From a14190b51fdfbc6a2d66a29e86185cb183b5363e Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 28 Sep 2010 19:30:30 -0600
Subject: [PATCH 0001/1659] added spec and reference schemas
---
address | 12 +
calendar | 20 +
card | 43 ++
draft-zyp-json-schema-03.xml | 985 +++++++++++++++++++++++++++++++++++
geo | 7 +
hyper-schema | 107 ++++
interfaces | 23 +
json-ref | 26 +
links | 34 ++
schema | 137 +++++
10 files changed, 1394 insertions(+)
create mode 100644 address
create mode 100644 calendar
create mode 100644 card
create mode 100644 draft-zyp-json-schema-03.xml
create mode 100644 geo
create mode 100644 hyper-schema
create mode 100644 interfaces
create mode 100644 json-ref
create mode 100644 links
create mode 100644 schema
diff --git a/address b/address
new file mode 100644
index 00000000..c553848c
--- /dev/null
+++ b/address
@@ -0,0 +1,12 @@
+{"description":"An Address following the convention of http://microformats.org/wiki/hcard",
+ "type":"object",
+ "properties":{
+ "post-office-box":{"type":"string","requires":"street-address"},
+ "extended-address":{"type":"string","requires":"street-address"},
+ "street-address":{"type":"string","requires":"region"},
+ "locality":{"type":"string","requires":"region", "required":true},
+ "region":{"type":"string","requires":"country-name", "required":true},
+ "postal-code":{"type":"string"},
+ "country-name":{"type":"string", "required":true}
+ }
+}
\ No newline at end of file
diff --git a/calendar b/calendar
new file mode 100644
index 00000000..9b02c4d7
--- /dev/null
+++ b/calendar
@@ -0,0 +1,20 @@
+{"description":"A representation of an event",
+ "type":"object",
+ "properties":{
+ "dtstart":{"format":"date-time","type":"string","description":"Event starting time","required":true},
+ "summary":{"type":"string","required":true},
+ "location":{"type":"string"},
+ "url":{"type":"string","format":"url"},
+ "dtend":{"format":"date-time","type":"string","description":"Event ending time"},
+ "duration":{"format":"date","type":"string","description":"Event duration"},
+ "rdate":{"format":"date-time","type":"string","description":"Recurrence date"},
+ "rrule":{"type":"string","description":"Recurrence rule"},
+ "category":{"type":"string"},
+ "description":{"type":"string"},
+ "geo":"http://json-schema.org/geo"
+ }
+}
+
+
+
+
diff --git a/card b/card
new file mode 100644
index 00000000..ba47d78b
--- /dev/null
+++ b/card
@@ -0,0 +1,43 @@
+{"description":"A representation of a person, company, organization, or place",
+ "type":"object",
+ "properties":{
+ "fn":{"description":"Formatted Name","type":"string"},
+ "familyName":{"type":"string", "required":true},
+ "givenName":{"type":"string", "required":true},
+ "additionalName":{"type":"array","items":{"type":"string"}},
+ "honorificPrefix":{"type":"array","items":{"type":"string"}},
+ "honorificSuffix":{"type":"array","items":{"type":"string"}},
+ "nickname":{"type":"string"},
+ "url":{"type":"string","format":"url"},
+ "email":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"email"}},
+ },
+ "tel":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"phone"}},
+ },
+ "adr":"http://json-schema.org/address",
+ "geo":"http://json-schema.org/geo",
+ "tz":{"type":"string"},
+ "photo":{"format":"image","type":"string"},
+ "logo":{"format":"image","type":"string"},
+ "sound":{"format":"attachment","type":"string"},
+ "bday":{"type":"string","format":"date"},
+ "title":{"type":"string"},
+ "role":{"type":"string"},
+ "org":{"type":"object",
+ "properties":{
+ "organizationName":{"type":"string"},
+ "organizationUnit":{"type":"string"}},
+ }
+ }
+}
+
+
+
+
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
new file mode 100644
index 00000000..acea107e
--- /dev/null
+++ b/draft-zyp-json-schema-03.xml
@@ -0,0 +1,985 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+
+ SitePen (USA)
+
+
+
+ 530 Lytton Avenue
+
+ Palo Alto, CA 94301
+
+ USA
+
+
+ +1 650 968 8787
+
+ kris@sitepen.com
+
+
+
+
+
+ Internet Engineering Task Force
+
+ JSON
+
+ Schema
+
+ Hyper Schema
+
+ Hypermedia
+
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+ 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.
+
+
+
+
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+
+This schema defines the properties of the instance JSON documents and
+their required properties (id, name, and price) as well as an optional
+property (tags). This also defines the link relations of the instance
+JSON documents.
+
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that the schema
+ will be describing and validating
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. It is acknowledged that JSON documents come
+ in a variety of structures, and JSON is unique in that the structure
+ of stored data structures often prescribes a non-ambiguous definite
+ JSON representation. Attempting to force a specific structure is generally
+ not viable, and therefore JSON Schema allows for great flexibility
+ in the structure of JSON data that it describes.
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a representational state transfer
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the application/json media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+ ; rel="describedby"
+]]>
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data, and the data SHOULD be valid by all the schemas.
+ The instance data MAY have multiple schemas
+ that it is defined by (the instance data SHOULD be valid for those schemas).
+ Or if the document is a collection of instances, the collection MAY contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the pathStart attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection. However, ultimately, the mechanism for referencing a schema is up to the
+ media type of the instance documents (if they choose to specify that schemas
+ can be referenced).
+
+
+
+ JSON Schemas are themselves instances for the schema
+ schemas. A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema and the hyper schema
+ self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ of the instance and defines it's usage and valid values. A JSON
+ Schema is a JSON Object with schema attribute properties. JSON
+ Schema has recursive capabilities; there are a number of elements
+ in the structure that allow for a nested JSON Schema or URI
+ referencing a schema. Schema referencing URIs can be relative
+ or absolute and the target of the URI SHOULD be treated as
+ the schema for the given element in the schema structure.
+ The following is the grammar of a JSON Schema:
+
+
+
+ And an example JSON Schema definition could look like:
+
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array MAY be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas (or schema referenced by the URI) in the array. For example to indicate that a string or number is a valid:
+{"type":["string","number"]}
+Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+
+string - Value MUST be a string.
+
+number - Value MUST be a number, floating point numbers are allowed.
+integer - Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
+boolean - Value MUST be a boolean.
+object - Value MUST be an object.
+array - Value MUST be an array.
+
+null - Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
+included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
+any - Value MAY be of any type including null.
+If the property is not defined or is not in this list, than any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+
+
+
+
+
+This is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+
+This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value MUST be a schema or a URI referencing a schema. If false is provided, no additional properties are allowed beyond the properties defined in the schema and the super schemas (the schemas that the schema extends). The default value is an empty schema which allows any value for additional properties.
+
+
+This MUST be a schema or URI referring to a schema or an array of schemas (schema or URI referring to a schema). When this is an object/schema and the instance value is an array, all the items in the array MUST conform to this schema or schema referenced by the URI. When this is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalItems attribute using the same rules as extra properties for objects. The default value is an empty schema which allows any value for items in the instance array.
+
+
+This provides a definition for additional items in array when tuple definition of the items in an array is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema or a URI referencing a schema to define the type of the additional items.
+
+
+This indicates that the instance property in the instance object is required. This is false by default.
+
+
+This indicates that if this property is present in the containing instance object, the property given by requires attribute MUST also be present in the containing instance object. The value
+of this property MAY be a string, indicating the require property name. Or the value MAY be a schema or a URI referencing a schema, in which case the containing instance MUST be valid by the schema if the property is present. For example if a object type definition is defined:
+
+
+
+
+An instance MUST include a state property if a town property is included. If a town property is not included, the state property is optional.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+This indicates the maximum value for the instance property when the type of the instance value is a number.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number. The instance value can not equal the exclusiveMinimum value.
+
+
+This indicates the maximum value for the instance property when the type of the instance value is a number. The instance value can not equal the exclusiveMaximum value.
+
+
+This indicates the minimum number of values in an array when an array is the instance value.
+
+
+This indicates the maximum number of values in an array when an array is the instance value.
+
+
+This indicates that all the items in an array MUST be unique (no two identical values) within that array when an array is the instance value. Uniqueness is only defined for primitive values (strings, numbers, booleans, and nulls).
+
+
+When the instance value is a string, this provides a regular expression that an instance string value MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
+
+When the instance value is a string, this indicates maximum length of the string.
+
+
+When the instance value is a string, this indicates minimum length of the string.
+
+
+This provides an enumeration of possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value MUST be one of the values in enum array in order for the schema to be valid.
+
+
+This provides a short description of the instance property. The value MUST be a string.
+
+
+This provides a full description of the of purpose the instance property. The value MUST be a string.
+
+
+This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
+date-time - This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+date - This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+time - This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+utc-millisec - This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
+regex - A regular expression, following the regular expression specification from ECMA 262/Perl 5.
+color - This is a CSS color (like "#FF0000" or "red"), based on &css21.
+style - This is a CSS style definition (like "color: red; background-color:#FFF"), based on &css21.
+phone - This SHOULD be a phone number (format MAY follow E.123).
+uri - This value SHOULD be a URI..
+email - This SHOULD be an email address.
+ip-address - This SHOULD be an ip version 4 address.
+ipv6 - This SHOULD be an ip version 6 address.
+host-name - This SHOULD be a host-name.
+Additional custom formats MAY be defined with a URL to a definition of the format.
+
+
+
+This indicates the maximum number of decimal points.
+
+
+This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, than this instance is not valid.
+
+
+The value of this property MUST be another schema or a URI referencing a schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional properties, constrain existing properties, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
+
+
+
+
+
+
+
+
+
+
+
+
+This indicates the URI of this schema (the target is effectively
+the "self" relation). This MAY be a relative or absolute. If the URI
+is relative, it SHOULD be resolved against the URI used to retrieve this schema.
+
+
+
+
+ The following attributes are specified in addition to those
+attributes that already provided by the core schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper schemas are optional.
+Therefore an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+
+
+The value of the links property MUST be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+
+A link description object is used to describe the link relations. In
+the context of a schema, it defines the link relations of the
+instances of the schema, and can be parameterized by the instance
+values. The link description format can be used on its own in
+regular (non-schema documents), and use of this format can
+be declared by referencing the normative link description
+schema as the the schema for the data structure that uses the
+links. The URI of the normative link description schema is: http://json-schema.org/links.
+
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property SHOULD be resolved as a URI-Reference per [RFC3986]
+and MAY be a relative URI. The base URI to be used for relative resolution
+SHOULD be the URI used to retrieve the instance object (not the schema)
+when used within a schema. Also, when links are used within a schema, the URI
+SHOULD be parametrized by the property values of the instance
+object, if property values exist for the corresponding variables
+in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+Instance property values SHOULD be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+
+If matching braces are found with the string "@" (no quotes) between the braces, than the
+actual instance value SHOULD be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+self - If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
+
+
+describedby - This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+
+
+instances - This indicates the target resource that represents collection of instances of a schema.
+
+
+create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+For example, if a schema is defined:
+
+
+
+
+And if a collection of instance resource's JSON representation was
+retrieved:
+
+
+
+
+
+This would indicate that for the first item in the collection, it's own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation SHOULD be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+This property value can be a schema that defines the expected
+structure of the JSON representation of the target of the link.
+
+
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+This indicates which method can be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, application/json is
+the default media type.
+
+
+
+
+This is inherited from the base JSON schema definition, and can follow the
+same structure, but its meaning SHOULD be used to define the acceptable
+property names and values for the action (whether it be for the GET query
+or POST body). If properties are omitted, and this form is the child of a
+schema, the properties from the parent schema SHOULD be used as the basis
+for the form action.
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "slash-delimited", which is defined below. Other fragment
+resolution protocols MAY be used, but are not defined in this
+document.
+
+
+
+The fragment identifier is based on RFC 2396 Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
+With the slash-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that start with and
+are delimited by the "/" character (\x2F). Each property reference token
+is a series of unreserved or escaped URI characters. Each property
+reference token SHOULD be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, than the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, than the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+Property names SHOULD be URI-encoded. In particular, any "/" in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+For example, for the following JSON representation:
+
+
+
+
+The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+The dot-delimited fragment resolution protocol is the same as
+slash-delimited fragment resolution protocol except that the "." character
+(\x2E) is used as the delimiter between property names (instead of "/") and
+the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
+identifiers for referencing the value of the foo propery.
+
+
+
+
+
+
+ This attribute indicates that the value of the instance property value
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
+
+
+This indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+If the instance property value is a string, this indicates that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+
+
+
+
+This indicates the default for the instance property.
+
+
+
+ This property value is a URI-Reference that indicates the URI that all
+the URIs for the instances of the schema MUST start with. When
+multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if URI of the instance begins with the pathStart's referenced
+URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+the instance does not start with URI indicated by pathStart, or if another
+schema specifies a starting URI that is longer and also matches the
+instance, this schema SHOULD NOT be applied to the instance. Any schema
+that does not have a pathStart attribute SHOULD be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+
+
+
+ This indicates the media type of the instance representations that this schema is defining.
+
+
+
+
+
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC
+4627. However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+
+
+And a resource was requested from somesite.com:
+
+
+
+
+
+With a response of:
+
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is application/schema+json
+
+
+ Type name: application
+
+
+ Subtype name: schema+json
+
+
+ Required parameters: profile
+
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+ Optional parameters: pretty
+
+
+ The value of the pretty parameter MAY be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+
+
+
+
+ &rfc3986;
+ &rfc2119;
+ &rfc4287;
+ &rfc3339;
+ &rfc2045;
+
+
+
+ &rfc4627;
+ &rfc2616;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
+
+
+
+
+ -03
+
+
+ Defined referencing schemas by URI for all elements that accept schemas
+ Added example and verbiage to extends
+ Defined slash-delimited to use a leading slash
+ Removed address values, and mime media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types)
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced divisibleBy attribute with maxDecimal attribute
+ Replaced optional attribute with required attribute
+ Replaced maximumCanEqual attribute with exclusiveMaximum attribute
+ Replaced minimumCanEqual attribute with exclusiveMinimum attribute
+ Moved default and contentEncoding to hyper schema
+ Added additionalItems
+ Added id
+ Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template
+
+
+
+ -02
+
+
+ Replaced maxDecimal attribute with divisibleBy attribute
+ Added slash-delimited fragment resolution protocol and made it the default.
+ Added language about using links outside of schemas by referencing it's normative URI.
+ Added uniqueItems attribute
+ Added targetSchema attribute to link description object
+
+
+
+ -01
+
+
+ Fixed category and updates from template
+
+
+ -00
+
+
+ Initial draft
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should we use "profile" as the media type parameter instead?
+ Should "root" be a MIME parameter instead of a schema attribute?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed.
+ I still do not like how dates are handled.
+ Should "slash-delimited" or "dot-delimited" be the default fragment resolution protocol?
+
+
+
+
+
+
diff --git a/geo b/geo
new file mode 100644
index 00000000..73a9851b
--- /dev/null
+++ b/geo
@@ -0,0 +1,7 @@
+{"description":"A geographical coordinate",
+ "type":"object",
+ "properties":{
+ "latitude":{"type":"number"},
+ "longitude":{"type":"number"}
+ }
+}
\ No newline at end of file
diff --git a/hyper-schema b/hyper-schema
new file mode 100644
index 00000000..3fedec1e
--- /dev/null
+++ b/hyper-schema
@@ -0,0 +1,107 @@
+{
+ "id" : "http://json-schema.org/hyper-schema",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : "http://json-schema.org/links"
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "default" : "slash-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : "http://json-schema.org/hyper-schema-or-uri"
+ },
+
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
+ "items" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ },
+ "additionalProperties" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
+ "default" : {}
+ },
+ "additionalItems" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
+ "default" : {}
+ },
+ "contentEncoding" : {
+ "type" : "string"
+ },
+
+ "default" : {
+ },
+
+ "requires" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "disallow" : {
+ "type" : ["string", "array", "http://json-schema.org/hyper-schema-or-uri"],
+ "items" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "uniqueItems" : true
+ },
+ "extends" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
+ "items" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ }
+
+ },
+
+ "links" : [
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited",
+ "extends" : "http://json-schema.org/schema"
+}
\ No newline at end of file
diff --git a/interfaces b/interfaces
new file mode 100644
index 00000000..c1c08fc3
--- /dev/null
+++ b/interfaces
@@ -0,0 +1,23 @@
+{
+ "extends":"http://json-schema.org/hyper-schema",
+ "description":"A schema for schema interface definitions that describe programmatic class structures using JSON schema syntax",
+ "properties":{
+ "methods":{
+ "type":"object",
+ "description":"This defines the set of methods available to the class instances",
+ "additionalProperties":{
+ "type":"object",
+ "description":"The definition of the method",
+ "properties":{
+ "parameters":{
+ "type":"array",
+ "description":"The set of parameters that should be passed to the method when it is called",
+ "items":"#",
+ "required": true
+ },
+ "returns":"#"
+ }
+ }
+ }
+ }
+}
diff --git a/json-ref b/json-ref
new file mode 100644
index 00000000..323df0c6
--- /dev/null
+++ b/json-ref
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema",
+ "id" : "http://json-schema.org/json-ref",
+
+ "items" : "#",
+ "additionalProperties" : "#",
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/links b/links
new file mode 100644
index 00000000..27041005
--- /dev/null
+++ b/links
@@ -0,0 +1,34 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema",
+ "id" : "http://json-schema.org/links",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string",
+ "required": true
+ },
+
+ "rel" : {
+ "type" : "string",
+ "required": true
+ },
+
+ "targetSchema" : "http://json-schema.org/hyper-schema",
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET"
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "http://json-schema.org/hyper-schema"
+ }
+ }
+}
\ No newline at end of file
diff --git a/schema b/schema
new file mode 100644
index 00000000..dd0d1cee
--- /dev/null
+++ b/schema
@@ -0,0 +1,137 @@
+{
+ "id" : "http://json-schema.org/schema#",
+ "type" : ["object","string"],
+ "format": "uri",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", "#"]
+ },
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "#",
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : ["#", "array"],
+ "items" : "#",
+ "default" : {}
+ },
+
+ "required" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : ["#", "boolean"],
+ "default" : {}
+ },
+ "additionalItems" : {
+ "type" : ["#", "boolean"],
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", "#"]
+ },
+
+ "minimum" : {
+ "type" : "number"
+ },
+
+ "maximum" : {
+ "type" : "number"
+ },
+
+ "exclusiveMinimum" : {
+ "type" : "number"
+ },
+
+ "exclusiveMaximum" : {
+ "type" : "number"
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer"
+ },
+
+ "uniqueItems" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer"
+ },
+
+ "enum" : {
+ "type" : "array",
+ "minItems" : 1,
+ "uniqueItems" : true
+ },
+
+ "title" : {
+ "type" : "string"
+ },
+
+ "description" : {
+ "type" : "string"
+ },
+
+ "format" : {
+ "type" : "string"
+ },
+
+ "maxDecimal" : {
+ "type" : "number",
+ "minimum" : 0
+ },
+
+ "disallow" : {
+ "type" : ["string", "array", "#"],
+ "items" : {
+ "type" : ["string", "#"]
+ },
+ "uniqueItems" : true
+ },
+
+ "extends" : {
+ "type" : ["#", "array"],
+ "items" : "#",
+ "default" : {}
+ }
+ },
+ "links" : [
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "default" : {}
+}
\ No newline at end of file
From 830520da1a3aca78927bfeba6162228de96436d1 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 28 Sep 2010 19:33:50 -0600
Subject: [PATCH 0002/1659] added commonjs impl
---
README.md | 5 +
lib/json-schema.js | 286 +++++++++++++++++++++++++++++++++++++++++++++
package.json | 11 ++
3 files changed, 302 insertions(+)
create mode 100644 README.md
create mode 100644 lib/json-schema.js
create mode 100644 package.json
diff --git a/README.md b/README.md
new file mode 100644
index 00000000..bbd6cf4a
--- /dev/null
+++ b/README.md
@@ -0,0 +1,5 @@
+JSON Schema is a repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema.
+
+Code is licensed under the AFL or BSD license as part of the Persevere
+project which is administered under the Dojo foundation,
+and all contributions require a Dojo CLA.
\ No newline at end of file
diff --git a/lib/json-schema.js b/lib/json-schema.js
new file mode 100644
index 00000000..0f5670b3
--- /dev/null
+++ b/lib/json-schema.js
@@ -0,0 +1,286 @@
+/**
+ * JSONSchema Validator - Validates JavaScript objects using JSON Schemas
+ * (http://www.json.com/json-schema-proposal/)
+ *
+ * Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
+ * Licensed under the MIT (MIT-LICENSE.txt) license.
+To use the validator call JSONSchema.validate with an instance object and an optional schema object.
+If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
+that schema will be used to validate and the schema parameter is not necessary (if both exist,
+both validations will occur).
+The validate method will return an array of validation errors. If there are no errors, then an
+empty list will be returned. A validation error will have two properties:
+"property" which indicates which property had the error
+"message" which indicates what the error was
+ */
+
+// setup primitive classes to be JSON Schema types
+String.type = "string";
+Boolean.type = "boolean";
+Number.type = "number";
+exports.Integer = {type:"integer"};
+Object.type = "object";
+Array.type = "array";
+Date.type = "date";
+
+exports.validate = function(/*Any*/instance,/*Object*/schema) {
+ // Summary:
+ // To use the validator call JSONSchema.validate with an instance object and an optional schema object.
+ // If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
+ // that schema will be used to validate and the schema parameter is not necessary (if both exist,
+ // both validations will occur).
+ // The validate method will return an object with two properties:
+ // valid: A boolean indicating if the instance is valid by the schema
+ // errors: An array of validation errors. If there are no errors, then an
+ // empty list will be returned. A validation error will have two properties:
+ // property: which indicates which property had the error
+ // message: which indicates what the error was
+ //
+ return validate(instance,schema,false);
+ };
+exports.checkPropertyChange = function(/*Any*/value,/*Object*/schema, /*String*/ property) {
+ // Summary:
+ // The checkPropertyChange method will check to see if an value can legally be in property with the given schema
+ // This is slightly different than the validate method in that it will fail if the schema is readonly and it will
+ // not check for self-validation, it is assumed that the passed in value is already internally valid.
+ // The checkPropertyChange method will return the same object type as validate, see JSONSchema.validate for
+ // information.
+ //
+ return validate(value,schema, property || "property");
+ };
+var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*Boolean*/ _changing) {
+
+ var errors = [];
+ // validate a value against a property definition
+ function checkProp(value, schema, path,i){
+ var l;
+ path += path ? typeof i == 'number' ? '[' + i + ']' : typeof i == 'undefined' ? '' : '.' + i : i;
+ function addError(message){
+ errors.push({property:path,message:message});
+ }
+
+ if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && schema.type)){
+ if(typeof schema == 'function'){
+ if(!(value instanceof schema)){
+ addError("is not an instance of the class/constructor " + schema.name);
+ }
+ }else if(schema){
+ addError("Invalid schema/property definition " + schema);
+ }
+ return null;
+ }
+ if(_changing && schema.readonly){
+ addError("is a readonly field, it can not be changed");
+ }
+ if(schema['extends']){ // if it extends another schema, it must pass that schema as well
+ checkProp(value,schema['extends'],path,i);
+ }
+ // validate a value against a type definition
+ function checkType(type,value){
+ if(type){
+ if(typeof type == 'string' && type != 'any' &&
+ (type == 'null' ? value !== null : typeof value != type) &&
+ !(value instanceof Array && type == 'array') &&
+ !(value instanceof Date && type == 'date') &&
+ !(type == 'integer' && value%1===0)){
+ return [{property:path,message:(typeof value) + " value found, but a " + type + " is required"}];
+ }
+ if(type instanceof Array){
+ var unionErrors=[];
+ for(var j = 0; j < type.length; j++){ // a union type
+ if(!(unionErrors=checkType(type[j],value)).length){
+ break;
+ }
+ }
+ if(unionErrors.length){
+ return unionErrors;
+ }
+ }else if(typeof type == 'object'){
+ var priorErrors = errors;
+ errors = [];
+ checkProp(value,type,path);
+ var theseErrors = errors;
+ errors = priorErrors;
+ return theseErrors;
+ }
+ }
+ return [];
+ }
+ if(value === undefined){
+ if(!schema.optional && !schema.get){
+ addError("is missing and it is not optional");
+ }
+ }else{
+ errors = errors.concat(checkType(schema.type,value));
+ if(schema.disallow && !checkType(schema.disallow,value).length){
+ addError(" disallowed value was matched");
+ }
+ if(value !== null){
+ if(value instanceof Array){
+ if(schema.items){
+ if(schema.items instanceof Array){
+ for(i=0,l=value.length; i schema.maxItems){
+ addError("There must be a maximum of " + schema.maxItems + " in the array");
+ }
+ }else if(schema.properties || schema.additionalProperties){
+ errors.concat(checkObj(value, schema.properties, path, schema.additionalProperties));
+ }
+ if(schema.pattern && typeof value == 'string' && !value.match(schema.pattern)){
+ addError("does not match the regex pattern " + schema.pattern);
+ }
+ if(schema.maxLength && typeof value == 'string' && value.length > schema.maxLength){
+ addError("may only be " + schema.maxLength + " characters long");
+ }
+ if(schema.minLength && typeof value == 'string' && value.length < schema.minLength){
+ addError("must be at least " + schema.minLength + " characters long");
+ }
+ if(typeof schema.minimum !== undefined && typeof value == typeof schema.minimum &&
+ schema.minimum > value){
+ addError("must have a minimum value of " + schema.minimum);
+ }
+ if(typeof schema.maximum !== undefined && typeof value == typeof schema.maximum &&
+ schema.maximum < value){
+ addError("must have a maximum value of " + schema.maximum);
+ }
+ if(schema['enum']){
+ var enumer = schema['enum'];
+ l = enumer.length;
+ var found;
+ for(var j = 0; j < l; j++){
+ if(enumer[j]===value){
+ found=1;
+ break;
+ }
+ }
+ if(!found){
+ addError("does not have a value in the enumeration " + enumer.join(", "));
+ }
+ }
+ if(typeof schema.maxDecimal == 'number' &&
+ (value.toString().match(new RegExp("\\.[0-9]{" + (schema.maxDecimal + 1) + ",}")))){
+ addError("may only have " + schema.maxDecimal + " digits of decimal places");
+ }
+ }
+ }
+ return null;
+ }
+ // validate an object against a schema
+ function checkObj(instance,objTypeDef,path,additionalProp){
+
+ if(typeof objTypeDef =='object'){
+ if(typeof instance != 'object' || instance instanceof Array){
+ errors.push({property:path,message:"an object is required"});
+ }
+
+ for(var i in objTypeDef){
+ if(objTypeDef.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_')){
+ var value = instance[i];
+ var propDef = objTypeDef[i];
+ // set default
+ if(value === undefined && propDef["default"]){
+ value = instance[i] = propDef["default"];
+ }
+ if(exports.coerce){
+ value = instance[i] = exports.coerce(value, propDef);
+ }
+ checkProp(value,propDef,path,i);
+ }
+ }
+ }
+ for(i in instance){
+ if(instance.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_') && objTypeDef && !objTypeDef[i] && additionalProp===false){
+ errors.push({property:path,message:(typeof value) + "The property " + i +
+ " is not defined in the schema and the schema does not allow additional properties"});
+ }
+ var requires = objTypeDef && objTypeDef[i] && objTypeDef[i].requires;
+ if(requires && !(requires in instance)){
+ errors.push({property:path,message:"the presence of the property " + i + " requires that " + requires + " also be present"});
+ }
+ value = instance[i];
+ if(additionalProp && (!(objTypeDef && typeof objTypeDef == 'object') || !(i in objTypeDef))){
+ if(exports.coerce){
+ value = instance[i] = exports.coerce(value, additionalProp);
+ }
+ checkProp(value,additionalProp,path,i);
+ }
+ if(!_changing && value && value.$schema){
+ errors = errors.concat(checkProp(value,value.$schema,path,i));
+ }
+ }
+ return errors;
+ }
+ if(schema){
+ checkProp(instance,schema,'',_changing || '');
+ }
+ if(!_changing && instance && instance.$schema){
+ checkProp(instance,instance.$schema,'','');
+ }
+ return {valid:!errors.length,errors:errors};
+};
+exports.mustBeValid = function(result){
+ // summary:
+ // This checks to ensure that the result is valid and will throw an appropriate error message if it is not
+ // result: the result returned from checkPropertyChange or validate
+ if(!result.valid){
+ throw new TypeError(result.errors.map(function(error){return "for property " + error.property + ': ' + error.message;}).join(", \n"));
+ }
+}
+ /* will add this later
+ newFromSchema : function() {
+ }
+*/
+
+exports.cacheLinks = true;
+exports.getLink = function(relation, instance, schema){
+ // gets the URI of the link for the given relation based on the instance and schema
+ // for example:
+ // getLink(
+ // "brother",
+ // {"brother_id":33},
+ // {links:[{rel:"brother", href:"Brother/{brother_id}"}]}) ->
+ // "Brother/33"
+ var links = schema.__linkTemplates;
+ if(!links){
+ links = {};
+ var schemaLinks = schema.links;
+ if(schemaLinks && schemaLinks instanceof Array){
+ schemaLinks.forEach(function(link){
+ /* // TODO: allow for multiple same-name relations
+ if(links[link.rel]){
+ if(!(links[link.rel] instanceof Array)){
+ links[link.rel] = [links[link.rel]];
+ }
+ }*/
+ links[link.rel] = link.href;
+ });
+ }
+ if(exports.cacheLinks){
+ schema.__linkTemplates = links;
+ }
+ }
+ var linkTemplate = links[relation];
+ return linkTemplate && exports.substitute(linkTemplate, instance);
+};
+
+exports.substitute = function(linkTemplate, instance){
+ return linkTemplate.replace(/\{([^\}]*)\}/g, function(t, property){
+ var value = instance[decodeURIComponent(property)];
+ if(value instanceof Array){
+ // the value is an array, it should produce a URI like /Table/(4,5,8) and store.get() should handle that as an array of values
+ return '(' + value.join(',') + ')';
+ }
+ return value;
+ });
+};
\ No newline at end of file
diff --git a/package.json b/package.json
new file mode 100644
index 00000000..42fb6686
--- /dev/null
+++ b/package.json
@@ -0,0 +1,11 @@
+{
+ "name": "json-schema",
+ "author": "Kris Zyp",
+ "dependencies": [],
+ "contributors": [],
+ "keywords": [
+ "json",
+ "schema"
+ ],
+ "engines": {"node":">=0.1.30", "rhino": true}
+}
\ No newline at end of file
From e53541905b8841f3cadd5ab86443e5cfe1816c9f Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 28 Sep 2010 20:43:59 -0600
Subject: [PATCH 0003/1659] Updated docs
---
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/README.md b/README.md
index bbd6cf4a..4de01244 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-JSON Schema is a repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema.
+JSON Schema is a repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema (not the only JavaScript implementation of JSON Schema, JSV is another excellent JavaScript validator).
Code is licensed under the AFL or BSD license as part of the Persevere
project which is administered under the Dojo foundation,
From ab78480e03a9f91e78c5ade12f6636ef92e66ab1 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 28 Sep 2010 20:44:11 -0600
Subject: [PATCH 0004/1659] Split into two modules, add require.def support
---
lib/links.js | 52 +++++++++++++++++++++++++++
lib/{json-schema.js => validate.js} | 56 ++++-------------------------
2 files changed, 59 insertions(+), 49 deletions(-)
create mode 100644 lib/links.js
rename lib/{json-schema.js => validate.js} (86%)
diff --git a/lib/links.js b/lib/links.js
new file mode 100644
index 00000000..9736c301
--- /dev/null
+++ b/lib/links.js
@@ -0,0 +1,52 @@
+/**
+ * JSON Schema link handler
+ * Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
+ * Licensed under the MIT (MIT-LICENSE.txt) license.
+ */
+require.def||(require.def=function(deps, factory){module.exports = factory();});
+require.def([], function(){
+var exports = {};
+exports.cacheLinks = true;
+exports.getLink = function(relation, instance, schema){
+ // gets the URI of the link for the given relation based on the instance and schema
+ // for example:
+ // getLink(
+ // "brother",
+ // {"brother_id":33},
+ // {links:[{rel:"brother", href:"Brother/{brother_id}"}]}) ->
+ // "Brother/33"
+ var links = schema.__linkTemplates;
+ if(!links){
+ links = {};
+ var schemaLinks = schema.links;
+ if(schemaLinks && schemaLinks instanceof Array){
+ schemaLinks.forEach(function(link){
+ /* // TODO: allow for multiple same-name relations
+ if(links[link.rel]){
+ if(!(links[link.rel] instanceof Array)){
+ links[link.rel] = [links[link.rel]];
+ }
+ }*/
+ links[link.rel] = link.href;
+ });
+ }
+ if(exports.cacheLinks){
+ schema.__linkTemplates = links;
+ }
+ }
+ var linkTemplate = links[relation];
+ return linkTemplate && exports.substitute(linkTemplate, instance);
+};
+
+exports.substitute = function(linkTemplate, instance){
+ return linkTemplate.replace(/\{([^\}]*)\}/g, function(t, property){
+ var value = instance[decodeURIComponent(property)];
+ if(value instanceof Array){
+ // the value is an array, it should produce a URI like /Table/(4,5,8) and store.get() should handle that as an array of values
+ return '(' + value.join(',') + ')';
+ }
+ return value;
+ });
+};
+return exports;
+});
\ No newline at end of file
diff --git a/lib/json-schema.js b/lib/validate.js
similarity index 86%
rename from lib/json-schema.js
rename to lib/validate.js
index 0f5670b3..5f9b7a68 100644
--- a/lib/json-schema.js
+++ b/lib/validate.js
@@ -4,7 +4,7 @@
*
* Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
* Licensed under the MIT (MIT-LICENSE.txt) license.
-To use the validator call JSONSchema.validate with an instance object and an optional schema object.
+To use the validator call the validate function with an instance object and an optional schema object.
If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
that schema will be used to validate and the schema parameter is not necessary (if both exist,
both validations will occur).
@@ -13,6 +13,8 @@ empty list will be returned. A validation error will have two properties:
"property" which indicates which property had the error
"message" which indicates what the error was
*/
+require.def||(require.def=function(deps, factory){module.exports = factory();});
+require.def([], function(){
// setup primitive classes to be JSON Schema types
String.type = "string";
@@ -22,8 +24,8 @@ exports.Integer = {type:"integer"};
Object.type = "object";
Array.type = "array";
Date.type = "date";
-
-exports.validate = function(/*Any*/instance,/*Object*/schema) {
+var exports = validate;
+exports.validate = function validate(/*Any*/instance,/*Object*/schema) {
// Summary:
// To use the validator call JSONSchema.validate with an instance object and an optional schema object.
// If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
@@ -237,50 +239,6 @@ exports.mustBeValid = function(result){
throw new TypeError(result.errors.map(function(error){return "for property " + error.property + ': ' + error.message;}).join(", \n"));
}
}
- /* will add this later
- newFromSchema : function() {
- }
-*/
-exports.cacheLinks = true;
-exports.getLink = function(relation, instance, schema){
- // gets the URI of the link for the given relation based on the instance and schema
- // for example:
- // getLink(
- // "brother",
- // {"brother_id":33},
- // {links:[{rel:"brother", href:"Brother/{brother_id}"}]}) ->
- // "Brother/33"
- var links = schema.__linkTemplates;
- if(!links){
- links = {};
- var schemaLinks = schema.links;
- if(schemaLinks && schemaLinks instanceof Array){
- schemaLinks.forEach(function(link){
- /* // TODO: allow for multiple same-name relations
- if(links[link.rel]){
- if(!(links[link.rel] instanceof Array)){
- links[link.rel] = [links[link.rel]];
- }
- }*/
- links[link.rel] = link.href;
- });
- }
- if(exports.cacheLinks){
- schema.__linkTemplates = links;
- }
- }
- var linkTemplate = links[relation];
- return linkTemplate && exports.substitute(linkTemplate, instance);
-};
-
-exports.substitute = function(linkTemplate, instance){
- return linkTemplate.replace(/\{([^\}]*)\}/g, function(t, property){
- var value = instance[decodeURIComponent(property)];
- if(value instanceof Array){
- // the value is an array, it should produce a URI like /Table/(4,5,8) and store.get() should handle that as an array of values
- return '(' + value.join(',') + ')';
- }
- return value;
- });
-};
\ No newline at end of file
+return exports;
+});
\ No newline at end of file
From d077cab6fd7bd60dcf9de22093a687b762899769 Mon Sep 17 00:00:00 2001
From: unknown
Date: Wed, 29 Sep 2010 23:08:58 -0600
Subject: [PATCH 0005/1659] Fixed XML and reference errors.
---
draft-zyp-json-schema-03.xml | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index acea107e..50362063 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -20,7 +20,7 @@
-
+
@@ -386,14 +386,15 @@ of this property MAY be a string, indicating the require property name. Or the v
This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
-date-time - This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+date-time - This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
date - This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
time - This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
utc-millisec - This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
regex - A regular expression, following the regular expression specification from ECMA 262/Perl 5.
-color - This is a CSS color (like "#FF0000" or "red"), based on &css21.
-style - This is a CSS style definition (like "color: red; background-color:#FFF"), based on &css21.
+color - This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
+style - This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
phone - This SHOULD be a phone number (format MAY follow E.123).
uri - This value SHOULD be a URI..
email - This SHOULD be an email address.
@@ -402,6 +403,7 @@ of this property MAY be a string, indicating the require property name. Or the v
host-name - This SHOULD be a host-name.Additional custom formats MAY be defined with a URL to a definition of the format.
+This indicates the maximum number of decimal points.
@@ -512,7 +514,7 @@ The value of the "rel" property indicates the name of the
relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
self - If the relation value is "self", when this property is encountered in
From 0f6a2fce162f445c92d02292362e533615a3e5dd Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 30 Sep 2010 13:56:21 -0600
Subject: [PATCH 0006/1659] Fix exports
---
lib/validate.js | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 5f9b7a68..a68bd500 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -15,7 +15,7 @@ empty list will be returned. A validation error will have two properties:
*/
require.def||(require.def=function(deps, factory){module.exports = factory();});
require.def([], function(){
-
+var exports = validate;
// setup primitive classes to be JSON Schema types
String.type = "string";
Boolean.type = "boolean";
@@ -24,8 +24,8 @@ exports.Integer = {type:"integer"};
Object.type = "object";
Array.type = "array";
Date.type = "date";
-var exports = validate;
-exports.validate = function validate(/*Any*/instance,/*Object*/schema) {
+exports.validate = validate;
+function validate(/*Any*/instance,/*Object*/schema) {
// Summary:
// To use the validator call JSONSchema.validate with an instance object and an optional schema object.
// If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
From e518da0a41c19b14cce8e402b6288ddb531c21ce Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 30 Sep 2010 13:56:58 -0600
Subject: [PATCH 0007/1659] Made root a relation and clarified context of
pathStart
---
draft-zyp-json-schema-03.xml | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index acea107e..c3c17b4b 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -535,6 +535,14 @@ instances - This indicates the target resource that represents collection of ins
create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+root - This relation indicates that the target
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
For example, if a schema is defined:
@@ -743,16 +751,6 @@ identifiers for referencing the value of the foo propery.
-
- This attribute indicates that the value of the instance property value
-SHOULD be treated as the root or the body of the representation for the
-purposes of user agent interaction and fragment resolution (all other
-properties of the instance objects are can be regarded as meta-data
-descriptions for the data).
-
-
-
-This indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
@@ -777,7 +775,9 @@ schema specifies a starting URI that is longer and also matches the
instance, this schema SHOULD NOT be applied to the instance. Any schema
that does not have a pathStart attribute SHOULD be considered applicable
to all the instances for which it is referenced.
-
+
+
+If this URI is relative, it should be resolved against the instance's URI.
@@ -875,7 +875,7 @@ Content-Type: application/json; profile=/schema-for-this-data
This registry is maintained by IANA per RFC 4287 and this specification adds
-three values: "full", "create", "instances". New
+four values: "full", "create", "instances", "root". New
assignments are subject to IESG Approval, as outlined in [RFC5226].
Requests should be made by email to IANA, which will then forward the
request to the IESG, requesting approval.
From c3d6e4f7f52ca037ce980c66f0b6efb0d58551d2 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 30 Sep 2010 13:58:02 -0600
Subject: [PATCH 0008/1659] Added change log comment
---
draft-zyp-json-schema-03.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index ccf1f5a4..d3021e13 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -926,6 +926,7 @@ instead of numbersDefined referencing schemas by URI for all elements that accept schemasAdded example and verbiage to extendsDefined slash-delimited to use a leading slash
+ Made "root" a relation instead of an attributeRemoved address values, and mime media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types)Added more explanation of nullability.Removed "alternate" attribute.
From 4eafc69aabef9ed3630e205df9812c7f4ba93e05 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Thu, 30 Sep 2010 18:39:26 -0600
Subject: [PATCH 0009/1659] Fixed numerous errors listed below: -Added RFC2396
reference -Quoted MIME types -Added reference targets to all mentionings of
RFCs -Improved artwork spacing, updated all JSON examples to use consistent
spacing -Added external references to URLs -Improved wording to: --Core
Schema Definition --required --requires --minimum --maximum
--exclusiveMaximum --exclusiveMinimum --minItems --maxItems --uniqueItems
--pattern --maxLength --minLength --enum --title --description --id
--targetSchema --method --readonly --contentEncoding --default -Lists now use
hanging style where appropriate -Moved "root" link under instance links
-Fixed list layout for rel -Fixed sectioning of targetSchema -Cleaned up
changelog -Removed no longer outstanding open issues -Added recognition of
work
---
draft-zyp-json-schema-03.xml | 501 +++++++++++++++++------------------
1 file changed, 246 insertions(+), 255 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index d3021e13..35757e4e 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -8,6 +8,7 @@
+
@@ -22,11 +23,9 @@
-
A JSON Media Type for Describing the Structure and Meaning of JSON Documents
-
SitePen (USA)
@@ -45,23 +44,33 @@
kris@sitepen.com
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+ Internet Engineering Task ForceJSON
-
Schema
-
+ JavaScript
+ Object
+ NotationHyper Schema
-
Hypermedia
- JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
a JSON based format for defining
the structure of JSON data. JSON Schema provides a contract for what JSON
data is required for a given application and how to interact with it. JSON
@@ -87,13 +96,13 @@
and should not be modified.-->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.
+ interpreted as described in RFC 2119.
- JSON Schema defines the media type application/schema+json for
+ JSON Schema defines the media type "application/schema+json" for
describing the structure of other
JSON documents. JSON Schema is JSON-based and includes facilities
for describing the structure of JSON documents in terms of
@@ -118,8 +127,7 @@
An example JSON Schema that describes products might look like:
-
-
JSON Schema instances are correlated to their schema by the "describedby"
relation, where the schema is defined to be the target of the relation.
- Instance representations may be of the application/json media type or
+ Instance representations may be of the "application/json" media type or
any other subtype. Consequently, dictating how an instance
representation should specify the relation to the schema is beyond the normative scope
of this document (since this document specifically defines the JSON
@@ -210,16 +218,14 @@ JSON documents.
of instances) structure. A MIME type parameter named
"profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
-
-
or if the content is being transferred by a protocol (such as HTTP) that
provides headers, a Link header can be used:
-
- ; rel="describedby"
]]>
Instances MAY specify multiple schemas, to indicate all the schemas that
@@ -238,14 +244,13 @@ collection. However, ultimately, the mechanism for referencing a schema is up to
JSON Schemas are themselves instances for the schema
schemas. A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema and the hyper schema
- self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ be found at http://json-schema.org/schema, while the hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema. All schemas
used within a protocol with media type definitions
SHOULD include a MIME parameter that refers to the self-descriptive
hyper schema or another schema that extends this hyper schema:
-
-
@@ -255,28 +260,27 @@ Content-Type: application/json;
A JSON Schema is a JSON Object that defines various attributes
- of the instance and defines it's usage and valid values. A JSON
- Schema is a JSON Object with schema attribute properties. JSON
+ of the instance and defines it's usage and valid values. JSON
Schema has recursive capabilities; there are a number of elements
in the structure that allow for a nested JSON Schema or URI
referencing a schema. Schema referencing URIs can be relative
or absolute and the target of the URI SHOULD be treated as
the schema for the given element in the schema structure.
- The following is the grammar of a JSON Schema:
- And an example JSON Schema definition could look like:
+ An example JSON Schema definition could look like:
-
-
@@ -287,26 +291,30 @@ Content-Type: application/json;
-Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array MAY be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas (or schema referenced by the URI) in the array. For example to indicate that a string or number is a valid:
-{"type":["string","number"]}
-Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
-
-
-
-string - Value MUST be a string.
-
-number - Value MUST be a number, floating point numbers are allowed.
-integer - Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
-boolean - Value MUST be a boolean.
-object - Value MUST be an object.
-array - Value MUST be an array.
-
-null - Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
+
+A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+Value MUST be a string.
+Value MUST be a number, floating point numbers are allowed.
+Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
+Value MUST be a boolean.
+Value MUST be an object.
+Value MUST be an array.
+Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
-any - Value MAY be of any type including null.
+Value MAY be of any type including null.
If the property is not defined or is not in this list, than any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+An array with two or more simple type definitions. Each item in the array MUST be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one the simple type definitions in the array, or if it is valid by one of the schemas (or schema referenced by the URI) in the array.
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
+
+
@@ -323,21 +331,18 @@ If the property is not defined or is not in this list, than any type of value is
This provides a definition for additional items in array when tuple definition of the items in an array is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema or a URI referencing a schema to define the type of the additional items.
-This indicates that the instance property in the instance object is required. This is false by default.
+This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
-This indicates that if this property is present in the containing instance object, the property given by requires attribute MUST also be present in the containing instance object. The value
+This attribute indicates that if this property is present in the containing instance object, the property given by requires attribute MUST also be present in the containing instance object. The value
of this property MAY be a string, indicating the require property name. Or the value MAY be a schema or a URI referencing a schema, in which case the containing instance MUST be valid by the schema if the property is present. For example if a object type definition is defined:
-
- An instance MUST include a state property if a town property is included. If a town property is not included, the state property is optional.
-This indicates the minimum value for the instance property when the type of the instance value is a number.
+This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-This indicates the maximum value for the instance property when the type of the instance value is a number.
+This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-This indicates the minimum value for the instance property when the type of the instance value is a number. The instance value can not equal the exclusiveMinimum value.
+This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-This indicates the maximum value for the instance property when the type of the instance value is a number. The instance value can not equal the exclusiveMaximum value.
+This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-This indicates the minimum number of values in an array when an array is the instance value.
+This attribute defines the minimum number of values in an array when the array is the instance value.
-This indicates the maximum number of values in an array when an array is the instance value.
+This attribute defines the maximum number of values in an array when the array is the instance value.
-This indicates that all the items in an array MUST be unique (no two identical values) within that array when an array is the instance value. Uniqueness is only defined for primitive values (strings, numbers, booleans, and nulls).
+This attribute indicates that all the items in an array MUST be unique (no two identical values) within that array when the array is the instance value. Uniqueness is only defined for primitive types: strings, numbers, booleans, and nulls.
-When the instance value is a string, this provides a regular expression that an instance string value MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
+When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-When the instance value is a string, this indicates maximum length of the string.
+When the instance value is a string, this defines the maximum length of the string.
-When the instance value is a string, this indicates minimum length of the string.
+When the instance value is a string, this defines the minimum length of the string.
-This provides an enumeration of possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value MUST be one of the values in enum array in order for the schema to be valid.
+This provides an enumeration of possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid.
-This provides a short description of the instance property. The value MUST be a string.
+This attribute is a string that provides a short description of the instance property.
-This provides a full description of the of purpose the instance property. The value MUST be a string.
+This attribute is a string that provides a full description of the of purpose the instance property.
-This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
-
-date-time - This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
-date - This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
-time - This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
-utc-millisec - This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
-regex - A regular expression, following the regular expression specification from ECMA 262/Perl 5.
-color - This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
-style - This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
-phone - This SHOULD be a phone number (format MAY follow E.123).
-uri - This value SHOULD be a URI..
-email - This SHOULD be an email address.
-ip-address - This SHOULD be an ip version 4 address.
-ipv6 - This SHOULD be an ip version 6 address.
-host-name - This SHOULD be a host-name.
-Additional custom formats MAY be defined with a URL to a definition of the format.
+
+This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
+A regular expression, following the regular expression specification from ECMA 262/Perl 5.
+This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
+This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
+This SHOULD be a phone number (format MAY follow E.123).
+This value SHOULD be a URI..
+This SHOULD be an email address.
+This SHOULD be an ip version 4 address.
+This SHOULD be an ip version 6 address.
+This SHOULD be a host-name.
+Additional custom formats MAY be defined with a URL to a definition of the format.This indicates the maximum number of decimal points.
@@ -414,19 +419,19 @@ of this property MAY be a string, indicating the require property name. Or the v
The value of this property MUST be another schema or a URI referencing a schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional properties, constrain existing properties, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
-
-
-
-
@@ -435,7 +440,7 @@ of this property MAY be a string, indicating the require property name. Or the v
-This indicates the URI of this schema (the target is effectively
+This defines the URI of this schema (the target is effectively
the "self" relation). This MAY be a relative or absolute. If the URI
is relative, it SHOULD be resolved against the URI used to retrieve this schema.
@@ -466,13 +471,13 @@ values. The link description format can be used on its own in
regular (non-schema documents), and use of this format can
be declared by referencing the normative link description
schema as the the schema for the data structure that uses the
-links. The URI of the normative link description schema is: http://json-schema.org/links.
+links. The URI of the normative link description schema is: http://json-schema.org/links.
The value of the "href" link description property
indicates the target URI of the related resource. The value
-of the instance property SHOULD be resolved as a URI-Reference per [RFC3986]
+of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
and MAY be a relative URI. The base URI to be used for relative resolution
SHOULD be the URI used to retrieve the instance object (not the schema)
when used within a schema. Also, when links are used within a schema, the URI
@@ -488,8 +493,7 @@ by using the text between the braces to denote the property name
from the instance to get the value to substitute. For example,
if an href value is defined:
-
-
@@ -497,8 +501,7 @@ Then it would be resolved by replace the value of the "id" property value from
the instance object. If the value of the "id" property was "45", the expanded
URI would be:
-
-
@@ -515,75 +518,75 @@ relation to the target resource. The relation to the target SHOULD be interprete
Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
-
-
-self - If the relation value is "self", when this property is encountered in
+
+
+If the relation value is "self", when this property is encountered in
the instance object, the object represents a resource and the instance object is
treated as a full representation of the target resource identified by
the specified URI.
-
-full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
+
+This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
-
-describedby - This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
-The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+This relation indicates that the target of the link
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction or fragment resolution. All other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data.
-
-instances - This indicates the target resource that represents collection of instances of a schema.
+
-create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+This indicates the target resource that represents collection of instances of a schema.
-root - This relation indicates that the target
-SHOULD be treated as the root or the body of the representation for the
-purposes of user agent interaction and fragment resolution (all other
-properties of the instance objects are can be regarded as meta-data
-descriptions for the data).
-
+
+This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
-
+
+
For example, if a schema is defined:
-
-
And if a collection of instance resource's JSON representation was
retrieved:
-
-
@@ -593,11 +596,11 @@ This would indicate that for the first item in the collection, it's own
relation SHOULD be resolved to the resource at "/Resource/parent".
The "children" collection would be located at "/Resource/?upId=thing".
+
-This property value can be a schema that defines the expected
+This property value is a schema that defines the expected
structure of the JSON representation of the target of the link.
-
The following properties also apply to link definition objects, and
@@ -607,7 +610,7 @@ means for submitting extra (often user supplied) information to send to a server
-This indicates which method can be used to access the target resource.
+This attribute defines which method can be used to access the target resource.
In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
such as "PUT" and "DELETE" have semantics that are clearly implied by
accessed resources, and do not need to be defined here).
@@ -625,33 +628,31 @@ property-based constraints on the resources that SHOULD be returned from
the server or used to post data to the resource (depending on the method).
For example, with the following schema:
-
-
This indicates that the client can query the server for instances that
have a specific name:
-
-
If no enctype or method is specified, only the single URI specified by
-the href property is defined. If the method is POST, application/json is
+the href property is defined. If the method is POST, "application/json" is
the default media type.
@@ -680,7 +681,7 @@ document.
-The fragment identifier is based on RFC 2396 Sec 5, and defines the
+The fragment identifier is based on RFC 2396, Sec 5, and defines the
mechanism for resolving references to entities within a document.
@@ -709,35 +710,33 @@ delimiter.
For example, for the following JSON representation:
-
-
The following fragment identifiers would be resolved:
-
-
@@ -754,24 +753,25 @@ identifiers for referencing the value of the foo propery.
-This indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
-If the instance property value is a string, this indicates that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
-This indicates the default for the instance property.
+This attribute defines the default value of the instance when the instance is undefined.
-
- This property value is a URI-Reference that indicates the URI that all
+
+
+This property value is a URI-Reference that indicates the URI that all
the URIs for the instances of the schema MUST start with. When
multiple schemas have been referenced for an instance, the user agent
can determine if this schema is applicable for a particular instance by
determining if URI of the instance begins with the pathStart's referenced
-URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+URI. pathStart MUST be resolved as per RFC 3986, Sec 5. If the URI of
the instance does not start with URI indicated by pathStart, or if another
schema specifies a starting URI that is longer and also matches the
instance, this schema SHOULD NOT be applied to the instance. Any schema
@@ -785,8 +785,9 @@ If this URI is relative, it should be resolved against the instance's URI.
-
- This indicates the media type of the instance representations that this schema is defining.
+
+
+This attribute defines the media type of the instance representations that this schema is defining.
@@ -797,8 +798,8 @@ If this URI is relative, it should be resolved against the instance's URI.
This specification is a sub-type of the JSON format, and
-consequently the security considerations are generally the same as RFC
-4627. However, an additional issue is that when link relation of "self"
+consequently the security considerations are generally the same as RFC 4627.
+However, an additional issue is that when link relation of "self"
is used to denote a full representation of an object, the user agent
SHOULD NOT consider the representation to be the authoritative representation
of the resource denoted by the target URI if the target URI is not
@@ -806,13 +807,12 @@ equivalent to or a sub-path of the the URI used to request the resource
representation which contains the target URI with the "self" link.
For example, if a hyper schema was defined:
-
-
And a resource was requested from somesite.com:
-
-
With a response of:
-
-
- The proposed MIME media type for JSON Schema is application/schema+json
+ The proposed MIME media type for JSON Schema is "application/schema+json".
Type name: application
@@ -876,9 +874,9 @@ Content-Type: application/json; profile=/schema-for-this-data
-This registry is maintained by IANA per RFC 4287 and this specification adds
+This registry is maintained by IANA per RFC 4287 and this specification adds
four values: "full", "create", "instances", "root". New
- assignments are subject to IESG Approval, as outlined in [RFC5226].
+ assignments are subject to IESG Approval, as outlined in RFC 5226.
Requests should be made by email to IANA, which will then forward the
request to the IESG, requesting approval.
@@ -893,16 +891,17 @@ four values: "full", "create", "instances", "root". New
- &rfc3986;
+ &rfc2045;
&rfc2119;
- &rfc4287;
+ &rfc2396;
&rfc3339;
- &rfc2045;
+ &rfc3986;
+ &rfc4287;
- &rfc4627;
&rfc2616;
+ &rfc4627;
&rfc5226;
&iddiscovery;
&uritemplate;
@@ -919,70 +918,62 @@ instead of numbers
-->
-
- -03
-
+
+
+
+
- Defined referencing schemas by URI for all elements that accept schemas
- Added example and verbiage to extends
- Defined slash-delimited to use a leading slash
- Made "root" a relation instead of an attribute
- Removed address values, and mime media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types)
+ Defined referencing schemas by URI for all elements that accept schemas.
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).Added more explanation of nullability.Removed "alternate" attribute.Upper cased many normative usages of must, may, and should.
- Replaced divisibleBy attribute with maxDecimal attribute
- Replaced optional attribute with required attribute
- Replaced maximumCanEqual attribute with exclusiveMaximum attribute
- Replaced minimumCanEqual attribute with exclusiveMinimum attribute
- Moved default and contentEncoding to hyper schema
- Added additionalItems
- Added id
- Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template
+ Replaced "divisibleBy" attribute with "maxDecimal" attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
+ Moved "default" and "contentEncoding" attributes to hyper schema
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
- -02
-
+
- Replaced maxDecimal attribute with divisibleBy attribute
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.Added slash-delimited fragment resolution protocol and made it the default.Added language about using links outside of schemas by referencing it's normative URI.
- Added uniqueItems attribute
- Added targetSchema attribute to link description object
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
- -01
-
+
- Fixed category and updates from template
+ Fixed category and updates from template.
- -00
-
+
- Initial draft
+ Initial draft.
-
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
- Should we use "profile" as the media type parameter instead?
- Should "root" be a MIME parameter instead of a schema attribute?
- Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed.
- I still do not like how dates are handled.
- Should "slash-delimited" or "dot-delimited" be the default fragment resolution protocol?
-
+ Should "root" be a MIME parameter?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
+ How should dates be handled?
+
-
-
+
From 32158718cd1c050d331e06e5c34f41732ac1737a Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Mon, 4 Oct 2010 20:05:20 -0600
Subject: [PATCH 0010/1659] Made the following changes: -Improved the wording
in: --Terminology --Design Considerations --type --properties
--additionalProperties --items --additionalItems --requires --enum --format
--maxDecimal --disallow --id --pathStart -Adjusted the figures in: --Overview
--requires -Fixed xml2rfc warning with "Open Issues"
---
draft-zyp-json-schema-03.xml | 113 ++++++++++++++++++-----------------
1 file changed, 59 insertions(+), 54 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 35757e4e..f1c6a148 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -124,9 +124,8 @@
for the purpose of describing a resource and determining hyperlinks
within the representation.
-
- An example JSON Schema that describes products might look like:
+ An example JSON Schema that describes products might look like:
-This schema defines the properties of the instance JSON documents and
-their required properties (id, name, and price) as well as an optional
-property (tags). This also defines the link relations of the instance
-JSON documents.
-
+]]>
+
+ This schema defines the properties of the instance JSON documents and
+ their required properties (id, name, and price) as well as an optional
+ property (tags). This also defines the link relations of the instance
+ JSON documents.
+
+
- For this specification, a schema will be used to denote a JSON Schema
- definition, and an instance refers to the JSON object or array that the schema
- will be describing and validating
+ For this specification, schema will be used to denote a JSON Schema
+ definition, and an instance refers to a JSON value that the schema
+ will be describing and validating.
@@ -185,8 +186,8 @@ JSON documents.
in a variety of structures, and JSON is unique in that the structure
of stored data structures often prescribes a non-ambiguous definite
JSON representation. Attempting to force a specific structure is generally
- not viable, and therefore JSON Schema allows for great flexibility
- in the structure of JSON data that it describes.
+ not viable, and therefore JSON Schema allows for a great flexibility
+ in the structure of the JSON data that it describes.
This specification is protocol agnostic.
The underlying protocol (such as HTTP) should sufficiently define the
@@ -234,7 +235,7 @@ Link: ; rel="describedby"
that it is defined by (the instance data SHOULD be valid for those schemas).
Or if the document is a collection of instances, the collection MAY contain
instances from different schemas. When collections contain heterogeneous
- instances, the pathStart attribute MAY be specified in the
+ instances, the "pathStart" attribute MAY be specified in the
schema to disambiguate which schema should be applied for each item in the
collection. However, ultimately, the mechanism for referencing a schema is up to the
media type of the instance documents (if they choose to specify that schemas
@@ -291,8 +292,11 @@ Content-Type: application/json;
+This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
+This attribute can take one of two forms:
+
-A string indicating a primitive or simple type. The following are acceptable strings:
+A string indicating a primitive or simple type. The following are acceptable string values:
Value MUST be a string.
@@ -307,49 +311,52 @@ included in a union, null values are not allowed (the primitives listed above do
If the property is not defined or is not in this list, than any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
-An array with two or more simple type definitions. Each item in the array MUST be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one the simple type definitions in the array, or if it is valid by one of the schemas (or schema referenced by the URI) in the array.
+An array of two or more simple type definitions. Each item in the array MUST be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one of the simple type definitions in the array, or if it is valid by one of the schemas (or a schema referenced by a URI) in the array.
+
+
+For example, a schema that defines if an instance can be a string or a number would be:
-
-
-
-
+
-This is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
-This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value MUST be a schema or a URI referencing a schema. If false is provided, no additional properties are allowed beyond the properties defined in the schema and the super schemas (the schemas that the schema extends). The default value is an empty schema which allows any value for additional properties.
+This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema, a URI referencing a schema, or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
-This MUST be a schema or URI referring to a schema or an array of schemas (schema or URI referring to a schema). When this is an object/schema and the instance value is an array, all the items in the array MUST conform to this schema or schema referenced by the URI. When this is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalItems attribute using the same rules as extra properties for objects. The default value is an empty schema which allows any value for items in the instance array.
+This MUST be a schema or URI referring to a schema or an array of schemas (schema or URI referring to a schema). When this is a schema and the instance value is an array, all the items in the array MUST conform to this schema or schema referenced by the URI. When this is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalItems attribute using the same rules as "additionalProperties" for objects. The default value is an empty schema which allows any value for items in the instance array.
-This provides a definition for additional items in array when tuple definition of the items in an array is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema or a URI referencing a schema to define the type of the additional items.
+This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema (or a URI referencing a schema) that defines the schema of the additional items.This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
-This attribute indicates that if this property is present in the containing instance object, the property given by requires attribute MUST also be present in the containing instance object. The value
-of this property MAY be a string, indicating the require property name. Or the value MAY be a schema or a URI referencing a schema, in which case the containing instance MUST be valid by the schema if the property is present. For example if a object type definition is defined:
+If this attribute value is a string, then the containing/parent object of the validating instance MUST have a property with a name of the attribute value in order to validate.
+If this attribute value is a schema, then the containing/parent object of the validating instance MUST be validated against the provided schema.
+ For example, for the following schema:
+An instance MUST include a state property if a town property is included. If a town property is not included, the state property is optional.
-An instance MUST include a state property if a town property is included. If a town property is not included, the state property is optional.This attribute defines the minimum value of the instance property when the type of the instance value is a number.
@@ -381,7 +388,7 @@ of this property MAY be a string, indicating the require property name. Or the v
When the instance value is a string, this defines the minimum length of the string.
-This provides an enumeration of possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid.
+This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid.This attribute is a string that provides a short description of the instance property.
@@ -390,7 +397,7 @@ of this property MAY be a string, indicating the require property name. Or the v
This attribute is a string that provides a full description of the of purpose the instance property.
-This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are predefined:This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
@@ -408,13 +415,13 @@ of this property MAY be a string, indicating the require property name. Or the v
This SHOULD be a host-name.
-Additional custom formats MAY be defined with a URL to a definition of the format.
+Additional custom formats MAY be referenced with a URI.
-This indicates the maximum number of decimal points.
+This attribute defines the maximum number of decimal points a number instance can have.
-This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, than this instance is not valid.
+This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, than this instance is not valid.The value of this property MUST be another schema or a URI referencing a schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional properties, constrain existing properties, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
@@ -441,7 +448,7 @@ of this property MAY be a string, indicating the require property name. Or the v
This defines the URI of this schema (the target is effectively
-the "self" relation). This MAY be a relative or absolute. If the URI
+a "self" link). This URI MAY be relative or absolute. If the URI
is relative, it SHOULD be resolved against the URI used to retrieve this schema.
@@ -452,7 +459,7 @@ attributes that already provided by the core schema with the specific
purpose of informing user agents of relations between resources based
on JSON data. Just as with JSON
schema attributes, all the attributes in hyper schemas are optional.
-Therefore an empty object is a valid (non-informative) schema, and
+Therefore, an empty object is a valid (non-informative) schema, and
essentially describes plain JSON (no constraints on the structures).
Addition of attributes provides additive information for user agents.
@@ -464,7 +471,7 @@ relations of the instances.
-A link description object is used to describe the link relations. In
+A link description object is used to describe link relations. In
the context of a schema, it defines the link relations of the
instances of the schema, and can be parameterized by the instance
values. The link description format can be used on its own in
@@ -766,24 +773,20 @@ If the instance property value is a string, this attribute defines that the stri
-This property value is a URI-Reference that indicates the URI that all
-the URIs for the instances of the schema MUST start with. When
-multiple schemas have been referenced for an instance, the user agent
+This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
+and is relative to the instance's URI.
+
+
+When multiple schemas have been referenced for an instance, the user agent
can determine if this schema is applicable for a particular instance by
-determining if URI of the instance begins with the pathStart's referenced
-URI. pathStart MUST be resolved as per RFC 3986, Sec 5. If the URI of
-the instance does not start with URI indicated by pathStart, or if another
-schema specifies a starting URI that is longer and also matches the
+determining if the URI of the instance begins with the the value of the "pathStart"
+attribute. If the URI of the instance does not start with this URI,
+or if another schema specifies a starting URI that is longer and also matches the
instance, this schema SHOULD NOT be applied to the instance. Any schema
that does not have a pathStart attribute SHOULD be considered applicable
to all the instances for which it is referenced.
-
-If this URI is relative, it should be resolved against the instance's URI.
-
-
-
-
@@ -967,12 +970,14 @@ instead of numbers
+ Should we give a preference to MIME headers over Link headers (or only use one)?Should "root" be a MIME parameter?Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?How should dates be handled?
+
From 56205ded14c2035649a1e44bdc4d3d468041d00d Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Wed, 27 Oct 2010 21:28:52 -0600
Subject: [PATCH 0011/1659] fix some wording
---
draft-zyp-json-schema-03.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 35757e4e..b7e4a059 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -534,7 +534,7 @@ This indicates the target of the link is the schema for the instance object. Thi
This relation indicates that the target of the link
SHOULD be treated as the root or the body of the representation for the
purposes of user agent interaction or fragment resolution. All other
-properties of the instance objects are can be regarded as meta-data
+properties of the instance objects can be regarded as meta-data
descriptions for the data.
From d3280375c8cdf338825f74c9678631442ec4493b Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Wed, 27 Oct 2010 21:29:02 -0600
Subject: [PATCH 0012/1659] Update to latest AMD spec
---
lib/links.js | 4 ++--
lib/validate.js | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/links.js b/lib/links.js
index 9736c301..d44e8dd9 100644
--- a/lib/links.js
+++ b/lib/links.js
@@ -3,8 +3,8 @@
* Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
* Licensed under the MIT (MIT-LICENSE.txt) license.
*/
-require.def||(require.def=function(deps, factory){module.exports = factory();});
-require.def([], function(){
+define||(define=function(deps, factory){module.exports = factory();});
+define([], function(){
var exports = {};
exports.cacheLinks = true;
exports.getLink = function(relation, instance, schema){
diff --git a/lib/validate.js b/lib/validate.js
index a68bd500..94f32808 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -13,8 +13,8 @@ empty list will be returned. A validation error will have two properties:
"property" which indicates which property had the error
"message" which indicates what the error was
*/
-require.def||(require.def=function(deps, factory){module.exports = factory();});
-require.def([], function(){
+define||(define=function(deps, factory){module.exports = factory();});
+define([], function(){
var exports = validate;
// setup primitive classes to be JSON Schema types
String.type = "string";
From 9c541343edb1cff6169cd209b9cf00ad2b31f2bd Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 28 Oct 2010 17:17:43 -0600
Subject: [PATCH 0013/1659] Fix boilerplate
---
lib/links.js | 2 +-
lib/validate.js | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/links.js b/lib/links.js
index d44e8dd9..5b1bbbfd 100644
--- a/lib/links.js
+++ b/lib/links.js
@@ -3,7 +3,7 @@
* Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
* Licensed under the MIT (MIT-LICENSE.txt) license.
*/
-define||(define=function(deps, factory){module.exports = factory();});
+({define:typeof define!="undefined"?define:function(deps, factory){module.exports = factory();}}).
define([], function(){
var exports = {};
exports.cacheLinks = true;
diff --git a/lib/validate.js b/lib/validate.js
index 94f32808..44e0c4a9 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -13,7 +13,7 @@ empty list will be returned. A validation error will have two properties:
"property" which indicates which property had the error
"message" which indicates what the error was
*/
-define||(define=function(deps, factory){module.exports = factory();});
+({define:typeof define!="undefined"?define:function(deps, factory){module.exports = factory();}}).
define([], function(){
var exports = validate;
// setup primitive classes to be JSON Schema types
From 36c25b7a404b04d95e151cdfb48f0f59d74f1bd5 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Fri, 29 Oct 2010 17:17:09 -0600
Subject: [PATCH 0014/1659] Added "patternProperties" attribute.
---
draft-zyp-json-schema-03.xml | 5 ++++-
schema | 6 ++++++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index a6323dcd..d3f6aaa4 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -325,6 +325,9 @@ If the property is not defined or is not in this list, than any type of value is
This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema or URI reference to a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema, a URI referencing a schema, or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
@@ -942,7 +945,7 @@ instead of numbers
Added "additionalItems" attribute.Added "id" attribute.Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
-
+ Added "patternProperties" attribute.
diff --git a/schema b/schema
index dd0d1cee..21321333 100644
--- a/schema
+++ b/schema
@@ -30,6 +30,12 @@
"default" : false
},
+ "patternProperties" : {
+ "type" : "object",
+ "additionalProperties" : "#",
+ "default" : {}
+ },
+
"additionalProperties" : {
"type" : ["#", "boolean"],
"default" : {}
From 300bf9de10427adc6558441a2c3baee2ec165d19 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Fri, 29 Oct 2010 17:52:12 -0600
Subject: [PATCH 0015/1659] Replaced the "requires" attribute with the
"dependencies" attribute.
---
draft-zyp-json-schema-03.xml | 30 ++++++++++--------------------
schema | 11 +++++++++--
2 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index a6323dcd..59df0706 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -337,26 +337,15 @@ If the property is not defined or is not in this list, than any type of value is
This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
-
-If this attribute value is a string, then the containing/parent object of the validating instance MUST have a property with a name of the attribute value in order to validate.
-If this attribute value is a schema, then the containing/parent object of the validating instance MUST be validated against the provided schema.
-
- For example, for the following schema:
-
-An instance MUST include a state property if a town property is included. If a town property is not included, the state property is optional.
-
+
+This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
+
+The dependency value can take one of two forms:
+
+If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
+If the dependency value is a schema, then the instance object MUST be valid against the schema.
+
+This attribute defines the minimum value of the instance property when the type of the instance value is a number.
@@ -938,6 +927,7 @@ instead of numbersReplaced "optional" attribute with "required" attribute.Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
+ Replaced "requires" attribute with "dependencies" attribute.Moved "default" and "contentEncoding" attributes to hyper schemaAdded "additionalItems" attribute.Added "id" attribute.
diff --git a/schema b/schema
index dd0d1cee..e003d849 100644
--- a/schema
+++ b/schema
@@ -39,8 +39,15 @@
"default" : {}
},
- "requires" : {
- "type" : ["string", "#"]
+ "dependencies" : {
+ "type" : "object",
+ "additionalProperties" : {
+ "type" : ["array", "#"],
+ "items" : {
+ "type" : "string"
+ }
+ },
+ "default" : {}
},
"minimum" : {
From cf472d8425b3732be7075f257faf767db35016f9 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Wed, 3 Nov 2010 08:39:05 -0600
Subject: [PATCH 0016/1659] Some language corrections
---
draft-zyp-json-schema-03.xml | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 8d447710..5b741a81 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -308,8 +308,9 @@ This attribute can take one of two forms:
Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).Value MAY be of any type including null.
-If the property is not defined or is not in this list, than any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+If the property is not defined or is not in this list, then any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
An array of two or more simple type definitions. Each item in the array MUST be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one of the simple type definitions in the array, or if it is valid by one of the schemas (or a schema referenced by a URI) in the array.
@@ -413,7 +414,7 @@ The dependency value can take one of two forms:
This attribute defines the maximum number of decimal points a number instance can have.
-This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, than this instance is not valid.
+This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, then this instance is not valid.The value of this property MUST be another schema or a URI referencing a schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional properties, constrain existing properties, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
@@ -504,7 +505,7 @@ URI would be:
http://somesite.com/45
]]>
-If matching braces are found with the string "@" (no quotes) between the braces, than the
+If matching braces are found with the string "@" (no quotes) between the braces, then the
actual instance value SHOULD be used to replace the braces, rather than a property value.
This should only be used in situations where the instance is a scalar (string,
boolean, or number), and not for objects or arrays.
@@ -693,7 +694,7 @@ the fragment identifier, as a path reference in the target JSON
structure. The final target value of the fragment can be determined by
starting with the root of the JSON structure from the representation of
the resource identified by the pre-fragment URI. If the target is a JSON
-object, than the new target is the value of the property with the name
+object, then the new target is the value of the property with the name
identified by the next property reference token in the fragment. If the
target is a JSON array, than the target is determined by finding the
item in array the array with the index defined by the next property
From e0868ccbab36cd73c8b7dd76853a92edafc52845 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Sun, 7 Nov 2010 21:54:10 -0700
Subject: [PATCH 0017/1659] Updated specification to include fixes from the
community: -Fixed examples -"uniqueItems" now enforces array and object
items, defined algorithm -Moved "default" back to core schema -Tweaked
wording in "format" -Re-replaced "maxDecimal" with "divisibleBy" -Tweaked
wording in hyper-schema "properties". Removed vague sentence regarding forms
(this can be re-added when a better description is defined).
---
draft-zyp-json-schema-03.xml | 62 ++++++++++++++++++++----------------
hyper-schema | 3 --
schema | 9 ++++++
3 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 5b741a81..646ab413 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -132,18 +132,20 @@
"properties":{
"id":{
"type":"number",
- "description":"Product identifier"
+ "description":"Product identifier",
+ "required":true
},
"name":{
"description":"Name of the product",
- "type":"string"
+ "type":"string",
+ "required":true
},
"price":{
"type": "number",
- "minimum":0
+ "minimum":0,
+ "required":true
},
"tags":{
- "optional":true,
"type":"array",
"items":{
"type":"string"
@@ -163,8 +165,8 @@
}
]]>
- This schema defines the properties of the instance JSON documents and
- their required properties (id, name, and price) as well as an optional
+ This schema defines the properties of the instance JSON documents,
+ the required properties (id, name, and price), as well as an optional
property (tags). This also defines the link relations of the instance
JSON documents.
@@ -279,8 +281,10 @@ Content-Type: application/json;
"properties":{
"name":{"type":"string"},
- "age" :{"type":"integer"},
- "maximum":125
+ "age" :{
+ "type":"integer",
+ "maximum":125
+ }
}
}
]]>
@@ -323,7 +327,7 @@ If the property is not defined or is not in this list, then any type of value is
]]>
-
+This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
@@ -369,8 +373,16 @@ The dependency value can take one of two forms:
This attribute defines the maximum number of values in an array when the array is the instance value.
-
-This attribute indicates that all the items in an array MUST be unique (no two identical values) within that array when the array is the instance value. Uniqueness is only defined for primitive types: strings, numbers, booleans, and nulls.
+
+This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
+Two instance are consider equal if they are both of the same type and:
+
+are null; or
+are booleans/numbers/strings and have the same value; or
+are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
+
+When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
@@ -381,7 +393,10 @@ The dependency value can take one of two forms:
When the instance value is a string, this defines the minimum length of the string.
-This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid.
+This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+
+This attribute defines the default value of the instance when the instance is undefined.This attribute is a string that provides a short description of the instance property.
@@ -390,7 +405,7 @@ The dependency value can take one of two forms:
This attribute is a string that provides a full description of the of purpose the instance property.
-This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are predefined:
+This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format. The following formats are predefined:This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
@@ -408,10 +423,10 @@ The dependency value can take one of two forms:
This SHOULD be a host-name.
-Additional custom formats MAY be referenced with a URI.
+Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
-
-This attribute defines the maximum number of decimal points a number instance can have.
+
+This attribute defines what value the number instance must be divisible by with no remainder. (The result of the division must be an integer.)This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, then this instance is not valid.
@@ -658,12 +673,10 @@ the default media type.
-This is inherited from the base JSON schema definition, and can follow the
-same structure, but its meaning SHOULD be used to define the acceptable
+This attribute has the same structure as the core JSON Schema "properties" attribute,
+but its meaning SHOULD be used to define the acceptable
property names and values for the action (whether it be for the GET query
-or POST body). If properties are omitted, and this form is the child of a
-schema, the properties from the parent schema SHOULD be used as the basis
-for the form action.
+or POST body).
@@ -760,10 +773,6 @@ If the instance property value is a string, this attribute defines that the stri
-
-This attribute defines the default value of the instance when the instance is undefined.
-
-
This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
@@ -927,12 +936,11 @@ instead of numbersAdded more explanation of nullability.Removed "alternate" attribute.Upper cased many normative usages of must, may, and should.
- Replaced "divisibleBy" attribute with "maxDecimal" attribute.Replaced "optional" attribute with "required" attribute.Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.Replaced "requires" attribute with "dependencies" attribute.
- Moved "default" and "contentEncoding" attributes to hyper schema
+ Moved "contentEncoding" attribute to hyper schema.Added "additionalItems" attribute.Added "id" attribute.Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
diff --git a/hyper-schema b/hyper-schema
index 3fedec1e..5604ab67 100644
--- a/hyper-schema
+++ b/hyper-schema
@@ -69,9 +69,6 @@
"type" : "string"
},
- "default" : {
- },
-
"requires" : {
"type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
},
diff --git a/schema b/schema
index d54751a9..c8a68e2d 100644
--- a/schema
+++ b/schema
@@ -108,6 +108,10 @@
"uniqueItems" : true
},
+ "default" : {
+ "type" : "any"
+ },
+
"title" : {
"type" : "string"
},
@@ -137,6 +141,11 @@
"type" : ["#", "array"],
"items" : "#",
"default" : {}
+ },
+
+ "id" : {
+ "type" : "string",
+ "format" : "uri"
}
},
"links" : [
From d1b68f87c4cba23d4a003f369fa7d9e3f24f3547 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Mon, 8 Nov 2010 07:53:10 -0700
Subject: [PATCH 0018/1659] Fixed some typos/errors
---
draft-zyp-json-schema-03.xml | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 5b741a81..a26da31d 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -139,11 +139,11 @@
"type":"string"
},
"price":{
+ "required":true,
"type": "number",
"minimum":0
},
"tags":{
- "optional":true,
"type":"array",
"items":{
"type":"string"
@@ -279,8 +279,7 @@ Content-Type: application/json;
"properties":{
"name":{"type":"string"},
- "age" :{"type":"integer"},
- "maximum":125
+ "age" :{"type":"integer", "maximum":125},
}
}
]]>
From f2f4141c0234935d84492ca012ba371783b8f43e Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Mon, 8 Nov 2010 22:10:47 -0700
Subject: [PATCH 0019/1659] Removed schemas-can-be-URI references. Tweaked the
wording in "items"
---
draft-zyp-json-schema-03.xml | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index d76493dc..497e958f 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -264,14 +264,9 @@ Content-Type: application/json;
A JSON Schema is a JSON Object that defines various attributes
- of the instance and defines it's usage and valid values. JSON
+ (including usage and valid values) of a JSON value. JSON
Schema has recursive capabilities; there are a number of elements
- in the structure that allow for a nested JSON Schema or URI
- referencing a schema. Schema referencing URIs can be relative
- or absolute and the target of the URI SHOULD be treated as
- the schema for the given element in the schema structure.
-
-
+ in the structure that allow for nested JSON Schemas.
An example JSON Schema definition could look like:
@@ -317,7 +312,7 @@ included in a union, null values are not allowed (the primitives listed above do
If the property is not defined or is not in this list, then any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
-An array of two or more simple type definitions. Each item in the array MUST be a simple type definition, a schema, or a URI for a schema. The instance value is valid if it is of the same type as one of the simple type definitions in the array, or if it is valid by one of the schemas (or a schema referenced by a URI) in the array.
+An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema. The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
@@ -329,19 +324,21 @@ If the property is not defined or is not in this list, then any type of value is
-This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema or URI referring to a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
-This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema or URI reference to a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
-
-This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema, a URI referencing a schema, or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
+
+This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
-This MUST be a schema or URI referring to a schema or an array of schemas (schema or URI referring to a schema). When this is a schema and the instance value is an array, all the items in the array MUST conform to this schema or schema referenced by the URI. When this is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalItems attribute using the same rules as "additionalProperties" for objects. The default value is an empty schema which allows any value for items in the instance array.
+This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
+When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
+When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
-
-This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema (or a URI referencing a schema) that defines the schema of the additional items.
+
+This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
@@ -430,10 +427,10 @@ The dependency value can take one of two forms:
This attribute defines what value the number instance must be divisible by with no remainder. (The result of the division must be an integer.)
-This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema or a URI referencing a schema in the array, then this instance is not valid.
+This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-The value of this property MUST be another schema or a URI referencing a schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional properties, constrain existing properties, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
+The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
-This defines the URI of this schema (the target is effectively
+This defines the URI of this schema (this attribute is effectively
a "self" link). This URI MAY be relative or absolute. If the URI
is relative, it SHOULD be resolved against the URI used to retrieve this schema.
@@ -929,7 +926,6 @@ instead of numbers
- Defined referencing schemas by URI for all elements that accept schemas.Added example and verbiage to "extends" attribute.Defined slash-delimited to use a leading slash.Made "root" a relation instead of an attribute.
From d8828328fe9dcf7ec779e83d22b2199decd9d256 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 11 Nov 2010 13:56:08 -0700
Subject: [PATCH 0020/1659] Check for coerce property
---
lib/validate.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 44e0c4a9..fc02a9b9 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -194,7 +194,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
if(value === undefined && propDef["default"]){
value = instance[i] = propDef["default"];
}
- if(exports.coerce){
+ if(propDef.coerce && exports.coerce && i in instance){
value = instance[i] = exports.coerce(value, propDef);
}
checkProp(value,propDef,path,i);
@@ -212,7 +212,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
value = instance[i];
if(additionalProp && (!(objTypeDef && typeof objTypeDef == 'object') || !(i in objTypeDef))){
- if(exports.coerce){
+ if(additionalProp.coerce && exports.coerce){
value = instance[i] = exports.coerce(value, additionalProp);
}
checkProp(value,additionalProp,path,i);
From 8c1e8af3bbfe054271c8563009a7d19b5ab04455 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Thu, 11 Nov 2010 18:37:55 -0700
Subject: [PATCH 0021/1659] Schema URIs are now namespace versioned. Added
simple string format for the "dependencies" attribute. Added "$ref" and
"$schema" attribute definitions.
---
address | 12 --
calendar | 20 ---
card | 43 ------
draft-00/hyper-schema | 68 +++++++++
json-ref => draft-00/json-ref | 8 +-
draft-00/links | 33 ++++
draft-00/schema | 155 +++++++++++++++++++
draft-01/hyper-schema | 68 +++++++++
draft-01/json-ref | 26 ++++
draft-01/links | 33 ++++
draft-01/schema | 155 +++++++++++++++++++
draft-02/hyper-schema | 68 +++++++++
draft-02/json-ref | 26 ++++
draft-02/links | 35 +++++
draft-02/schema | 166 +++++++++++++++++++++
draft-03/examples/address | 20 +++
draft-03/examples/calendar | 53 +++++++
draft-03/examples/card | 105 +++++++++++++
draft-03/examples/geo | 8 +
interfaces => draft-03/examples/interfaces | 4 +-
draft-03/hyper-schema | 60 ++++++++
draft-03/json-ref | 26 ++++
draft-03/links | 35 +++++
schema => draft-03/schema | 87 ++++++-----
draft-zyp-json-schema-03.xml | 49 ++++--
geo | 7 -
hyper-schema | 104 -------------
links | 34 -----
28 files changed, 1231 insertions(+), 277 deletions(-)
delete mode 100644 address
delete mode 100644 calendar
delete mode 100644 card
create mode 100644 draft-00/hyper-schema
rename json-ref => draft-00/json-ref (55%)
create mode 100644 draft-00/links
create mode 100644 draft-00/schema
create mode 100644 draft-01/hyper-schema
create mode 100644 draft-01/json-ref
create mode 100644 draft-01/links
create mode 100644 draft-01/schema
create mode 100644 draft-02/hyper-schema
create mode 100644 draft-02/json-ref
create mode 100644 draft-02/links
create mode 100644 draft-02/schema
create mode 100644 draft-03/examples/address
create mode 100644 draft-03/examples/calendar
create mode 100644 draft-03/examples/card
create mode 100644 draft-03/examples/geo
rename interfaces => draft-03/examples/interfaces (91%)
create mode 100644 draft-03/hyper-schema
create mode 100644 draft-03/json-ref
create mode 100644 draft-03/links
rename schema => draft-03/schema (62%)
delete mode 100644 geo
delete mode 100644 hyper-schema
delete mode 100644 links
diff --git a/address b/address
deleted file mode 100644
index c553848c..00000000
--- a/address
+++ /dev/null
@@ -1,12 +0,0 @@
-{"description":"An Address following the convention of http://microformats.org/wiki/hcard",
- "type":"object",
- "properties":{
- "post-office-box":{"type":"string","requires":"street-address"},
- "extended-address":{"type":"string","requires":"street-address"},
- "street-address":{"type":"string","requires":"region"},
- "locality":{"type":"string","requires":"region", "required":true},
- "region":{"type":"string","requires":"country-name", "required":true},
- "postal-code":{"type":"string"},
- "country-name":{"type":"string", "required":true}
- }
-}
\ No newline at end of file
diff --git a/calendar b/calendar
deleted file mode 100644
index 9b02c4d7..00000000
--- a/calendar
+++ /dev/null
@@ -1,20 +0,0 @@
-{"description":"A representation of an event",
- "type":"object",
- "properties":{
- "dtstart":{"format":"date-time","type":"string","description":"Event starting time","required":true},
- "summary":{"type":"string","required":true},
- "location":{"type":"string"},
- "url":{"type":"string","format":"url"},
- "dtend":{"format":"date-time","type":"string","description":"Event ending time"},
- "duration":{"format":"date","type":"string","description":"Event duration"},
- "rdate":{"format":"date-time","type":"string","description":"Recurrence date"},
- "rrule":{"type":"string","description":"Recurrence rule"},
- "category":{"type":"string"},
- "description":{"type":"string"},
- "geo":"http://json-schema.org/geo"
- }
-}
-
-
-
-
diff --git a/card b/card
deleted file mode 100644
index ba47d78b..00000000
--- a/card
+++ /dev/null
@@ -1,43 +0,0 @@
-{"description":"A representation of a person, company, organization, or place",
- "type":"object",
- "properties":{
- "fn":{"description":"Formatted Name","type":"string"},
- "familyName":{"type":"string", "required":true},
- "givenName":{"type":"string", "required":true},
- "additionalName":{"type":"array","items":{"type":"string"}},
- "honorificPrefix":{"type":"array","items":{"type":"string"}},
- "honorificSuffix":{"type":"array","items":{"type":"string"}},
- "nickname":{"type":"string"},
- "url":{"type":"string","format":"url"},
- "email":{
- "type":"object",
- "properties":{
- "type":{"type":"string"},
- "value":{"type":"string","format":"email"}},
- },
- "tel":{
- "type":"object",
- "properties":{
- "type":{"type":"string"},
- "value":{"type":"string","format":"phone"}},
- },
- "adr":"http://json-schema.org/address",
- "geo":"http://json-schema.org/geo",
- "tz":{"type":"string"},
- "photo":{"format":"image","type":"string"},
- "logo":{"format":"image","type":"string"},
- "sound":{"format":"attachment","type":"string"},
- "bday":{"type":"string","format":"date"},
- "title":{"type":"string"},
- "role":{"type":"string"},
- "org":{"type":"object",
- "properties":{
- "organizationName":{"type":"string"},
- "organizationUnit":{"type":"string"}},
- }
- }
-}
-
-
-
-
diff --git a/draft-00/hyper-schema b/draft-00/hyper-schema
new file mode 100644
index 00000000..de80b918
--- /dev/null
+++ b/draft-00/hyper-schema
@@ -0,0 +1,68 @@
+{
+ "$schema" : "http://json-schema.org/draft-00/hyper-schema#",
+ "id" : "http://json-schema.org/draft-00/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/draft-00/links#"},
+ "optional" : true
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "optional" : true,
+ "default" : "dot-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : {"$ref" : "#"},
+ "optional" : true
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited",
+ "extends" : {"$ref" : "http://json-schema.org/draft-00/schema#"}
+}
\ No newline at end of file
diff --git a/json-ref b/draft-00/json-ref
similarity index 55%
rename from json-ref
rename to draft-00/json-ref
index 323df0c6..3a872a71 100644
--- a/json-ref
+++ b/draft-00/json-ref
@@ -1,9 +1,9 @@
{
- "$schema" : "http://json-schema.org/hyper-schema",
- "id" : "http://json-schema.org/json-ref",
+ "$schema" : "http://json-schema.org/draft-00/hyper-schema#",
+ "id" : "http://json-schema.org/draft-00/json-ref#",
- "items" : "#",
- "additionalProperties" : "#",
+ "items" : {"$ref" : "#"},
+ "additionalProperties" : {"$ref" : "#"},
"links" : [
{
diff --git a/draft-00/links b/draft-00/links
new file mode 100644
index 00000000..8a5e7807
--- /dev/null
+++ b/draft-00/links
@@ -0,0 +1,33 @@
+{
+ "$schema" : "http://json-schema.org/draft-00/hyper-schema#",
+ "id" : "http://json-schema.org/draft-00/links#",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string"
+ },
+
+ "rel" : {
+ "type" : "string"
+ },
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET",
+ "optional" : true
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method",
+ "optional" : true
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/draft-00/hyper-schema#"},
+ "optional" : true
+ }
+ }
+}
\ No newline at end of file
diff --git a/draft-00/schema b/draft-00/schema
new file mode 100644
index 00000000..9aa2fbc5
--- /dev/null
+++ b/draft-00/schema
@@ -0,0 +1,155 @@
+{
+ "$schema" : "http://json-schema.org/draft-00/hyper-schema#",
+ "id" : "http://json-schema.org/draft-00/schema#",
+ "type" : "object",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "optional" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "optional" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "optional" : true,
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", {"$ref" : "#"}],
+ "optional" : true
+ },
+
+ "minimum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "maximum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "minimumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "minimum",
+ "default" : true
+ },
+
+ "maximumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "maximum",
+ "default" : true
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer",
+ "optional" : true
+ },
+
+ "enum" : {
+ "type" : "array",
+ "optional" : true,
+ "minItems" : 1
+ },
+
+ "title" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "description" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "format" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "contentEncoding" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "default" : {
+ "type" : "any",
+ "optional" : true
+ },
+
+ "maxDecimal" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0
+ },
+
+ "disallow" : {
+ "type" : ["string", "array"],
+ "items" : {"type" : "string"},
+ "optional" : true
+ },
+
+ "extends" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ }
+ },
+
+ "optional" : true,
+ "default" : {}
+}
\ No newline at end of file
diff --git a/draft-01/hyper-schema b/draft-01/hyper-schema
new file mode 100644
index 00000000..3f6c6cc2
--- /dev/null
+++ b/draft-01/hyper-schema
@@ -0,0 +1,68 @@
+{
+ "$schema" : "http://json-schema.org/draft-01/hyper-schema#",
+ "id" : "http://json-schema.org/draft-01/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/draft-01/links#"},
+ "optional" : true
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "optional" : true,
+ "default" : "dot-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : {"$ref" : "#"},
+ "optional" : true
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited",
+ "extends" : {"$ref" : "http://json-schema.org/draft-01/schema#"}
+}
\ No newline at end of file
diff --git a/draft-01/json-ref b/draft-01/json-ref
new file mode 100644
index 00000000..4d26174e
--- /dev/null
+++ b/draft-01/json-ref
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/draft-01/hyper-schema#",
+ "id" : "http://json-schema.org/draft-01/json-ref#",
+
+ "items" : {"$ref" : "#"},
+ "additionalProperties" : {"$ref" : "#"},
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/draft-01/links b/draft-01/links
new file mode 100644
index 00000000..52430a5d
--- /dev/null
+++ b/draft-01/links
@@ -0,0 +1,33 @@
+{
+ "$schema" : "http://json-schema.org/draft-01/hyper-schema#",
+ "id" : "http://json-schema.org/draft-01/links#",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string"
+ },
+
+ "rel" : {
+ "type" : "string"
+ },
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET",
+ "optional" : true
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method",
+ "optional" : true
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/draft-01/hyper-schema#"},
+ "optional" : true
+ }
+ }
+}
\ No newline at end of file
diff --git a/draft-01/schema b/draft-01/schema
new file mode 100644
index 00000000..7a208e68
--- /dev/null
+++ b/draft-01/schema
@@ -0,0 +1,155 @@
+{
+ "$schema" : "http://json-schema.org/draft-01/hyper-schema#",
+ "id" : "http://json-schema.org/draft-01/schema#",
+ "type" : "object",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "optional" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "optional" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "optional" : true,
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", {"$ref" : "#"}],
+ "optional" : true
+ },
+
+ "minimum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "maximum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "minimumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "minimum",
+ "default" : true
+ },
+
+ "maximumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "maximum",
+ "default" : true
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer",
+ "optional" : true
+ },
+
+ "enum" : {
+ "type" : "array",
+ "optional" : true,
+ "minItems" : 1
+ },
+
+ "title" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "description" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "format" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "contentEncoding" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "default" : {
+ "type" : "any",
+ "optional" : true
+ },
+
+ "maxDecimal" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0
+ },
+
+ "disallow" : {
+ "type" : ["string", "array"],
+ "items" : {"type" : "string"},
+ "optional" : true
+ },
+
+ "extends" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ }
+ },
+
+ "optional" : true,
+ "default" : {}
+}
\ No newline at end of file
diff --git a/draft-02/hyper-schema b/draft-02/hyper-schema
new file mode 100644
index 00000000..4ec1b756
--- /dev/null
+++ b/draft-02/hyper-schema
@@ -0,0 +1,68 @@
+{
+ "$schema" : "http://json-schema.org/draft-02/hyper-schema#",
+ "id" : "http://json-schema.org/draft-02/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/draft-02/links#"},
+ "optional" : true
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "optional" : true,
+ "default" : "slash-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : {"$ref" : "#"},
+ "optional" : true
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "slash-delimited",
+ "extends" : {"$ref" : "http://json-schema.org/draft-02/schema#"}
+}
\ No newline at end of file
diff --git a/draft-02/json-ref b/draft-02/json-ref
new file mode 100644
index 00000000..6526c394
--- /dev/null
+++ b/draft-02/json-ref
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/draft-02/hyper-schema#",
+ "id" : "http://json-schema.org/draft-02/json-ref#",
+
+ "items" : {"$ref" : "#"},
+ "additionalProperties" : {"$ref" : "#"},
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/draft-02/links b/draft-02/links
new file mode 100644
index 00000000..1b176178
--- /dev/null
+++ b/draft-02/links
@@ -0,0 +1,35 @@
+{
+ "$schema" : "http://json-schema.org/draft-02/hyper-schema#",
+ "id" : "http://json-schema.org/draft-02/links#",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string"
+ },
+
+ "rel" : {
+ "type" : "string"
+ },
+
+ "targetSchema" : {"$ref" : "http://json-schema.org/draft-02/hyper-schema#"},
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET",
+ "optional" : true
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method",
+ "optional" : true
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/draft-02/hyper-schema#"},
+ "optional" : true
+ }
+ }
+}
\ No newline at end of file
diff --git a/draft-02/schema b/draft-02/schema
new file mode 100644
index 00000000..61b8de15
--- /dev/null
+++ b/draft-02/schema
@@ -0,0 +1,166 @@
+{
+ "$schema" : "http://json-schema.org/draft-02/hyper-schema#",
+ "id" : "http://json-schema.org/draft-02/schema#",
+ "type" : "object",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "optional" : true,
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "optional" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "optional" : true,
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", {"$ref" : "#"}],
+ "optional" : true
+ },
+
+ "minimum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "maximum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "minimumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "minimum",
+ "default" : true
+ },
+
+ "maximumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "maximum",
+ "default" : true
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0
+ },
+
+ "uniqueItems" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer",
+ "optional" : true
+ },
+
+ "enum" : {
+ "type" : "array",
+ "optional" : true,
+ "minItems" : 1,
+ "uniqueItems" : true
+ },
+
+ "title" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "description" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "format" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "contentEncoding" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "default" : {
+ "type" : "any",
+ "optional" : true
+ },
+
+ "divisibleBy" : {
+ "type" : "number",
+ "minimum" : 0,
+ "minimumCanEqual" : false,
+ "optional" : true,
+ "default" : 1
+ },
+
+ "disallow" : {
+ "type" : ["string", "array"],
+ "items" : {"type" : "string"},
+ "optional" : true,
+ "uniqueItems" : true
+ },
+
+ "extends" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ }
+ },
+
+ "optional" : true,
+ "default" : {}
+}
\ No newline at end of file
diff --git a/draft-03/examples/address b/draft-03/examples/address
new file mode 100644
index 00000000..074d34e8
--- /dev/null
+++ b/draft-03/examples/address
@@ -0,0 +1,20 @@
+{
+ "description" : "An Address following the convention of http://microformats.org/wiki/hcard",
+ "type" : "object",
+ "properties" : {
+ "post-office-box" : { "type" : "string" },
+ "extended-address" : { "type" : "string" },
+ "street-address" : { "type":"string" },
+ "locality" : { "type" : "string", "required" : true },
+ "region" : { "type" : "string", "required" : true },
+ "postal-code" : { "type" : "string" },
+ "country-name" : { "type" : "string", "required" : true }
+ },
+ "dependencies" : {
+ "post-office-box" : "street-address",
+ "extended-address" : "street-address",
+ "street-address" : "region",
+ "locality" : "region",
+ "region" : "country-name"
+ }
+}
\ No newline at end of file
diff --git a/draft-03/examples/calendar b/draft-03/examples/calendar
new file mode 100644
index 00000000..463cfb31
--- /dev/null
+++ b/draft-03/examples/calendar
@@ -0,0 +1,53 @@
+{
+ "description" : "A representation of an event",
+ "type" : "object",
+ "properties" : {
+ "dtstart" : {
+ "format" : "date-time",
+ "type" : "string",
+ "description" : "Event starting time",
+ "required":true
+ },
+ "summary" : {
+ "type":"string",
+ "required":true
+ },
+ "location" : {
+ "type" : "string"
+ },
+ "url" : {
+ "type" : "string",
+ "format" : "url"
+ },
+ "dtend" : {
+ "format" : "date-time",
+ "type" : "string",
+ "description" : "Event ending time"
+ },
+ "duration" : {
+ "format" : "date",
+ "type" : "string",
+ "description" : "Event duration"
+ },
+ "rdate" : {
+ "format" : "date-time",
+ "type" : "string",
+ "description" : "Recurrence date"
+ },
+ "rrule" : {
+ "type" : "string",
+ "description" : "Recurrence rule"
+ },
+ "category" : {
+ "type" : "string"
+ },
+ "description" : {
+ "type" : "string"
+ },
+ "geo" : { "$ref" : "http://json-schema.org/draft-03/geo" }
+ }
+}
+
+
+
+
diff --git a/draft-03/examples/card b/draft-03/examples/card
new file mode 100644
index 00000000..89287a40
--- /dev/null
+++ b/draft-03/examples/card
@@ -0,0 +1,105 @@
+{
+ "description":"A representation of a person, company, organization, or place",
+ "type":"object",
+ "properties":{
+ "fn":{
+ "description":"Formatted Name",
+ "type":"string"
+ },
+ "familyName":{
+ "type":"string",
+ "required":true
+ },
+ "givenName":{
+ "type":"string",
+ "required":true
+ },
+ "additionalName":{
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ },
+ "honorificPrefix":{
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ },
+ "honorificSuffix":{
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ },
+ "nickname":{
+ "type":"string"
+ },
+ "url":{
+ "type":"string",
+ "format":"url"
+ },
+ "email":{
+ "type":"object",
+ "properties":{
+ "type":{
+ "type":"string"
+ },
+ "value":{
+ "type":"string",
+ "format":"email"
+ }
+ }
+ },
+ "tel":{
+ "type":"object",
+ "properties":{
+ "type":{
+ "type":"string"
+ },
+ "value":{
+ "type":"string",
+ "format":"phone"
+ }
+ }
+ },
+ "adr":{"$ref" : "http://json-schema.org/address"},
+ "geo":{"$ref" : "http://json-schema.org/geo"},
+ "tz":{
+ "type":"string"
+ },
+ "photo":{
+ "format":"image",
+ "type":"string"
+ },
+ "logo":{
+ "format":"image",
+ "type":"string"
+ },
+ "sound":{
+ "format":"attachment",
+ "type":"string"
+ },
+ "bday":{
+ "type":"string",
+ "format":"date"
+ },
+ "title":{
+ "type":"string"
+ },
+ "role":{
+ "type":"string"
+ },
+ "org":{
+ "type":"object",
+ "properties":{
+ "organizationName":{
+ "type":"string"
+ },
+ "organizationUnit":{
+ "type":"string"
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/draft-03/examples/geo b/draft-03/examples/geo
new file mode 100644
index 00000000..73ac7e53
--- /dev/null
+++ b/draft-03/examples/geo
@@ -0,0 +1,8 @@
+{
+ "description" : "A geographical coordinate",
+ "type" : "object",
+ "properties" : {
+ "latitude" : { "type" : "number" },
+ "longitude" : { "type" : "number" }
+ }
+}
\ No newline at end of file
diff --git a/interfaces b/draft-03/examples/interfaces
similarity index 91%
rename from interfaces
rename to draft-03/examples/interfaces
index c1c08fc3..288a1985 100644
--- a/interfaces
+++ b/draft-03/examples/interfaces
@@ -12,10 +12,10 @@
"parameters":{
"type":"array",
"description":"The set of parameters that should be passed to the method when it is called",
- "items":"#",
+ "items":{"$ref":"#"},
"required": true
},
- "returns":"#"
+ "returns":{"$ref":"#"}
}
}
}
diff --git a/draft-03/hyper-schema b/draft-03/hyper-schema
new file mode 100644
index 00000000..a0e0a350
--- /dev/null
+++ b/draft-03/hyper-schema
@@ -0,0 +1,60 @@
+{
+ "$schema" : "http://json-schema.org/draft-03/hyper-schema#",
+ "extends" : {"$ref" : "http://json-schema.org/draft-03/schema#"}
+ "id" : "http://json-schema.org/draft-03/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/draft-03/links#"}
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "default" : "slash-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "contentEncoding" : {
+ "type" : "string"
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "format" : "media-type"
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ },
+
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ }
+ ],
+
+ "fragmentResolution" : "slash-delimited"
+}
\ No newline at end of file
diff --git a/draft-03/json-ref b/draft-03/json-ref
new file mode 100644
index 00000000..7e491a8e
--- /dev/null
+++ b/draft-03/json-ref
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/draft-03/hyper-schema#",
+ "id" : "http://json-schema.org/draft-03/json-ref#",
+
+ "additionalItems" : {"$ref" : "#"},
+ "additionalProperties" : {"$ref" : "#"},
+
+ "links" : [
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ },
+
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/draft-03/links b/draft-03/links
new file mode 100644
index 00000000..6b0a85a6
--- /dev/null
+++ b/draft-03/links
@@ -0,0 +1,35 @@
+{
+ "$schema" : "http://json-schema.org/draft-03/hyper-schema#",
+ "id" : "http://json-schema.org/draft-03/links#",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string",
+ "required" : true,
+ "format" : "link-description-object-template"
+ },
+
+ "rel" : {
+ "type" : "string",
+ "required" : true
+ },
+
+ "targetSchema" : {"$ref" : "http://json-schema.org/draft-03/hyper-schema#"},
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET"
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/draft-03/hyper-schema#"}
+ }
+ }
+}
\ No newline at end of file
diff --git a/schema b/draft-03/schema
similarity index 62%
rename from schema
rename to draft-03/schema
index c8a68e2d..55ae47d8 100644
--- a/schema
+++ b/draft-03/schema
@@ -1,13 +1,13 @@
{
- "id" : "http://json-schema.org/schema#",
- "type" : ["object","string"],
- "format": "uri",
+ "$schema" : "http://json-schema.org/draft-03/schema#",
+ "id" : "http://json-schema.org/draft-03/schema#",
+ "type" : "object",
"properties" : {
"type" : {
"type" : ["string", "array"],
"items" : {
- "type" : ["string", "#"]
+ "type" : ["string", {"$ref" : "#"}]
},
"uniqueItems" : true,
"default" : "any"
@@ -15,40 +15,41 @@
"properties" : {
"type" : "object",
- "additionalProperties" : "#",
+ "additionalProperties" : {"$ref" : "#"},
"default" : {}
},
- "items" : {
- "type" : ["#", "array"],
- "items" : "#",
- "default" : {}
- },
-
- "required" : {
- "type" : "boolean",
- "default" : false
- },
-
"patternProperties" : {
"type" : "object",
- "additionalProperties" : "#",
+ "additionalProperties" : {"$ref" : "#"},
"default" : {}
},
"additionalProperties" : {
- "type" : ["#", "boolean"],
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
"default" : {}
},
+
"additionalItems" : {
- "type" : ["#", "boolean"],
+ "type" : [{"$ref" : "#"}, "boolean"],
"default" : {}
},
+ "required" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
"dependencies" : {
"type" : "object",
"additionalProperties" : {
- "type" : ["array", "#"],
+ "type" : ["string", "array", {"$ref" : "#"}],
"items" : {
"type" : "string"
}
@@ -65,11 +66,13 @@
},
"exclusiveMinimum" : {
- "type" : "number"
+ "type" : "boolean",
+ "default" : false
},
"exclusiveMaximum" : {
- "type" : "number"
+ "type" : "boolean",
+ "default" : false
},
"minItems" : {
@@ -79,7 +82,8 @@
},
"maxItems" : {
- "type" : "integer"
+ "type" : "integer",
+ "minimum" : 0
},
"uniqueItems" : {
@@ -123,37 +127,48 @@
"format" : {
"type" : "string"
},
-
- "maxDecimal" : {
+
+ "divisibleBy" : {
"type" : "number",
- "minimum" : 0
+ "minimum" : 0,
+ "exclusiveMinimum" : true,
+ "default" : 1
},
"disallow" : {
- "type" : ["string", "array", "#"],
+ "type" : ["string", "array"],
"items" : {
- "type" : ["string", "#"]
+ "type" : ["string", {"$ref" : "#"}]
},
"uniqueItems" : true
},
"extends" : {
- "type" : ["#", "array"],
- "items" : "#",
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
"default" : {}
},
"id" : {
"type" : "string",
"format" : "uri"
+ },
+
+ "$ref" : {
+ "type" : "string",
+ "format" : "uri"
+ },
+
+ "$schema" : {
+ "type" : "string",
+ "format" : "uri"
}
},
- "links" : [
- {
- "href" : "{id}",
- "rel" : "self"
- }
- ],
+
+ "dependencies" : {
+ "exclusiveMinimum" : "minimum",
+ "exclusiveMaximum" : "maximum"
+ },
"default" : {}
}
\ No newline at end of file
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 497e958f..8e184aea 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -246,17 +246,17 @@ collection. However, ultimately, the mechanism for referencing a schema is up to
- JSON Schemas are themselves instances for the schema
- schemas. A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema, while the hyper schema
- self-description can be found at http://json-schema.org/hyper-schema. All schemas
+ JSON Schemas can themselves be described using JSON Schemas.
+ A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/draft-03/schema, while the hyper schema
+ self-description can be found at http://json-schema.org/draft-03/hyper-schema. All schemas
used within a protocol with media type definitions
SHOULD include a MIME parameter that refers to the self-descriptive
hyper schema or another schema that extends this hyper schema:
@@ -348,7 +348,7 @@ If the property is not defined or is not in this list, then any type of value is
The dependency value can take one of two forms:
-If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
+If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value. If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.If the dependency value is a schema, then the instance object MUST be valid against the schema.
@@ -384,12 +384,12 @@ The dependency value can take one of two forms:
When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
-When the instance value is a string, this defines the maximum length of the string.
-When the instance value is a string, this defines the minimum length of the string.
+
+When the instance value is a string, this defines the maximum length of the string.
+This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
@@ -444,7 +444,7 @@ The dependency value can take one of two forms:
{
"description":"Extended schema",
"properties":{"deprecated":{"type": "boolean"}},
- "extends":"http://json-schema.org/schema"
+ "extends":"http://json-schema.org/draft-03/schema"
}
]]>
@@ -453,13 +453,30 @@ The dependency value can take one of two forms:
-This defines the URI of this schema (this attribute is effectively
+This attribute defines the URI of this schema (this attribute is effectively
a "self" link). This URI MAY be relative or absolute. If the URI
is relative, it SHOULD be resolved against the URI used to retrieve this schema.
+
+
+
+This attribute defines a URI of a schema that contains the full representation of this schema.
+When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
+This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+This attribute defines a URI of a JSON Schema that is the schema of the current schema.
+When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+
+A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
+Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
+
-
+The following attributes are specified in addition to those
attributes that already provided by the core schema with the specific
purpose of informing user agents of relations between resources based
@@ -469,7 +486,7 @@ Therefore, an empty object is a valid (non-informative) schema, and
essentially describes plain JSON (no constraints on the structures).
Addition of attributes provides additive information for user agents.
-
+
The value of the links property MUST be an array, where each item
in the array is a link description object which describes the link
@@ -484,7 +501,7 @@ values. The link description format can be used on its own in
regular (non-schema documents), and use of this format can
be declared by referencing the normative link description
schema as the the schema for the data structure that uses the
-links. The URI of the normative link description schema is: http://json-schema.org/links.
+links. The URI of the normative link description schema is: http://json-schema.org/draft-03/links.
@@ -863,7 +880,7 @@ Content-Type: application/json; profile=/schema-for-this-data
The value of the profile parameter SHOULD be a URI (relative or absolute) that
refers to the schema used to define the structure of this structure (the
- meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
but it is allowable to use other schemas that extend the hyper schema's meta-
schema.
@@ -942,6 +959,8 @@ instead of numbersAdded "id" attribute.Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
diff --git a/geo b/geo
deleted file mode 100644
index 73a9851b..00000000
--- a/geo
+++ /dev/null
@@ -1,7 +0,0 @@
-{"description":"A geographical coordinate",
- "type":"object",
- "properties":{
- "latitude":{"type":"number"},
- "longitude":{"type":"number"}
- }
-}
\ No newline at end of file
diff --git a/hyper-schema b/hyper-schema
deleted file mode 100644
index 5604ab67..00000000
--- a/hyper-schema
+++ /dev/null
@@ -1,104 +0,0 @@
-{
- "id" : "http://json-schema.org/hyper-schema",
-
- "properties" : {
- "links" : {
- "type" : "array",
- "items" : "http://json-schema.org/links"
- },
-
- "fragmentResolution" : {
- "type" : "string",
- "default" : "slash-delimited"
- },
-
- "root" : {
- "type" : "boolean",
- "default" : false
- },
-
- "readonly" : {
- "type" : "boolean",
- "default" : false
- },
-
- "pathStart" : {
- "type" : "string",
- "format" : "uri"
- },
-
- "mediaType" : {
- "type" : "string",
- "format" : "media-type"
- },
-
- "alternate" : {
- "type" : "array",
- "items" : "http://json-schema.org/hyper-schema-or-uri"
- },
-
- "type" : {
- "type" : ["string", "array"],
- "items" : {
- "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
- },
- "uniqueItems" : true,
- "default" : "any"
- },
-
- "properties" : {
- "type" : "object",
- "additionalProperties" : "http://json-schema.org/hyper-schema-or-uri",
- "default" : {}
- },
-
- "items" : {
- "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
- "items" : "http://json-schema.org/hyper-schema-or-uri",
- "default" : {}
- },
- "additionalProperties" : {
- "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
- "default" : {}
- },
- "additionalItems" : {
- "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
- "default" : {}
- },
- "contentEncoding" : {
- "type" : "string"
- },
-
- "requires" : {
- "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
- },
- "disallow" : {
- "type" : ["string", "array", "http://json-schema.org/hyper-schema-or-uri"],
- "items" : {
- "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
- },
- "uniqueItems" : true
- },
- "extends" : {
- "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
- "items" : "http://json-schema.org/hyper-schema-or-uri",
- "default" : {}
- }
-
- },
-
- "links" : [
- {
- "href" : "{$schema}",
- "rel" : "describedby"
- },
-
- {
- "href" : "{$ref}",
- "rel" : "full"
- }
- ],
-
- "fragmentResolution" : "dot-delimited",
- "extends" : "http://json-schema.org/schema"
-}
\ No newline at end of file
diff --git a/links b/links
deleted file mode 100644
index 27041005..00000000
--- a/links
+++ /dev/null
@@ -1,34 +0,0 @@
-{
- "$schema" : "http://json-schema.org/hyper-schema",
- "id" : "http://json-schema.org/links",
- "type" : "object",
-
- "properties" : {
- "href" : {
- "type" : "string",
- "required": true
- },
-
- "rel" : {
- "type" : "string",
- "required": true
- },
-
- "targetSchema" : "http://json-schema.org/hyper-schema",
-
- "method" : {
- "type" : "string",
- "default" : "GET"
- },
-
- "enctype" : {
- "type" : "string",
- "requires" : "method"
- },
-
- "properties" : {
- "type" : "object",
- "additionalProperties" : "http://json-schema.org/hyper-schema"
- }
- }
-}
\ No newline at end of file
From e8955a668bf18de3a1ce799af0af6828bbd8ea21 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 11 Nov 2010 19:05:58 -0700
Subject: [PATCH 0022/1659] Indicate latest version and specific version URLs
---
draft-zyp-json-schema-03.xml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 8e184aea..7099a0e1 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -248,8 +248,10 @@ collection. However, ultimately, the mechanism for referencing a schema is up to
JSON Schemas can themselves be described using JSON Schemas.
A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/draft-03/schema, while the hyper schema
- self-description can be found at http://json-schema.org/draft-03/hyper-schema. All schemas
+ be found at http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema
+ or http://json-schema.org/draft-03/hyper-schema. All schemas
used within a protocol with media type definitions
SHOULD include a MIME parameter that refers to the self-descriptive
hyper schema or another schema that extends this hyper schema:
@@ -501,7 +503,9 @@ values. The link description format can be used on its own in
regular (non-schema documents), and use of this format can
be declared by referencing the normative link description
schema as the the schema for the data structure that uses the
-links. The URI of the normative link description schema is: http://json-schema.org/draft-03/links.
+links. The URI of the normative link description schema is:
+http://json-schema.org/links (latest version) or
+http://json-schema.org/draft-03/links (draft-03 version).
From f51a2a5c19f6b2eab33833fbfdac7a8316ab864b Mon Sep 17 00:00:00 2001
From: Martijn Faassen
Date: Fri, 12 Nov 2010 16:41:19 +0100
Subject: [PATCH 0023/1659] Fix some language issues.
---
draft-zyp-json-schema-03.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 7099a0e1..75264d28 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -728,7 +728,7 @@ starting with the root of the JSON structure from the representation of
the resource identified by the pre-fragment URI. If the target is a JSON
object, then the new target is the value of the property with the name
identified by the next property reference token in the fragment. If the
-target is a JSON array, than the target is determined by finding the
+target is a JSON array, then the target is determined by finding the
item in array the array with the index defined by the next property
reference token (which MUST be a number). The target is successively
updated for each property reference token, until the entire fragment has
From e561d3da1529e18fe5dc6bdc5386d20341b5bfd3 Mon Sep 17 00:00:00 2001
From: Martijn Faassen
Date: Fri, 12 Nov 2010 16:49:27 +0100
Subject: [PATCH 0024/1659] Some more language issues.
---
draft-zyp-json-schema-03.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 75264d28..5bdc973d 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -551,7 +551,7 @@ The value of the "rel" property indicates the name of the
relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
If the relation value is "self", when this property is encountered in
@@ -625,7 +625,7 @@ GET /Resource/
]]>
-This would indicate that for the first item in the collection, it's own
+This would indicate that for the first item in the collection, its own
(self) URI would resolve to "/Resource/thing" and the first item's "up"
relation SHOULD be resolved to the resource at "/Resource/parent".
The "children" collection would be located at "/Resource/?upId=thing".
@@ -971,7 +971,7 @@ instead of numbersReplaced "maxDecimal" attribute with "divisibleBy" attribute.Added slash-delimited fragment resolution protocol and made it the default.
- Added language about using links outside of schemas by referencing it's normative URI.
+ Added language about using links outside of schemas by referencing its normative URI.Added "uniqueItems" attribute.Added "targetSchema" attribute to link description object.
From 6b217dcf2832052f7781b74ea06e44de5a858933 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Sat, 13 Nov 2010 11:09:47 -0700
Subject: [PATCH 0025/1659] Improved language for extends
---
draft-zyp-json-schema-03.xml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 5bdc973d..2345f260 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -432,7 +432,11 @@ The dependency value can take one of two forms:
This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints. The schema MUST NOT define a constraint that conflicts with an extended schema such that no instance may satisfy both schemas. An example of using "extends":
+The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
+Conceptually, the behavior of extends can be seen as validating an
+instance against all constraints in the extending schema as well as
+the extended schema(s). More optimized implementations that merge
+schemas are possible, but are not required. An example of using "extends":
Date: Sat, 13 Nov 2010 11:19:21 -0700
Subject: [PATCH 0026/1659] Replaced the link submission "properties" attribute
to "schema" attribute.
---
draft-zyp-json-schema-03.xml | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 2345f260..acb0cf9e 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -694,12 +694,11 @@ the href property is defined. If the method is POST, "application/json" is
the default media type.
-
+
-This attribute has the same structure as the core JSON Schema "properties" attribute,
-but its meaning SHOULD be used to define the acceptable
-property names and values for the action (whether it be for the GET query
-or POST body).
+This attribute contains a schema which defines the acceptable structure of the submitted
+request (for a GET request, this schema would define the properties for the query string
+and for a POST request, this would define the body).
From b6f9650da0fc969ff5244176a0d141edcb1e0858 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Sun, 14 Nov 2010 21:07:40 -0700
Subject: [PATCH 0027/1659] Fixed "extends" examples.
---
draft-zyp-json-schema-03.xml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index acb0cf9e..467a53c6 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -441,16 +441,16 @@ schemas are possible, but are not required. An example of using "extends":
From ecf6c828f9615d0f5d0a7a8f70e927c429d325da Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 18 Nov 2010 08:15:31 -0700
Subject: [PATCH 0028/1659] Improved wording for "id" property and specified
that it resolves against parent schema
---
draft-zyp-json-schema-03.xml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index acb0cf9e..8624554f 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -459,10 +459,14 @@ schemas are possible, but are not required. An example of using "extends":
-This attribute defines the URI of this schema (this attribute is effectively
-a "self" link). This URI MAY be relative or absolute. If the URI
-is relative, it SHOULD be resolved against the URI used to retrieve this schema.
-
+This attribute defines the current URI of this schema (this attribute is
+effectively a "self" link). This URI MAY be relative or absolute. If
+the URI is relative it is resolved against the current URI of the parent
+schema it is contained in. If this schema is not contained in any
+parent schema, the current URI of the parent schema is held to be the
+URI under which this schema was addressed. If id is missing, the current URI of a schema is
+defined to be that of the parent schema. The current URI of the schema
+is also used to construct relative references such as for $ref.
@@ -957,6 +961,7 @@ instead of numbersAdded more explanation of nullability.Removed "alternate" attribute.Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema" attribute.Replaced "optional" attribute with "required" attribute.Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
From 2d6f9681733a7e1cb6fdf430ee07a4abd32faaf1 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Mon, 22 Nov 2010 14:15:50 -0700
Subject: [PATCH 0029/1659] Recommended against 0 as divisibleBy
---
draft-zyp-json-schema-03.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 8624554f..63ae73b5 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -426,7 +426,7 @@ The dependency value can take one of two forms:
Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
-This attribute defines what value the number instance must be divisible by with no remainder. (The result of the division must be an integer.)
+This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
From cd374385c465be308cf4fa12955a15c033f3e595 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 23 Nov 2010 12:38:18 -0700
Subject: [PATCH 0030/1659] Updated package.json
---
package.json | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/package.json b/package.json
index 42fb6686..d986a319 100644
--- a/package.json
+++ b/package.json
@@ -1,11 +1,24 @@
{
- "name": "json-schema",
- "author": "Kris Zyp",
- "dependencies": [],
- "contributors": [],
- "keywords": [
- "json",
- "schema"
- ],
- "engines": {"node":">=0.1.30", "rhino": true}
+ "name": "json-schema",
+ "version": "0.2.0",
+ "author": "Kris Zyp",
+ "keywords": [
+ "json",
+ "schema"
+ ],
+ "licenses": [
+ {
+ "type": "AFLv2.1",
+ "url": "http://trac.dojotoolkit.org/browser/dojo/trunk/LICENSE#L43"
+ },
+ {
+ "type": "BSD",
+ "url": "http://trac.dojotoolkit.org/browser/dojo/trunk/LICENSE#L13"
+ }
+ ],
+ "repository": {
+ "type":"git",
+ "url":"http://github.com/kriszyp/json-schema"
+ },
+ "directories": { "lib": "./lib" }
}
\ No newline at end of file
From 8cd7a08368ab2d52e2b4a76f1063fdd1c951799e Mon Sep 17 00:00:00 2001
From: Vladimir Dronnikov
Date: Sat, 8 Jan 2011 18:56:42 +0300
Subject: [PATCH 0031/1659] coercion
---
lib/validate.js | 120 +++++++++++++++++++++++++-----------------------
1 file changed, 63 insertions(+), 57 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index fc02a9b9..3d043463 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -1,15 +1,15 @@
-/**
- * JSONSchema Validator - Validates JavaScript objects using JSON Schemas
+/**
+ * JSONSchema Validator - Validates JavaScript objects using JSON Schemas
* (http://www.json.com/json-schema-proposal/)
*
* Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com)
* Licensed under the MIT (MIT-LICENSE.txt) license.
To use the validator call the validate function with an instance object and an optional schema object.
-If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
-that schema will be used to validate and the schema parameter is not necessary (if both exist,
-both validations will occur).
-The validate method will return an array of validation errors. If there are no errors, then an
-empty list will be returned. A validation error will have two properties:
+If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
+that schema will be used to validate and the schema parameter is not necessary (if both exist,
+both validations will occur).
+The validate method will return an array of validation errors. If there are no errors, then an
+empty list will be returned. A validation error will have two properties:
"property" which indicates which property had the error
"message" which indicates what the error was
*/
@@ -24,43 +24,47 @@ exports.Integer = {type:"integer"};
Object.type = "object";
Array.type = "array";
Date.type = "date";
-exports.validate = validate;
+exports.validate = validate;
function validate(/*Any*/instance,/*Object*/schema) {
// Summary:
// To use the validator call JSONSchema.validate with an instance object and an optional schema object.
- // If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
- // that schema will be used to validate and the schema parameter is not necessary (if both exist,
- // both validations will occur).
+ // If a schema is provided, it will be used to validate. If the instance object refers to a schema (self-validating),
+ // that schema will be used to validate and the schema parameter is not necessary (if both exist,
+ // both validations will occur).
// The validate method will return an object with two properties:
// valid: A boolean indicating if the instance is valid by the schema
- // errors: An array of validation errors. If there are no errors, then an
- // empty list will be returned. A validation error will have two properties:
+ // errors: An array of validation errors. If there are no errors, then an
+ // empty list will be returned. A validation error will have two properties:
// property: which indicates which property had the error
// message: which indicates what the error was
//
- return validate(instance,schema,false);
+ return validate(instance, schema, {changing: false});//, coerce: false, existingOnly: false});
};
-exports.checkPropertyChange = function(/*Any*/value,/*Object*/schema, /*String*/ property) {
+exports.checkPropertyChange = function(/*Any*/value,/*Object*/schema, /*String*/property) {
// Summary:
// The checkPropertyChange method will check to see if an value can legally be in property with the given schema
// This is slightly different than the validate method in that it will fail if the schema is readonly and it will
- // not check for self-validation, it is assumed that the passed in value is already internally valid.
- // The checkPropertyChange method will return the same object type as validate, see JSONSchema.validate for
+ // not check for self-validation, it is assumed that the passed in value is already internally valid.
+ // The checkPropertyChange method will return the same object type as validate, see JSONSchema.validate for
// information.
//
- return validate(value,schema, property || "property");
+ return validate(value, schema, {changing: property || "property"});
};
-var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*Boolean*/ _changing) {
-
+var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*Object*/options) {
+
+ if (!options) options = {};
+ var _changing = options.changing;
+
var errors = [];
- // validate a value against a property definition
+ // validate a value against a property definition
function checkProp(value, schema, path,i){
+
var l;
path += path ? typeof i == 'number' ? '[' + i + ']' : typeof i == 'undefined' ? '' : '.' + i : i;
function addError(message){
errors.push({property:path,message:message});
}
-
+
if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && schema.type)){
if(typeof schema == 'function'){
if(!(value instanceof schema)){
@@ -80,8 +84,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
// validate a value against a type definition
function checkType(type,value){
if(type){
- if(typeof type == 'string' && type != 'any' &&
- (type == 'null' ? value !== null : typeof value != type) &&
+ if(typeof type == 'string' && type != 'any' &&
+ (type == 'null' ? value !== null : typeof value != type) &&
!(value instanceof Array && type == 'array') &&
!(value instanceof Date && type == 'date') &&
!(type == 'integer' && value%1===0)){
@@ -89,7 +93,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
if(type instanceof Array){
var unionErrors=[];
- for(var j = 0; j < type.length; j++){ // a union type
+ for(var j = 0; j < type.length; j++){ // a union type
if(!(unionErrors=checkType(type[j],value)).length){
break;
}
@@ -99,17 +103,17 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
}else if(typeof type == 'object'){
var priorErrors = errors;
- errors = [];
+ errors = [];
checkProp(value,type,path);
var theseErrors = errors;
errors = priorErrors;
- return theseErrors;
- }
+ return theseErrors;
+ }
}
return [];
}
if(value === undefined){
- if(!schema.optional && !schema.get){
+ if(!schema.optional && !schema.get){
addError("is missing and it is not optional");
}
}else{
@@ -120,15 +124,15 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
if(value !== null){
if(value instanceof Array){
if(schema.items){
- if(schema.items instanceof Array){
- for(i=0,l=value.length; i value){
addError("must have a minimum value of " + schema.minimum);
}
- if(typeof schema.maximum !== undefined && typeof value == typeof schema.maximum &&
+ if(typeof schema.maximum !== undefined && typeof value == typeof schema.maximum &&
schema.maximum < value){
addError("must have a maximum value of " + schema.maximum);
}
@@ -170,7 +174,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
addError("does not have a value in the enumeration " + enumer.join(", "));
}
}
- if(typeof schema.maxDecimal == 'number' &&
+ if(typeof schema.maxDecimal == 'number' &&
(value.toString().match(new RegExp("\\.[0-9]{" + (schema.maxDecimal + 1) + ",}")))){
addError("may only have " + schema.maxDecimal + " digits of decimal places");
}
@@ -180,23 +184,25 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
// validate an object against a schema
function checkObj(instance,objTypeDef,path,additionalProp){
-
+
if(typeof objTypeDef =='object'){
if(typeof instance != 'object' || instance instanceof Array){
errors.push({property:path,message:"an object is required"});
}
-
- for(var i in objTypeDef){
+
+ for(var i in objTypeDef){
if(objTypeDef.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_')){
var value = instance[i];
+ // skip _not_ specified properties
+ if (value === undefined && options.existingOnly) continue;
var propDef = objTypeDef[i];
- // set default
- if(value === undefined && propDef["default"]){
- value = instance[i] = propDef["default"];
- }
- if(propDef.coerce && exports.coerce && i in instance){
- value = instance[i] = exports.coerce(value, propDef);
- }
+ // set default
+ if(value === undefined && propDef["default"]){
+ value = instance[i] = propDef["default"];
+ }
+ if(options.coerce && i in instance){
+ value = instance[i] = options.coerce(value, propDef);
+ }
checkProp(value,propDef,path,i);
}
}
@@ -212,10 +218,10 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
value = instance[i];
if(additionalProp && (!(objTypeDef && typeof objTypeDef == 'object') || !(i in objTypeDef))){
- if(additionalProp.coerce && exports.coerce){
- value = instance[i] = exports.coerce(value, additionalProp);
- }
- checkProp(value,additionalProp,path,i);
+ if(options.coerce){
+ value = instance[i] = options.coerce(value, additionalProp);
+ }
+ checkProp(value,additionalProp,path,i);
}
if(!_changing && value && value.$schema){
errors = errors.concat(checkProp(value,value.$schema,path,i));
@@ -237,8 +243,8 @@ exports.mustBeValid = function(result){
// result: the result returned from checkPropertyChange or validate
if(!result.valid){
throw new TypeError(result.errors.map(function(error){return "for property " + error.property + ': ' + error.message;}).join(", \n"));
- }
+ }
}
return exports;
-});
\ No newline at end of file
+});
From 6acf3a9af0d236a036a9688e07073abc15eec07c Mon Sep 17 00:00:00 2001
From: Vladimir Dronnikov
Date: Tue, 11 Jan 2011 17:47:06 +0300
Subject: [PATCH 0032/1659] filter-helper
---
lib/validate.js | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 3d043463..2d10df8a 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -209,8 +209,13 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
for(i in instance){
if(instance.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_') && objTypeDef && !objTypeDef[i] && additionalProp===false){
- errors.push({property:path,message:(typeof value) + "The property " + i +
+ if (options.filter) {
+ delete instance[i];
+ continue;
+ } else {
+ errors.push({property:path,message:(typeof value) + "The property " + i +
" is not defined in the schema and the schema does not allow additional properties"});
+ }
}
var requires = objTypeDef && objTypeDef[i] && objTypeDef[i].requires;
if(requires && !(requires in instance)){
From fdc23eb13ff82c3d73886b43d03cf8dab5faef80 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Fri, 14 Jan 2011 12:03:50 -0700
Subject: [PATCH 0033/1659] Remove underscore check
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index fc02a9b9..16181019 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -187,7 +187,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*B
}
for(var i in objTypeDef){
- if(objTypeDef.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_')){
+ if(objTypeDef.hasOwnProperty(i)){
var value = instance[i];
var propDef = objTypeDef[i];
// set default
From b1d463a52d45b8d3414647e294dca0962e4391aa Mon Sep 17 00:00:00 2001
From: Laurie Harper
Date: Wed, 26 Jan 2011 06:11:19 -0500
Subject: [PATCH 0034/1659] replace outdate "optional" defaulting to false with
new "required" defaulting to false
---
lib/validate.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index a9f1438d..24662a07 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -113,8 +113,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
return [];
}
if(value === undefined){
- if(!schema.optional && !schema.get){
- addError("is missing and it is not optional");
+ if(schema.required){
+ addError("is missing and it is required");
}
}else{
errors = errors.concat(checkType(schema.type,value));
From f331e2c418f05501af9752ccfe56bd33f6e45631 Mon Sep 17 00:00:00 2001
From: Stacia Hartleben
Date: Wed, 2 Mar 2011 10:27:50 -0800
Subject: [PATCH 0035/1659] Replaced obsolete optional with required fixed
package.json
---
lib/validate.js | 4 ++--
package.json | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index a9f1438d..5f73dfc4 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -113,8 +113,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
return [];
}
if(value === undefined){
- if(!schema.optional && !schema.get){
- addError("is missing and it is not optional");
+ if(schema.required && !schema.get){
+ addError("is missing and it is required");
}
}else{
errors = errors.concat(checkType(schema.type,value));
diff --git a/package.json b/package.json
index d986a319..d2769234 100644
--- a/package.json
+++ b/package.json
@@ -20,5 +20,6 @@
"type":"git",
"url":"http://github.com/kriszyp/json-schema"
},
- "directories": { "lib": "./lib" }
+ "directories": { "lib": "./lib" },
+ "dependencies" : {}
}
\ No newline at end of file
From 70002354fea892e99ff4a53ffb9df5747fa47ad8 Mon Sep 17 00:00:00 2001
From: Laurie Harper
Date: Wed, 2 Mar 2011 16:01:57 -0500
Subject: [PATCH 0036/1659] Fix hyper-schema syntax error.
---
draft-03/hyper-schema | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/draft-03/hyper-schema b/draft-03/hyper-schema
index a0e0a350..623055c3 100644
--- a/draft-03/hyper-schema
+++ b/draft-03/hyper-schema
@@ -1,6 +1,6 @@
{
"$schema" : "http://json-schema.org/draft-03/hyper-schema#",
- "extends" : {"$ref" : "http://json-schema.org/draft-03/schema#"}
+ "extends" : {"$ref" : "http://json-schema.org/draft-03/schema#"},
"id" : "http://json-schema.org/draft-03/hyper-schema#",
"properties" : {
@@ -8,53 +8,53 @@
"type" : "array",
"items" : {"$ref" : "http://json-schema.org/draft-03/links#"}
},
-
+
"fragmentResolution" : {
"type" : "string",
"default" : "slash-delimited"
},
-
+
"root" : {
"type" : "boolean",
"default" : false
},
-
+
"readonly" : {
"type" : "boolean",
"default" : false
},
-
+
"contentEncoding" : {
"type" : "string"
},
-
+
"pathStart" : {
"type" : "string",
"format" : "uri"
},
-
+
"mediaType" : {
"type" : "string",
"format" : "media-type"
}
},
-
+
"links" : [
{
"href" : "{id}",
"rel" : "self"
},
-
+
{
"href" : "{$ref}",
"rel" : "full"
},
-
+
{
"href" : "{$schema}",
"rel" : "describedby"
}
],
-
+
"fragmentResolution" : "slash-delimited"
-}
\ No newline at end of file
+}
From 0a52e1e737d4adeab0cb45739062f327dfd65257 Mon Sep 17 00:00:00 2001
From: Laurie Harper
Date: Wed, 2 Mar 2011 18:02:19 -0500
Subject: [PATCH 0037/1659] Add vows-based unit tests.
These tests demonstrate the problems reported in
more comprehensive unit tests.
---
package.json | 6 ++--
test/tests.js | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 99 insertions(+), 2 deletions(-)
create mode 100644 test/tests.js
diff --git a/package.json b/package.json
index d986a319..2b9b4676 100644
--- a/package.json
+++ b/package.json
@@ -20,5 +20,7 @@
"type":"git",
"url":"http://github.com/kriszyp/json-schema"
},
- "directories": { "lib": "./lib" }
-}
\ No newline at end of file
+ "directories": { "lib": "./lib" },
+ "devDependencies": { "vows": "*" },
+ "scripts": { "test": "echo TESTS DISABLED vows --spec test/*.js" }
+}
diff --git a/test/tests.js b/test/tests.js
new file mode 100644
index 00000000..40eeda5d
--- /dev/null
+++ b/test/tests.js
@@ -0,0 +1,95 @@
+var assert = require('assert');
+var vows = require('vows');
+var path = require('path');
+var fs = require('fs');
+
+var validate = require('../lib/validate').validate;
+
+
+var revision = 'draft-03';
+var schemaRoot = path.join(__dirname, '..', revision);
+var schemaNames = ['schema', 'hyper-schema', 'links', 'json-ref' ];
+var schemas = {};
+
+schemaNames.forEach(function(name) {
+ var file = path.join(schemaRoot, name);
+ schemas[name] = loadSchema(file);
+});
+
+schemaNames.forEach(function(name) {
+ var s, n = name+'-nsd', f = path.join(schemaRoot, name);
+ schemas[n] = loadSchema(f);
+ s = schemas[n];
+ delete s['$schema'];
+});
+
+function loadSchema(path) {
+ var data = fs.readFileSync(path, 'utf-8');
+ var schema = JSON.parse(data);
+ return schema;
+}
+
+function resultIsValid() {
+ return function(result) {
+ assert.isObject(result);
+ //assert.isBoolean(result.valid);
+ assert.equal(typeof(result.valid), 'boolean');
+ assert.isArray(result.errors);
+ for (var i = 0; i < result.errors.length; i++) {
+ assert.notEqual(result.errors[i], null, 'errors['+i+'] is null');
+ }
+ }
+}
+
+function assertValidates(doc, schema) {
+ var context = {};
+
+ context[': validate('+doc+', '+schema+')'] = {
+ topic: validate(schemas[doc], schemas[schema]),
+ 'returns valid result': resultIsValid(),
+ 'with valid=true': function(result) { assert.equal(result.valid, true); },
+ 'and no errors': function(result) {
+ // XXX work-around for bug in vows: [null] chokes it
+ if (result.errors[0] == null) assert.fail('(errors contains null)');
+ assert.length(result.errors, 0);
+ }
+ };
+
+ return context;
+}
+
+function assertSelfValidates(doc) {
+ var context = {};
+
+ context[': validate('+doc+')'] = {
+ topic: validate(schemas[doc]),
+ 'returns valid result': resultIsValid(),
+ 'with valid=true': function(result) { assert.equal(result.valid, true); },
+ 'and no errors': function(result) { assert.length(result.errors, 0); }
+ };
+
+ return context;
+}
+
+var suite = vows.describe('JSON Schema').addBatch({
+ 'Core-NSD self-validates': assertSelfValidates('schema-nsd'),
+ 'Core-NSD/Core-NSD': assertValidates('schema-nsd', 'schema-nsd'),
+ 'Core-NSD/Core': assertValidates('schema-nsd', 'schema'),
+
+ 'Core self-validates': assertSelfValidates('schema'),
+ 'Core/Core': assertValidates('schema', 'schema'),
+
+ 'Hyper-NSD self-validates': assertSelfValidates('hyper-schema-nsd'),
+ 'Hyper self-validates': assertSelfValidates('hyper-schema'),
+ 'Hyper/Hyper': assertValidates('hyper-schema', 'hyper-schema'),
+ 'Hyper/Core': assertValidates('hyper-schema', 'schema'),
+
+ 'Links-NSD self-validates': assertSelfValidates('links-nsd'),
+ 'Links self-validates': assertSelfValidates('links'),
+ 'Links/Hyper': assertValidates('links', 'hyper-schema'),
+ 'Links/Core': assertValidates('links', 'schema'),
+
+ 'Json-Ref self-validates': assertSelfValidates('json-ref'),
+ 'Json-Ref/Hyper': assertValidates('json-ref', 'hyper-schema'),
+ 'Json-Ref/Core': assertValidates('json-ref', 'schema')
+}).export(module);
From 549c6e0406a768f1dd6c3286d0f6702f8bef65a5 Mon Sep 17 00:00:00 2001
From: Jacob Chapel
Date: Fri, 13 May 2011 04:34:59 -0700
Subject: [PATCH 0038/1659] Added main key to package.json to troubleshoot npm
install issues
---
package.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package.json b/package.json
index d986a319..4964bf23 100644
--- a/package.json
+++ b/package.json
@@ -20,5 +20,6 @@
"type":"git",
"url":"http://github.com/kriszyp/json-schema"
},
- "directories": { "lib": "./lib" }
+ "directories": { "lib": "./lib" },
+ "main": "./lib"
}
\ No newline at end of file
From 9354bf34964b164417171b459d78c8aa68c3dfa8 Mon Sep 17 00:00:00 2001
From: Jacob Chapel
Date: Fri, 13 May 2011 04:46:13 -0700
Subject: [PATCH 0039/1659] Testing main options
---
package.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package.json b/package.json
index 4964bf23..5d5aa00e 100644
--- a/package.json
+++ b/package.json
@@ -21,5 +21,5 @@
"url":"http://github.com/kriszyp/json-schema"
},
"directories": { "lib": "./lib" },
- "main": "./lib"
+ "main": { "validate": "./lib/validate.js" }
}
\ No newline at end of file
From f363c53798da3798d330f942b6385311145e0114 Mon Sep 17 00:00:00 2001
From: Jacob Chapel
Date: Fri, 13 May 2011 04:48:27 -0700
Subject: [PATCH 0040/1659] more testing of main
---
package.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package.json b/package.json
index 5d5aa00e..55f405ad 100644
--- a/package.json
+++ b/package.json
@@ -21,5 +21,5 @@
"url":"http://github.com/kriszyp/json-schema"
},
"directories": { "lib": "./lib" },
- "main": { "validate": "./lib/validate.js" }
+ "main": ["./lib/validate.js", "./lib/links.js"]
}
\ No newline at end of file
From ae89ab502f79cee5bff9a36f24973cf07a51fd69 Mon Sep 17 00:00:00 2001
From: Jacob Chapel
Date: Fri, 13 May 2011 04:49:08 -0700
Subject: [PATCH 0041/1659] no more testing
---
package.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package.json b/package.json
index 55f405ad..17d9dd4d 100644
--- a/package.json
+++ b/package.json
@@ -21,5 +21,5 @@
"url":"http://github.com/kriszyp/json-schema"
},
"directories": { "lib": "./lib" },
- "main": ["./lib/validate.js", "./lib/links.js"]
+ "main": "./lib/validate.js"
}
\ No newline at end of file
From 87d7bd7419a60d77646924652416575bc85b174a Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Mon, 16 May 2011 15:32:42 -0600
Subject: [PATCH 0042/1659] Fixed syntax error in draft-03/hyper-schema.
---
draft-03/hyper-schema | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-03/hyper-schema b/draft-03/hyper-schema
index a0e0a350..6ac2c40f 100644
--- a/draft-03/hyper-schema
+++ b/draft-03/hyper-schema
@@ -1,6 +1,6 @@
{
"$schema" : "http://json-schema.org/draft-03/hyper-schema#",
- "extends" : {"$ref" : "http://json-schema.org/draft-03/schema#"}
+ "extends" : {"$ref" : "http://json-schema.org/draft-03/schema#"},
"id" : "http://json-schema.org/draft-03/hyper-schema#",
"properties" : {
From d57195610e1c364ba158fef78a6c2aeb8401fe44 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Mon, 16 May 2011 15:33:29 -0600
Subject: [PATCH 0043/1659] Beautified XML
---
draft-zyp-json-schema-03.xml | 1994 ++++++++++++++++++----------------
1 file changed, 1050 insertions(+), 944 deletions(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 4f6643e3..bf201aea 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -22,749 +22,868 @@
-
-
- A JSON Media Type for Describing the Structure and Meaning of JSON Documents
-
-
- SitePen (USA)
-
-
-
- 530 Lytton Avenue
-
- Palo Alto, CA 94301
-
- USA
-
-
- +1 650 968 8787
-
- kris@sitepen.com
-
-
-
-
-
-
- Calgary, AB
- Canada
-
- gary.court@gmail.com
-
-
-
-
-
- Internet Engineering Task Force
-
- JSON
- Schema
- JavaScript
- Object
- Notation
- Hyper Schema
- Hypermedia
-
-
-
-
- JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
- a JSON based format for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
-
-
-
- JSON (JavaScript Object Notation) Schema is a JSON media type for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
- 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.
-
-
-
-
-
- JSON Schema defines the media type "application/schema+json" for
- describing the structure of other
- JSON documents. JSON Schema is JSON-based and includes facilities
- for describing the structure of JSON documents in terms of
- allowable values, descriptions, and interpreting relations with other resources.
-
- JSON Schema format is organized into several separate definitions. The first
- definition is the core schema specification. This definition is primary
- concerned with describing a JSON structure and specifying valid elements
- in the structure. The second definition is the Hyper Schema specification
- which is intended define elements in a structure that can be interpreted as
- hyperlinks.
- Hyper Schema builds on JSON Schema to describe the hyperlink structure of
- other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
- JSON documents based on their schemas.
-
-
- Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
- property values, as well as define the meaning of the property values
- for the purpose of describing a resource and determining hyperlinks
- within the representation.
-
-
- An example JSON Schema that describes products might look like:
-
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ JavaScript
+ Object
+ Notation
+ Hyper Schema
+ Hypermedia
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
-
- This schema defines the properties of the instance JSON documents,
- the required properties (id, name, and price), as well as an optional
- property (tags). This also defines the link relations of the instance
- JSON documents.
-
-
-
- For this specification, schema will be used to denote a JSON Schema
- definition, and an instance refers to a JSON value that the schema
- will be describing and validating.
-
-
-
-
- The JSON Schema media type does not attempt to dictate the structure of JSON
- representations that contain data, but rather provides a separate format
- for flexibly communicating how a JSON representation should be
- interpreted and validated, such that user agents can properly understand
- acceptable structures and extrapolate hyperlink information
- with the JSON document. It is acknowledged that JSON documents come
- in a variety of structures, and JSON is unique in that the structure
- of stored data structures often prescribes a non-ambiguous definite
- JSON representation. Attempting to force a specific structure is generally
- not viable, and therefore JSON Schema allows for a great flexibility
- in the structure of the JSON data that it describes.
-
- This specification is protocol agnostic.
- The underlying protocol (such as HTTP) should sufficiently define the
- semantics of the client-server interface, the retrieval of resource
- representations linked to by JSON representations, and modification of
- those resources. The goal of this
- format is to sufficiently describe JSON structures such that one can
- utilize existing information available in existing JSON
- representations from a large variety of services that leverage a representational state transfer
- architecture using existing protocols.
-
-
-
-
-
-
- JSON Schema instances are correlated to their schema by the "describedby"
- relation, where the schema is defined to be the target of the relation.
- Instance representations may be of the "application/json" media type or
- any other subtype. Consequently, dictating how an instance
- representation should specify the relation to the schema is beyond the normative scope
- of this document (since this document specifically defines the JSON
- Schema media type, and no other), but it is recommended that instances
- specify their schema so that user agents can interpret the instance
- representation and messages may retain the self-descriptive
- characteristic, avoiding the need for out-of-band information about
- instance data. Two approaches are recommended for declaring the
- relation to the schema that describes the meaning of a JSON instance's (or collection
- of instances) structure. A MIME type parameter named
- "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
-
-
+
+
+ This schema defines the properties of the instance JSON documents,
+ the required properties (id, name, and price), as well as an optional
+ property (tags). This also defines the link relations of the instance
+ JSON documents.
+
+
+
+
+
+ For this specification, schema will be used to denote a JSON Schema
+ definition, and an instance refers to a JSON value that the schema
+ will be describing and validating.
+
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. It is acknowledged that JSON documents come
+ in a variety of structures, and JSON is unique in that the structure
+ of stored data structures often prescribes a non-ambiguous definite
+ JSON representation. Attempting to force a specific structure is generally
+ not viable, and therefore JSON Schema allows for a great flexibility
+ in the structure of the JSON data that it describes.
+
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a representational state transfer
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the "application/json" media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
+
+
+
+
- or if the content is being transferred by a protocol (such as HTTP) that
- provides headers, a Link header can be used:
-
-
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+
+; rel="describedby"
-]]>
- Instances MAY specify multiple schemas, to indicate all the schemas that
- are applicable to the data, and the data SHOULD be valid by all the schemas.
- The instance data MAY have multiple schemas
- that it is defined by (the instance data SHOULD be valid for those schemas).
- Or if the document is a collection of instances, the collection MAY contain
- instances from different schemas. When collections contain heterogeneous
- instances, the "pathStart" attribute MAY be specified in the
- schema to disambiguate which schema should be applied for each item in the
-collection. However, ultimately, the mechanism for referencing a schema is up to the
- media type of the instance documents (if they choose to specify that schemas
- can be referenced).
-
-
-
- JSON Schemas can themselves be described using JSON Schemas.
- A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema for the latest version or
- http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
- self-description can be found at http://json-schema.org/hyper-schema
- or http://json-schema.org/draft-03/hyper-schema. All schemas
- used within a protocol with media type definitions
- SHOULD include a MIME parameter that refers to the self-descriptive
- hyper schema or another schema that extends this hyper schema:
-
-
+
+
+
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data, and the data SHOULD be valid by all the schemas.
+ The instance data MAY have multiple schemas
+ that it is defined by (the instance data SHOULD be valid for those schemas).
+ Or if the document is a collection of instances, the collection MAY contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the "pathStart" attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+ collection. However, ultimately, the mechanism for referencing a schema is up to the
+ media type of the instance documents (if they choose to specify that schemas
+ can be referenced).
+
+
+
+
+ JSON Schemas can themselves be described using JSON Schemas.
+ A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema
+ or http://json-schema.org/draft-03/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
-
-
-
-
-
- A JSON Schema is a JSON Object that defines various attributes
- (including usage and valid values) of a JSON value. JSON
- Schema has recursive capabilities; there are a number of elements
- in the structure that allow for nested JSON Schemas.
-
- An example JSON Schema definition could look like:
-
-
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ (including usage and valid values) of a JSON value. JSON
+ Schema has recursive capabilities; there are a number of elements
+ in the structure that allow for nested JSON Schemas.
+
+
+
+ An example JSON Schema definition could look like:
+
+
-
-
- A JSON Schema object may have any of the following properties, called schema
- attributes (all attributes are optional):
-
-
-
-
-This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
-This attribute can take one of two forms:
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "age": {
+ "type": "integer",
+ "maximum": 125
+ }
+ }
+}
+]]>
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+ This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
+ This attribute can take one of two forms:
-
-A string indicating a primitive or simple type. The following are acceptable string values:
+
+
+ A string indicating a primitive or simple type. The following are acceptable string values:
-
-Value MUST be a string.
-Value MUST be a number, floating point numbers are allowed.
-Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
-Value MUST be a boolean.
-Value MUST be an object.
-Value MUST be an array.
-Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
-included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
-Value MAY be of any type including null.
-
-
-If the property is not defined or is not in this list, then any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
-
-An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema. The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
-
-
-
-
- For example, a schema that defines if an instance can be a string or a number would be:
-
+ Value MUST be a string.
+ Value MUST be a number, floating point numbers are allowed.
+ Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
+ Value MUST be a boolean.
+ Value MUST be an object.
+ Value MUST be an array.
+ Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
+ Value MAY be of any type including null.
+
+
+ If the property is not defined or is not in this list, then any type of value is acceptable.
+ Other type values MAY be used for custom purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type values.
+
+
+
+ An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema.
+ The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
+
+
+
+
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
+
-
-
-
-This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
-
-
-This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
-
-
-This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
-
-
-This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
-When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
-When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
-
-
-This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
-
-
-This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
-
-
-This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
-
-The dependency value can take one of two forms:
-
-If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value. If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
-If the dependency value is a schema, then the instance object MUST be valid against the schema.
-
-
-
-
-This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-
-
-This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-
-
-This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-
-
-This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-
-
-This attribute defines the minimum number of values in an array when the array is the instance value.
-
-
-This attribute defines the maximum number of values in an array when the array is the instance value.
-
-
-This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
-Two instance are consider equal if they are both of the same type and:
-
-are null; or
-are booleans/numbers/strings and have the same value; or
-are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
-are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
-
-
-
-
-When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
-When the instance value is a string, this defines the minimum length of the string.
-
-
-When the instance value is a string, this defines the maximum length of the string.
-
-
-This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
-
-
-This attribute defines the default value of the instance when the instance is undefined.
-
-
-This attribute is a string that provides a short description of the instance property.
-
-
-This attribute is a string that provides a full description of the of purpose the instance property.
-
-
-This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format. The following formats are predefined:
-
-
-This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
-This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
-This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
-This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
-A regular expression, following the regular expression specification from ECMA 262/Perl 5.
-This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
-This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
-This SHOULD be a phone number (format MAY follow E.123).
-This value SHOULD be a URI..
-This SHOULD be an email address.
-This SHOULD be an ip version 4 address.
-This SHOULD be an ip version 6 address.
-This SHOULD be a host-name.
-
-
-Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
-
-
-This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
-
-
-This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-
-
-The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
-Conceptually, the behavior of extends can be seen as validating an
-instance against all constraints in the extending schema as well as
-the extended schema(s). More optimized implementations that merge
-schemas are possible, but are not required. An example of using "extends":
-
-
+
+
+
+ This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+
+
+ This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+
+
+
+ This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
+
+
+
+ This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
+ When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
+ When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
+
+
+
+ This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
+
+
+
+ This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
+
+
+
+ This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
+
+ The dependency value can take one of two forms:
+
+
+
+ If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value.
+ If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
+
+
+ If the dependency value is a schema, then the instance object MUST be valid against the schema.
+
+
+
+
+
+
+ This attribute defines the minimum value of the instance property when the type of the instance value is a number.
+
+
+
+ This attribute defines the maximum value of the instance property when the type of the instance value is a number.
+
+
+
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
+
+
+
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
+
+
+
+ This attribute defines the minimum number of values in an array when the array is the instance value.
+
+
+
+ This attribute defines the maximum number of values in an array when the array is the instance value.
+
+
+
+ This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
+
+ Two instance are consider equal if they are both of the same type and:
+
+
+ are null; or
+ are booleans/numbers/strings and have the same value; or
+ are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+ are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
+
+
+
+
+
+ When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
+
+
+
+ When the instance value is a string, this defines the minimum length of the string.
+
+
+
+ When the instance value is a string, this defines the maximum length of the string.
+
+
+
+ This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+
+
+ This attribute defines the default value of the instance when the instance is undefined.
+
+
+
+ This attribute is a string that provides a short description of the instance property.
+
+
+
+ This attribute is a string that provides a full description of the of purpose the instance property.
+
+
+
+ This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format.
+
+
+ The following formats are predefined:
+
+
+ This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+ This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+ This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+ This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
+ A regular expression, following the regular expression specification from ECMA 262/Perl 5.
+ This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
+ This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
+ This SHOULD be a phone number (format MAY follow E.123).
+ This value SHOULD be a URI.
+ This SHOULD be an email address.
+ This SHOULD be an ip version 4 address.
+ This SHOULD be an ip version 6 address.
+ This SHOULD be a host-name.
+
+
+
+ Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
+
+
+
+ This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
+
+
+
+ This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
+
+
+
+ The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
+
+ Conceptually, the behavior of extends can be seen as validating an
+ instance against all constraints in the extending schema as well as
+ the extended schema(s). More optimized implementations that merge
+ schemas are possible, but are not required. Some examples of using "extends":
+
+
+
+
-
-
+
+
+
+
+
+
-
-
-
-
-
-
-This attribute defines the current URI of this schema (this attribute is
-effectively a "self" link). This URI MAY be relative or absolute. If
-the URI is relative it is resolved against the current URI of the parent
-schema it is contained in. If this schema is not contained in any
-parent schema, the current URI of the parent schema is held to be the
-URI under which this schema was addressed. If id is missing, the current URI of a schema is
-defined to be that of the parent schema. The current URI of the schema
-is also used to construct relative references such as for $ref.
-
-
-
-This attribute defines a URI of a schema that contains the full representation of this schema.
-When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
-This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
-
-
-
-
-This attribute defines a URI of a JSON Schema that is the schema of the current schema.
-When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
-
-
-A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
-Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
-
-
-
-
- The following attributes are specified in addition to those
-attributes that already provided by the core schema with the specific
-purpose of informing user agents of relations between resources based
-on JSON data. Just as with JSON
-schema attributes, all the attributes in hyper schemas are optional.
-Therefore, an empty object is a valid (non-informative) schema, and
-essentially describes plain JSON (no constraints on the structures).
-Addition of attributes provides additive information for user agents.
-
-
-
-The value of the links property MUST be an array, where each item
-in the array is a link description object which describes the link
-relations of the instances.
-
-
-
-A link description object is used to describe link relations. In
-the context of a schema, it defines the link relations of the
-instances of the schema, and can be parameterized by the instance
-values. The link description format can be used on its own in
-regular (non-schema documents), and use of this format can
-be declared by referencing the normative link description
-schema as the the schema for the data structure that uses the
-links. The URI of the normative link description schema is:
-http://json-schema.org/links (latest version) or
-http://json-schema.org/draft-03/links (draft-03 version).
-
-
-
- The value of the "href" link description property
-indicates the target URI of the related resource. The value
-of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
-and MAY be a relative URI. The base URI to be used for relative resolution
-SHOULD be the URI used to retrieve the instance object (not the schema)
-when used within a schema. Also, when links are used within a schema, the URI
-SHOULD be parametrized by the property values of the instance
-object, if property values exist for the corresponding variables
-in the template (otherwise they MAY be provided from alternate sources, like user input).
-
-
-Instance property values SHOULD be substituted into the URIs where
-matching braces ('{', '}') are found surrounding zero or more characters,
-creating an expanded URI. Instance property value substitutions are resolved
-by using the text between the braces to denote the property name
-from the instance to get the value to substitute. For example,
-if an href value is defined:
-
-
+
+
+
+
+
+
+
+ This attribute defines the current URI of this schema (this attribute is
+ effectively a "self" link). This URI MAY be relative or absolute. If
+ the URI is relative it is resolved against the current URI of the parent
+ schema it is contained in. If this schema is not contained in any
+ parent schema, the current URI of the parent schema is held to be the
+ URI under which this schema was addressed. If id is missing, the current URI of a schema is
+ defined to be that of the parent schema. The current URI of the schema
+ is also used to construct relative references such as for $ref.
+
+
+
+
+
+ This attribute defines a URI of a schema that contains the full representation of this schema.
+ When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
+ This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+
+ This attribute defines a URI of a JSON Schema that is the schema of the current schema.
+ When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+
+
+ A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
+ Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
+
+
+
+
+
+
+ The following attributes are specified in addition to those
+ attributes that already provided by the core schema with the specific
+ purpose of informing user agents of relations between resources based
+ on JSON data. Just as with JSON
+ schema attributes, all the attributes in hyper schemas are optional.
+ Therefore, an empty object is a valid (non-informative) schema, and
+ essentially describes plain JSON (no constraints on the structures).
+ Addition of attributes provides additive information for user agents.
+
+
+
+
+ The value of the links property MUST be an array, where each item
+ in the array is a link description object which describes the link
+ relations of the instances.
+
+
+
+
+ A link description object is used to describe link relations. In
+ the context of a schema, it defines the link relations of the
+ instances of the schema, and can be parameterized by the instance
+ values. The link description format can be used on its own in
+ regular (non-schema documents), and use of this format can
+ be declared by referencing the normative link description
+ schema as the the schema for the data structure that uses the
+ links. The URI of the normative link description schema is:
+ http://json-schema.org/links (latest version) or
+ http://json-schema.org/draft-03/links (draft-03 version).
+
+
+
+
+ The value of the "href" link description property
+ indicates the target URI of the related resource. The value
+ of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
+ and MAY be a relative URI. The base URI to be used for relative resolution
+ SHOULD be the URI used to retrieve the instance object (not the schema)
+ when used within a schema. Also, when links are used within a schema, the URI
+ SHOULD be parametrized by the property values of the instance
+ object, if property values exist for the corresponding variables
+ in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more characters,
+ creating an expanded URI. Instance property value substitutions are resolved
+ by using the text between the braces to denote the property name
+ from the instance to get the value to substitute.
+
+
+ For example, if an href value is defined:
+
+
-
-Then it would be resolved by replace the value of the "id" property value from
-the instance object. If the value of the "id" property was "45", the expanded
-URI would be:
-
-
+
+ Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+
+
+ If the value of the "id" property was "45", the expanded URI would be:
+
+
-
-If matching braces are found with the string "@" (no quotes) between the braces, then the
-actual instance value SHOULD be used to replace the braces, rather than a property value.
-This should only be used in situations where the instance is a scalar (string,
-boolean, or number), and not for objects or arrays.
-
-
-
-
-The value of the "rel" property indicates the name of the
-relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-
-
-Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
-
-
-If the relation value is "self", when this property is encountered in
-the instance object, the object represents a resource and the instance object is
-treated as a full representation of the target resource identified by
-the specified URI.
-
-
-This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
-
-
-This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
-This relation indicates that the target of the link
-SHOULD be treated as the root or the body of the representation for the
-purposes of user agent interaction or fragment resolution. All other
-properties of the instance objects can be regarded as meta-data
-descriptions for the data.
-
-
-
-
-The following relations are applicable for schemas (the schema as the "from" resource in the relation):
-
-
-This indicates the target resource that represents collection of instances of a schema.
-
-
-This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
-
-
-
-
-For example, if a schema is defined:
-
-
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the
+ actual instance value SHOULD be used to replace the braces, rather than a property value.
+ This should only be used in situations where the instance is a scalar (string,
+ boolean, or number), and not for objects or arrays.
+
+
+
+
+
+ The value of the "rel" property indicates the name of the
+ relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+
+ If the relation value is "self", when this property is encountered in
+ the instance object, the object represents a resource and the instance object is
+ treated as a full representation of the target resource identified by
+ the specified URI.
+
+
+
+ This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
+
+
+
+ This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
+ This relation indicates that the target of the link
+ SHOULD be treated as the root or the body of the representation for the
+ purposes of user agent interaction or fragment resolution. All other
+ properties of the instance objects can be regarded as meta-data
+ descriptions for the data.
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+ This indicates the target resource that represents collection of instances of a schema.
+ This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+
+
+ For example, if a schema is defined:
+
+
-
-And if a collection of instance resource's JSON representation was
-retrieved:
-
-
+
+
+
+
+ And if a collection of instance resource's JSON representation was retrieved:
+
+
-
+[{
+ "id": "thing",
+ "upId": "parent"
+}, {
+ "id": "thing2",
+ "upId": "parent"
+}]
+]]>
+
+
-This would indicate that for the first item in the collection, its own
-(self) URI would resolve to "/Resource/thing" and the first item's "up"
-relation SHOULD be resolved to the resource at "/Resource/parent".
-The "children" collection would be located at "/Resource/?upId=thing".
-
-
-
-This property value is a schema that defines the expected
-structure of the JSON representation of the target of the link.
-
-
-
-The following properties also apply to link definition objects, and
-provide functionality analogous to HTML forms, in providing a
-means for submitting extra (often user supplied) information to send to a server.
-
-
-
-
-This attribute defines which method can be used to access the target resource.
-In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
-such as "PUT" and "DELETE" have semantics that are clearly implied by
-accessed resources, and do not need to be defined here).
-This defaults to "GET".
-
-
-
-
-
-If present, this property indicates a query media type format that the server
-supports for querying or posting to the collection of instances at the target
-resource. The query can be
-suffixed to the target URI to query the collection with
-property-based constraints on the resources that SHOULD be returned from
-the server or used to post data to the resource (depending on the method).
-For example, with the following schema:
-
-
+
+
+
+ This property value is a schema that defines the expected structure of the JSON representation of the target of the link.
+
+
+
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a
+ means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+ such as "PUT" and "DELETE" have semantics that are clearly implied by
+ accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
+
+
+
+
+ If present, this property indicates a query media type format that the server
+ supports for querying or posting to the collection of instances at the target
+ resource. The query can be
+ suffixed to the target URI to query the collection with
+ property-based constraints on the resources that SHOULD be returned from
+ the server or used to post data to the resource (depending on the method).
+
+
+ For example, with the following schema:
+
+
-
-This indicates that the client can query the server for instances that
-have a specific name:
-
-
+
+ This indicates that the client can query the server for instances that have a specific name.
+
+
+
+ For example:
+
+
-
+]]>
+
+
-If no enctype or method is specified, only the single URI specified by
-the href property is defined. If the method is POST, "application/json" is
-the default media type.
-
-
-
-
-This attribute contains a schema which defines the acceptable structure of the submitted
-request (for a GET request, this schema would define the properties for the query string
-and for a POST request, this would define the body).
-
-
-
-
-
-
-
- This property indicates the fragment resolution protocol to use for
-resolving fragment identifiers in URIs within the instance
-representations. This applies to the instance object URIs and all
-children of the instance object's URIs. The default fragment resolution
-protocol is "slash-delimited", which is defined below. Other fragment
-resolution protocols MAY be used, but are not defined in this
-document.
-
-
-
-The fragment identifier is based on RFC 2396, Sec 5, and defines the
-mechanism for resolving references to entities within a document.
-
-
-With the slash-delimited fragment resolution protocol, the fragment
-identifier is interpreted as a series of property reference tokens that start with and
-are delimited by the "/" character (\x2F). Each property reference token
-is a series of unreserved or escaped URI characters. Each property
-reference token SHOULD be interpreted, starting from the beginning of
-the fragment identifier, as a path reference in the target JSON
-structure. The final target value of the fragment can be determined by
-starting with the root of the JSON structure from the representation of
-the resource identified by the pre-fragment URI. If the target is a JSON
-object, then the new target is the value of the property with the name
-identified by the next property reference token in the fragment. If the
-target is a JSON array, then the target is determined by finding the
-item in array the array with the index defined by the next property
-reference token (which MUST be a number). The target is successively
-updated for each property reference token, until the entire fragment has
-been traversed.
-
-
-Property names SHOULD be URI-encoded. In particular, any "/" in a
-property name MUST be encoded to avoid being interpreted as a property
-delimiter.
-
-
-For example, for the following JSON representation:
-
-
+
+
+
+
+ This attribute contains a schema which defines the acceptable structure of the submitted
+ request (for a GET request, this schema would define the properties for the query string
+ and for a POST request, this would define the body).
+
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment resolution
+ protocol is "slash-delimited", which is defined below. Other fragment
+ resolution protocols MAY be used, but are not defined in this document.
+
+
+
+ The fragment identifier is based on RFC 2396, Sec 5, and defines the
+ mechanism for resolving references to entities within a document.
+
+
+
+
+ With the slash-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens that start with and
+ are delimited by the "/" character (\x2F). Each property reference token
+ is a series of unreserved or escaped URI characters. Each property
+ reference token SHOULD be interpreted, starting from the beginning of
+ the fragment identifier, as a path reference in the target JSON
+ structure. The final target value of the fragment can be determined by
+ starting with the root of the JSON structure from the representation of
+ the resource identified by the pre-fragment URI. If the target is a JSON
+ object, then the new target is the value of the property with the name
+ identified by the next property reference token in the fragment. If the
+ target is a JSON array, then the target is determined by finding the
+ item in array the array with the index defined by the next property
+ reference token (which MUST be a number). The target is successively
+ updated for each property reference token, until the entire fragment has
+ been traversed.
+
+
+
+ Property names SHOULD be URI-encoded. In particular, any "/" in a
+ property name MUST be encoded to avoid being interpreted as a property
+ delimiter.
+
+
+
+
+ For example, for the following JSON representation:
+
+
-
-The following fragment identifiers would be resolved:
-
-
+
+
+
+
+ The following fragment identifiers would be resolved:
+
+
-
-
-
-
-The dot-delimited fragment resolution protocol is the same as
-slash-delimited fragment resolution protocol except that the "." character
-(\x2E) is used as the delimiter between property names (instead of "/") and
-the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
-identifiers for referencing the value of the foo propery.
-
-
-
-
-
-
-This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
-
-
-If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
-
-
-
-
-
-This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
-The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
-and is relative to the instance's URI.
-
-
-When multiple schemas have been referenced for an instance, the user agent
-can determine if this schema is applicable for a particular instance by
-determining if the URI of the instance begins with the the value of the "pathStart"
-attribute. If the URI of the instance does not start with this URI,
-or if another schema specifies a starting URI that is longer and also matches the
-instance, this schema SHOULD NOT be applied to the instance. Any schema
-that does not have a pathStart attribute SHOULD be considered applicable
-to all the instances for which it is referenced.
-
-
-
-
-This attribute defines the media type of the instance representations that this schema is defining.
-
-
-
-
-
-
-
-
-
-This specification is a sub-type of the JSON format, and
-consequently the security considerations are generally the same as RFC 4627.
-However, an additional issue is that when link relation of "self"
-is used to denote a full representation of an object, the user agent
-SHOULD NOT consider the representation to be the authoritative representation
-of the resource denoted by the target URI if the target URI is not
-equivalent to or a sub-path of the the URI used to request the resource
-representation which contains the target URI with the "self" link.
-For example, if a hyper schema was defined:
-
-
+
+
+
+
+
+
+
+ The dot-delimited fragment resolution protocol is the same as
+ slash-delimited fragment resolution protocol except that the "." character
+ (\x2E) is used as the delimiter between property names (instead of "/") and
+ the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
+ identifiers for referencing the value of the foo propery.
+
+
+
+
+
+ This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+
+ If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
+
+
+
+
+ This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+ The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
+ and is relative to the instance's URI.
+
+
+
+ When multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance by
+ determining if the URI of the instance begins with the the value of the "pathStart"
+ attribute. If the URI of the instance does not start with this URI,
+ or if another schema specifies a starting URI that is longer and also matches the
+ instance, this schema SHOULD NOT be applied to the instance. Any schema
+ that does not have a pathStart attribute SHOULD be considered applicable
+ to all the instances for which it is referenced.
+
+
+
+
+ This attribute defines the media type of the instance representations that this schema is defining.
+
+
+
+
+
+ This specification is a sub-type of the JSON format, and
+ consequently the security considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self"
+ is used to denote a full representation of an object, the user agent
+ SHOULD NOT consider the representation to be the authoritative representation
+ of the resource denoted by the target URI if the target URI is not
+ equivalent to or a sub-path of the the URI used to request the resource
+ representation which contains the target URI with the "self" link.
+
+
+ For example, if a hyper schema was defined:
+
+
-
-And a resource was requested from somesite.com:
-
-
+
+
+
+
+ And a resource was requested from somesite.com:
+
+
-
+]]>
+
+
-With a response of:
-
-
+ With a response of:
+
+
-
-
-
-
-
- The proposed MIME media type for JSON Schema is "application/schema+json".
-
-
- Type name: application
-
-
- Subtype name: schema+json
-
-
- Required parameters: profile
-
-
- The value of the profile parameter SHOULD be a URI (relative or absolute) that
- refers to the schema used to define the structure of this structure (the
- meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
- but it is allowable to use other schemas that extend the hyper schema's meta-
- schema.
-
-
- Optional parameters: pretty
-
-
- The value of the pretty parameter MAY be true or false to indicate if additional
- whitespace has been included to make the JSON representation easier to read.
-
-
-
-
-This registry is maintained by IANA per RFC 4287 and this specification adds
-four values: "full", "create", "instances", "root". New
- assignments are subject to IESG Approval, as outlined in RFC 5226.
- Requests should be made by email to IANA, which will then forward the
- request to the IESG, requesting approval.
-
-
-
-
-
-
-
-
-
-
-
- &rfc2045;
- &rfc2119;
- &rfc2396;
- &rfc3339;
- &rfc3986;
- &rfc4287;
-
-
-
- &rfc2616;
- &rfc4627;
- &rfc5226;
- &iddiscovery;
- &uritemplate;
- &linkheader;
- &html401;
- &css21;
-
-
-
-
-
-
-
-
-
- Added example and verbiage to "extends" attribute.
- Defined slash-delimited to use a leading slash.
- Made "root" a relation instead of an attribute.
- Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
- Added more explanation of nullability.
- Removed "alternate" attribute.
- Upper cased many normative usages of must, may, and should.
- Replaced the link submission "properties" attribute to "schema" attribute.
- Replaced "optional" attribute with "required" attribute.
- Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
- Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
- Replaced "requires" attribute with "dependencies" attribute.
- Moved "contentEncoding" attribute to hyper schema.
- Added "additionalItems" attribute.
- Added "id" attribute.
- Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
- Added "patternProperties" attribute.
- Schema URIs are now namespace versioned.
- Added "$ref" and "$schema" attributes.
-
-
-
-
- Replaced "maxDecimal" attribute with "divisibleBy" attribute.
- Added slash-delimited fragment resolution protocol and made it the default.
- Added language about using links outside of schemas by referencing its normative URI.
- Added "uniqueItems" attribute.
- Added "targetSchema" attribute to link description object.
-
-
-
-
-
- Fixed category and updates from template.
-
-
-
-
- Initial draft.
-
-
-
-
-
+[{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+}, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+}, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+}]
+]]>
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is "application/schema+json".
+ Type name: application
+ Subtype name: schema+json
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+ Optional parameters: pretty
+ The value of the pretty parameter MAY be true or false to indicate if additional whitespace has been included to make the JSON representation easier to read.
+
+
+
+ This registry is maintained by IANA per RFC 4287 and this specification adds
+ four values: "full", "create", "instances", "root". New
+ assignments are subject to IESG Approval, as outlined in RFC 5226.
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc2396;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
-
-
-
- Should we give a preference to MIME headers over Link headers (or only use one)?
- Should "root" be a MIME parameter?
- Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
- How should dates be handled?
-
-
-
-
-
-
+
+
+
+
+
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema" attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
+ Replaced "requires" attribute with "dependencies" attribute.
+ Moved "contentEncoding" attribute to hyper schema.
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
+ Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
+
+
+
+
+
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+ Added slash-delimited fragment resolution protocol and made it the default.
+ Added language about using links outside of schemas by referencing its normative URI.
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
+
+
+
+
+
+ Fixed category and updates from template.
+
+
+
+
+
+ Initial draft.
+
+
+
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should "root" be a MIME parameter?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
+ How should dates be handled?
+
+
+
+
+
\ No newline at end of file
From 60fb39c252d70a9c6cc6ec4bb7eb5e217139845c Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Mon, 16 May 2011 16:03:33 -0600
Subject: [PATCH 0044/1659] Add next version
---
draft-zyp-json-schema-04.xml | 1014 ++++++++++++++++++++++++++++++++++
1 file changed, 1014 insertions(+)
create mode 100644 draft-zyp-json-schema-04.xml
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
new file mode 100644
index 00000000..69f75447
--- /dev/null
+++ b/draft-zyp-json-schema-04.xml
@@ -0,0 +1,1014 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+ SitePen (USA)
+
+
+
+ 530 Lytton Avenue
+
+ Palo Alto, CA 94301
+
+ USA
+
+
+ +1 650 968 8787
+
+ kris@sitepen.com
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+
+ Internet Engineering Task Force
+
+ JSON
+ Schema
+ JavaScript
+ Object
+ Notation
+ Hyper Schema
+ Hypermedia
+
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+ 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.
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primarily
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+ This schema defines the properties of the instance JSON documents,
+ the required properties (id, name, and price), as well as an optional
+ property (tags). This also defines the link relations of the instance
+ JSON documents.
+
+
+
+ For this specification, schema will be used to denote a JSON Schema
+ definition, and an instance refers to a JSON value that the schema
+ will be describing and validating.
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. It is acknowledged that JSON documents come
+ in a variety of structures, and JSON is unique in that the structure
+ of stored data structures often prescribes a non-ambiguous definite
+ JSON representation. Attempting to force a specific structure is generally
+ not viable, and therefore JSON Schema allows for a great flexibility
+ in the structure of the JSON data that it describes.
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a representational state transfer
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the "application/json" media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+ ; rel="describedby"
+]]>
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data, and the data SHOULD be valid by all the schemas.
+ The instance data MAY have multiple schemas
+ that it is defined by (the instance data SHOULD be valid for those schemas).
+ Or if the document is a collection of instances, the collection MAY contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the "pathStart" attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection. However, ultimately, the mechanism for referencing a schema is up to the
+ media type of the instance documents (if they choose to specify that schemas
+ can be referenced).
+
+
+
+ JSON Schemas can themselves be described using JSON Schemas.
+ A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema
+ or http://json-schema.org/draft-03/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ (including usage and valid values) of a JSON value. JSON
+ Schema has recursive capabilities; there are a number of elements
+ in the structure that allow for nested JSON Schemas.
+
+ An example JSON Schema definition could look like:
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
+This attribute can take one of two forms:
+
+
+A string indicating a primitive or simple type. The following are acceptable string values:
+
+
+Value MUST be a string.
+Value MUST be a number, floating point numbers are allowed.
+Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
+Value MUST be a boolean.
+Value MUST be an object.
+Value MUST be an array.
+Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
+included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
+Value MAY be of any type including null.
+
+
+If the property is not defined or is not in this list, then any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema. The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
+
+
+
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
+
+
+
+This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+
+This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+
+
+This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
+
+
+This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
+When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
+When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
+
+
+This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
+
+
+This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
+
+
+This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
+
+The dependency value can take one of two forms:
+
+If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value. If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
+If the dependency value is a schema, then the instance object MUST be valid against the schema.
+
+
+
+
+This attribute defines the minimum value of the instance property when the type of the instance value is a number.
+
+
+This attribute defines the maximum value of the instance property when the type of the instance value is a number.
+
+
+This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
+
+
+This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
+
+
+This attribute defines the minimum number of values in an array when the array is the instance value.
+
+
+This attribute defines the maximum number of values in an array when the array is the instance value.
+
+
+This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
+Two instance are consider equal if they are both of the same type and:
+
+are null; or
+are booleans/numbers/strings and have the same value; or
+are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
+
+
+
+
+When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
+
+When the instance value is a string, this defines the minimum length of the string.
+
+
+When the instance value is a string, this defines the maximum length of the string.
+
+
+This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+
+This attribute defines the default value of the instance when the instance is undefined.
+
+
+This attribute is a string that provides a short description of the instance property.
+
+
+This attribute is a string that provides a full description of the of purpose the instance property.
+
+
+This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format. The following formats are predefined:
+
+
+This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
+A regular expression, following the regular expression specification from ECMA 262/Perl 5.
+This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
+This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
+This SHOULD be a phone number (format MAY follow E.123).
+This value SHOULD be a URI..
+This SHOULD be an email address.
+This SHOULD be an ip version 4 address.
+This SHOULD be an ip version 6 address.
+This SHOULD be a host-name.
+
+
+Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
+
+
+This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
+
+
+This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
+
+
+The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
+Conceptually, the behavior of extends can be seen as validating an
+instance against all constraints in the extending schema as well as
+the extended schema(s). More optimized implementations that merge
+schemas are possible, but are not required. An example of using "extends":
+
+
+
+
+
+
+
+
+
+
+This attribute defines the current URI of this schema (this attribute is
+effectively a "self" link). This URI MAY be relative or absolute. If
+the URI is relative it is resolved against the current URI of the parent
+schema it is contained in. If this schema is not contained in any
+parent schema, the current URI of the parent schema is held to be the
+URI under which this schema was addressed. If id is missing, the current URI of a schema is
+defined to be that of the parent schema. The current URI of the schema
+is also used to construct relative references such as for $ref.
+
+
+
+This attribute defines a URI of a schema that contains the full representation of this schema.
+When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
+This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+This attribute defines a URI of a JSON Schema that is the schema of the current schema.
+When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+
+A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
+Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
+
+
+
+
+ The following attributes are specified in addition to those
+attributes that already provided by the core schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper schemas are optional.
+Therefore, an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+
+
+The value of the links property MUST be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+
+A link description object is used to describe link relations. In
+the context of a schema, it defines the link relations of the
+instances of the schema, and can be parameterized by the instance
+values. The link description format can be used on its own in
+regular (non-schema documents), and use of this format can
+be declared by referencing the normative link description
+schema as the the schema for the data structure that uses the
+links. The URI of the normative link description schema is:
+http://json-schema.org/links (latest version) or
+http://json-schema.org/draft-03/links (draft-03 version).
+
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
+and MAY be a relative URI. The base URI to be used for relative resolution
+SHOULD be the URI used to retrieve the instance object (not the schema)
+when used within a schema. Also, when links are used within a schema, the URI
+SHOULD be parametrized by the property values of the instance
+object, if property values exist for the corresponding variables
+in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+Instance property values SHOULD be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+If matching braces are found with the string "@" (no quotes) between the braces, then the
+actual instance value SHOULD be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
+
+
+This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+This relation indicates that the target of the link
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction or fragment resolution. All other
+properties of the instance objects can be regarded as meta-data
+descriptions for the data.
+
+
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+This indicates the target resource that represents collection of instances of a schema.
+
+
+This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+
+For example, if a schema is defined:
+
+
+
+And if a collection of instance resource's JSON representation was
+retrieved:
+
+
+
+
+This would indicate that for the first item in the collection, its own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation SHOULD be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+
+This property value is a schema that defines the expected
+structure of the JSON representation of the target of the link.
+
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+This attribute defines which method can be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, "application/json" is
+the default media type.
+
+
+
+
+This attribute contains a schema which defines the acceptable structure of the submitted
+request (for a GET request, this schema would define the properties for the query string
+and for a POST request, this would define the body).
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "slash-delimited", which is defined below. Other fragment
+resolution protocols MAY be used, but are not defined in this
+document.
+
+
+
+The fragment identifier is based on RFC 2396, Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
+With the slash-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that start with and
+are delimited by the "/" character (\x2F). Each property reference token
+is a series of unreserved or escaped URI characters. Each property
+reference token SHOULD be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, then the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, then the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+Property names SHOULD be URI-encoded. In particular, any "/" in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+For example, for the following JSON representation:
+
+
+
+The following fragment identifiers would be resolved:
+
+
+
+
+
+
+The dot-delimited fragment resolution protocol is the same as
+slash-delimited fragment resolution protocol except that the "." character
+(\x2E) is used as the delimiter between property names (instead of "/") and
+the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
+identifiers for referencing the value of the foo propery.
+
+
+
+
+
+
+This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
+
+
+
+
+
+This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
+and is relative to the instance's URI.
+
+
+When multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if the URI of the instance begins with the the value of the "pathStart"
+attribute. If the URI of the instance does not start with this URI,
+or if another schema specifies a starting URI that is longer and also matches the
+instance, this schema SHOULD NOT be applied to the instance. Any schema
+that does not have a pathStart attribute SHOULD be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+This attribute defines the media type of the instance representations that this schema is defining.
+
+
+
+
+
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC 4627.
+However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+
+And a resource was requested from somesite.com:
+
+
+
+
+With a response of:
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is "application/schema+json".
+
+
+ Type name: application
+
+
+ Subtype name: schema+json
+
+
+ Required parameters: profile
+
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+ Optional parameters: pretty
+
+
+ The value of the pretty parameter MAY be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+four values: "full", "create", "instances", "root". New
+ assignments are subject to IESG Approval, as outlined in RFC 5226.
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc2396;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
+
+
+
+
+
+
+
+
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema" attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
+ Replaced "requires" attribute with "dependencies" attribute.
+ Moved "contentEncoding" attribute to hyper schema.
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
+ Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
+
+
+
+
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+ Added slash-delimited fragment resolution protocol and made it the default.
+ Added language about using links outside of schemas by referencing its normative URI.
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
+
+
+
+
+
+ Fixed category and updates from template.
+
+
+
+
+ Initial draft.
+
+
+
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should "root" be a MIME parameter?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
+ How should dates be handled?
+
+
+
+
+
+
From 7295b3b0314355d6864907fead956ee3eb4f511a Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Mon, 16 May 2011 16:03:42 -0600
Subject: [PATCH 0045/1659] Add maintainers to package.json
---
package.json | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package.json b/package.json
index d986a319..8e49bed4 100644
--- a/package.json
+++ b/package.json
@@ -2,6 +2,8 @@
"name": "json-schema",
"version": "0.2.0",
"author": "Kris Zyp",
+ "maintainers":[
+ {"name": "Kris Zyp", "email": "kriszyp@gmail.com"}],
"keywords": [
"json",
"schema"
From 694b44a576392a5042b52d0902b3166dba530e06 Mon Sep 17 00:00:00 2001
From: Georg Leciejewski
Date: Wed, 18 May 2011 00:33:09 -0700
Subject: [PATCH 0046/1659] removed duplicate "required":true in price example
---
draft-zyp-json-schema-04.xml | 1 -
1 file changed, 1 deletion(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 69f75447..a231b540 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -141,7 +141,6 @@
"required":true
},
"price":{
- "required":true,
"type": "number",
"minimum":0,
"required":true
From 3d58f91ff95d1923cbcc0111816d8f77fa5427da Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 7 Jun 2011 14:51:34 -0600
Subject: [PATCH 0047/1659] Fixed property name
---
draft-zyp-json-schema-03.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-03.xml b/draft-zyp-json-schema-03.xml
index 4f6643e3..d7b0295a 100644
--- a/draft-zyp-json-schema-03.xml
+++ b/draft-zyp-json-schema-03.xml
@@ -128,7 +128,7 @@
An example JSON Schema that describes products might look like:
Date: Mon, 20 Jun 2011 14:01:26 -0600
Subject: [PATCH 0048/1659] Copied over draft 3 beautification to draft 4.
---
draft-zyp-json-schema-04.xml | 1992 ++++++++++++++++++----------------
1 file changed, 1049 insertions(+), 943 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index a231b540..3703f992 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -21,749 +21,868 @@
-
-
-
- A JSON Media Type for Describing the Structure and Meaning of JSON Documents
-
-
- SitePen (USA)
-
-
-
- 530 Lytton Avenue
-
- Palo Alto, CA 94301
-
- USA
-
-
- +1 650 968 8787
-
- kris@sitepen.com
-
-
-
-
-
-
- Calgary, AB
- Canada
-
- gary.court@gmail.com
-
-
-
-
-
- Internet Engineering Task Force
-
- JSON
- Schema
- JavaScript
- Object
- Notation
- Hyper Schema
- Hypermedia
-
-
-
-
- JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
- a JSON based format for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
-
-
-
- JSON (JavaScript Object Notation) Schema is a JSON media type for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
- 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.
-
-
-
-
-
- JSON Schema defines the media type "application/schema+json" for
- describing the structure of other
- JSON documents. JSON Schema is JSON-based and includes facilities
- for describing the structure of JSON documents in terms of
- allowable values, descriptions, and interpreting relations with other resources.
-
- JSON Schema format is organized into several separate definitions. The first
- definition is the core schema specification. This definition is primarily
- concerned with describing a JSON structure and specifying valid elements
- in the structure. The second definition is the Hyper Schema specification
- which is intended define elements in a structure that can be interpreted as
- hyperlinks.
- Hyper Schema builds on JSON Schema to describe the hyperlink structure of
- other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
- JSON documents based on their schemas.
-
-
- Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
- property values, as well as define the meaning of the property values
- for the purpose of describing a resource and determining hyperlinks
- within the representation.
-
-
- An example JSON Schema that describes products might look like:
-
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ JavaScript
+ Object
+ Notation
+ Hyper Schema
+ Hypermedia
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
-
- This schema defines the properties of the instance JSON documents,
- the required properties (id, name, and price), as well as an optional
- property (tags). This also defines the link relations of the instance
- JSON documents.
-
-
-
- For this specification, schema will be used to denote a JSON Schema
- definition, and an instance refers to a JSON value that the schema
- will be describing and validating.
-
-
-
-
- The JSON Schema media type does not attempt to dictate the structure of JSON
- representations that contain data, but rather provides a separate format
- for flexibly communicating how a JSON representation should be
- interpreted and validated, such that user agents can properly understand
- acceptable structures and extrapolate hyperlink information
- with the JSON document. It is acknowledged that JSON documents come
- in a variety of structures, and JSON is unique in that the structure
- of stored data structures often prescribes a non-ambiguous definite
- JSON representation. Attempting to force a specific structure is generally
- not viable, and therefore JSON Schema allows for a great flexibility
- in the structure of the JSON data that it describes.
-
- This specification is protocol agnostic.
- The underlying protocol (such as HTTP) should sufficiently define the
- semantics of the client-server interface, the retrieval of resource
- representations linked to by JSON representations, and modification of
- those resources. The goal of this
- format is to sufficiently describe JSON structures such that one can
- utilize existing information available in existing JSON
- representations from a large variety of services that leverage a representational state transfer
- architecture using existing protocols.
-
-
-
-
-
-
- JSON Schema instances are correlated to their schema by the "describedby"
- relation, where the schema is defined to be the target of the relation.
- Instance representations may be of the "application/json" media type or
- any other subtype. Consequently, dictating how an instance
- representation should specify the relation to the schema is beyond the normative scope
- of this document (since this document specifically defines the JSON
- Schema media type, and no other), but it is recommended that instances
- specify their schema so that user agents can interpret the instance
- representation and messages may retain the self-descriptive
- characteristic, avoiding the need for out-of-band information about
- instance data. Two approaches are recommended for declaring the
- relation to the schema that describes the meaning of a JSON instance's (or collection
- of instances) structure. A MIME type parameter named
- "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
-
-
+
+
+ This schema defines the properties of the instance JSON documents,
+ the required properties (id, name, and price), as well as an optional
+ property (tags). This also defines the link relations of the instance
+ JSON documents.
+
+
+
+
+
+ For this specification, schema will be used to denote a JSON Schema
+ definition, and an instance refers to a JSON value that the schema
+ will be describing and validating.
+
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. It is acknowledged that JSON documents come
+ in a variety of structures, and JSON is unique in that the structure
+ of stored data structures often prescribes a non-ambiguous definite
+ JSON representation. Attempting to force a specific structure is generally
+ not viable, and therefore JSON Schema allows for a great flexibility
+ in the structure of the JSON data that it describes.
+
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a representational state transfer
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the "application/json" media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
+
+
+
+
- or if the content is being transferred by a protocol (such as HTTP) that
- provides headers, a Link header can be used:
-
-
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+
+; rel="describedby"
-]]>
- Instances MAY specify multiple schemas, to indicate all the schemas that
- are applicable to the data, and the data SHOULD be valid by all the schemas.
- The instance data MAY have multiple schemas
- that it is defined by (the instance data SHOULD be valid for those schemas).
- Or if the document is a collection of instances, the collection MAY contain
- instances from different schemas. When collections contain heterogeneous
- instances, the "pathStart" attribute MAY be specified in the
- schema to disambiguate which schema should be applied for each item in the
-collection. However, ultimately, the mechanism for referencing a schema is up to the
- media type of the instance documents (if they choose to specify that schemas
- can be referenced).
-
-
-
- JSON Schemas can themselves be described using JSON Schemas.
- A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema for the latest version or
- http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
- self-description can be found at http://json-schema.org/hyper-schema
- or http://json-schema.org/draft-03/hyper-schema. All schemas
- used within a protocol with media type definitions
- SHOULD include a MIME parameter that refers to the self-descriptive
- hyper schema or another schema that extends this hyper schema:
-
-
+
+
+
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data, and the data SHOULD be valid by all the schemas.
+ The instance data MAY have multiple schemas
+ that it is defined by (the instance data SHOULD be valid for those schemas).
+ Or if the document is a collection of instances, the collection MAY contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the "pathStart" attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+ collection. However, ultimately, the mechanism for referencing a schema is up to the
+ media type of the instance documents (if they choose to specify that schemas
+ can be referenced).
+
+
+
+
+ JSON Schemas can themselves be described using JSON Schemas.
+ A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema
+ or http://json-schema.org/draft-03/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
-
-
-
-
-
- A JSON Schema is a JSON Object that defines various attributes
- (including usage and valid values) of a JSON value. JSON
- Schema has recursive capabilities; there are a number of elements
- in the structure that allow for nested JSON Schemas.
-
- An example JSON Schema definition could look like:
-
-
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ (including usage and valid values) of a JSON value. JSON
+ Schema has recursive capabilities; there are a number of elements
+ in the structure that allow for nested JSON Schemas.
+
+
+
+ An example JSON Schema definition could look like:
+
+
-
-
- A JSON Schema object may have any of the following properties, called schema
- attributes (all attributes are optional):
-
-
-
-
-This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
-This attribute can take one of two forms:
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "age": {
+ "type": "integer",
+ "maximum": 125
+ }
+ }
+}
+]]>
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+ This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
+ This attribute can take one of two forms:
-
-A string indicating a primitive or simple type. The following are acceptable string values:
+
+
+ A string indicating a primitive or simple type. The following are acceptable string values:
-
-Value MUST be a string.
-Value MUST be a number, floating point numbers are allowed.
-Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
-Value MUST be a boolean.
-Value MUST be an object.
-Value MUST be an array.
-Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not
-included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
-Value MAY be of any type including null.
-
-
-If the property is not defined or is not in this list, then any type of value is acceptable. Other type values MAY be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
-
-An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema. The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
-
-
-
-
- For example, a schema that defines if an instance can be a string or a number would be:
-
+ Value MUST be a string.
+ Value MUST be a number, floating point numbers are allowed.
+ Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
+ Value MUST be a boolean.
+ Value MUST be an object.
+ Value MUST be an array.
+ Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
+ Value MAY be of any type including null.
+
+
+ If the property is not defined or is not in this list, then any type of value is acceptable.
+ Other type values MAY be used for custom purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type values.
+
+
+
+ An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema.
+ The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
+
+
+
+
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
+
-
-
-
-This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
-
-
-This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
-
-
-This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
-
-
-This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
-When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
-When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
-
-
-This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
-
-
-This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
-
-
-This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
-
-The dependency value can take one of two forms:
-
-If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value. If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
-If the dependency value is a schema, then the instance object MUST be valid against the schema.
-
-
-
-
-This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-
-
-This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-
-
-This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-
-
-This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-
-
-This attribute defines the minimum number of values in an array when the array is the instance value.
-
-
-This attribute defines the maximum number of values in an array when the array is the instance value.
-
-
-This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
-Two instance are consider equal if they are both of the same type and:
-
-are null; or
-are booleans/numbers/strings and have the same value; or
-are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
-are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
-
-
-
-
-When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
-When the instance value is a string, this defines the minimum length of the string.
-
-
-When the instance value is a string, this defines the maximum length of the string.
-
-
-This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
-
-
-This attribute defines the default value of the instance when the instance is undefined.
-
-
-This attribute is a string that provides a short description of the instance property.
-
-
-This attribute is a string that provides a full description of the of purpose the instance property.
-
-
-This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format. The following formats are predefined:
-
-
-This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
-This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
-This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
-This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
-A regular expression, following the regular expression specification from ECMA 262/Perl 5.
-This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
-This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
-This SHOULD be a phone number (format MAY follow E.123).
-This value SHOULD be a URI..
-This SHOULD be an email address.
-This SHOULD be an ip version 4 address.
-This SHOULD be an ip version 6 address.
-This SHOULD be a host-name.
-
-
-Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
-
-
-This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
-
-
-This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-
-
-The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
-Conceptually, the behavior of extends can be seen as validating an
-instance against all constraints in the extending schema as well as
-the extended schema(s). More optimized implementations that merge
-schemas are possible, but are not required. An example of using "extends":
-
-
+
+
+
+ This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+
+
+ This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+
+
+
+ This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
+
+
+
+ This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
+ When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
+ When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
+
+
+
+ This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
+
+
+
+ This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
+
+
+
+ This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
+
+ The dependency value can take one of two forms:
+
+
+
+ If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value.
+ If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
+
+
+ If the dependency value is a schema, then the instance object MUST be valid against the schema.
+
+
+
+
+
+
+ This attribute defines the minimum value of the instance property when the type of the instance value is a number.
+
+
+
+ This attribute defines the maximum value of the instance property when the type of the instance value is a number.
+
+
+
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
+
+
+
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
+
+
+
+ This attribute defines the minimum number of values in an array when the array is the instance value.
+
+
+
+ This attribute defines the maximum number of values in an array when the array is the instance value.
+
+
+
+ This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
+
+ Two instance are consider equal if they are both of the same type and:
+
+
+ are null; or
+ are booleans/numbers/strings and have the same value; or
+ are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+ are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
+
+
+
+
+
+ When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
+
+
+
+ When the instance value is a string, this defines the minimum length of the string.
+
+
+
+ When the instance value is a string, this defines the maximum length of the string.
+
+
+
+ This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+
+
+ This attribute defines the default value of the instance when the instance is undefined.
+
+
+
+ This attribute is a string that provides a short description of the instance property.
+
+
+
+ This attribute is a string that provides a full description of the of purpose the instance property.
+
+
+
+ This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format.
+
+
+ The following formats are predefined:
+
+
+ This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+ This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+ This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+ This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
+ A regular expression, following the regular expression specification from ECMA 262/Perl 5.
+ This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
+ This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
+ This SHOULD be a phone number (format MAY follow E.123).
+ This value SHOULD be a URI.
+ This SHOULD be an email address.
+ This SHOULD be an ip version 4 address.
+ This SHOULD be an ip version 6 address.
+ This SHOULD be a host-name.
+
+
+
+ Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
+
+
+
+ This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
+
+
+
+ This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
+
+
+
+ The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
+
+ Conceptually, the behavior of extends can be seen as validating an
+ instance against all constraints in the extending schema as well as
+ the extended schema(s). More optimized implementations that merge
+ schemas are possible, but are not required. Some examples of using "extends":
+
+
+
+
-
-
+
+
+
+
+
+
-
-
-
-
-
-
-This attribute defines the current URI of this schema (this attribute is
-effectively a "self" link). This URI MAY be relative or absolute. If
-the URI is relative it is resolved against the current URI of the parent
-schema it is contained in. If this schema is not contained in any
-parent schema, the current URI of the parent schema is held to be the
-URI under which this schema was addressed. If id is missing, the current URI of a schema is
-defined to be that of the parent schema. The current URI of the schema
-is also used to construct relative references such as for $ref.
-
-
-
-This attribute defines a URI of a schema that contains the full representation of this schema.
-When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
-This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
-
-
-
-
-This attribute defines a URI of a JSON Schema that is the schema of the current schema.
-When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
-
-
-A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
-Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
-
-
-
-
- The following attributes are specified in addition to those
-attributes that already provided by the core schema with the specific
-purpose of informing user agents of relations between resources based
-on JSON data. Just as with JSON
-schema attributes, all the attributes in hyper schemas are optional.
-Therefore, an empty object is a valid (non-informative) schema, and
-essentially describes plain JSON (no constraints on the structures).
-Addition of attributes provides additive information for user agents.
-
-
-
-The value of the links property MUST be an array, where each item
-in the array is a link description object which describes the link
-relations of the instances.
-
-
-
-A link description object is used to describe link relations. In
-the context of a schema, it defines the link relations of the
-instances of the schema, and can be parameterized by the instance
-values. The link description format can be used on its own in
-regular (non-schema documents), and use of this format can
-be declared by referencing the normative link description
-schema as the the schema for the data structure that uses the
-links. The URI of the normative link description schema is:
-http://json-schema.org/links (latest version) or
-http://json-schema.org/draft-03/links (draft-03 version).
-
-
-
- The value of the "href" link description property
-indicates the target URI of the related resource. The value
-of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
-and MAY be a relative URI. The base URI to be used for relative resolution
-SHOULD be the URI used to retrieve the instance object (not the schema)
-when used within a schema. Also, when links are used within a schema, the URI
-SHOULD be parametrized by the property values of the instance
-object, if property values exist for the corresponding variables
-in the template (otherwise they MAY be provided from alternate sources, like user input).
-
-
-Instance property values SHOULD be substituted into the URIs where
-matching braces ('{', '}') are found surrounding zero or more characters,
-creating an expanded URI. Instance property value substitutions are resolved
-by using the text between the braces to denote the property name
-from the instance to get the value to substitute. For example,
-if an href value is defined:
-
-
+
+
+
+
+
+
+
+ This attribute defines the current URI of this schema (this attribute is
+ effectively a "self" link). This URI MAY be relative or absolute. If
+ the URI is relative it is resolved against the current URI of the parent
+ schema it is contained in. If this schema is not contained in any
+ parent schema, the current URI of the parent schema is held to be the
+ URI under which this schema was addressed. If id is missing, the current URI of a schema is
+ defined to be that of the parent schema. The current URI of the schema
+ is also used to construct relative references such as for $ref.
+
+
+
+
+
+ This attribute defines a URI of a schema that contains the full representation of this schema.
+ When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
+ This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+
+ This attribute defines a URI of a JSON Schema that is the schema of the current schema.
+ When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+
+
+ A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
+ Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
+
+
+
+
+
+
+ The following attributes are specified in addition to those
+ attributes that already provided by the core schema with the specific
+ purpose of informing user agents of relations between resources based
+ on JSON data. Just as with JSON
+ schema attributes, all the attributes in hyper schemas are optional.
+ Therefore, an empty object is a valid (non-informative) schema, and
+ essentially describes plain JSON (no constraints on the structures).
+ Addition of attributes provides additive information for user agents.
+
+
+
+
+ The value of the links property MUST be an array, where each item
+ in the array is a link description object which describes the link
+ relations of the instances.
+
+
+
+
+ A link description object is used to describe link relations. In
+ the context of a schema, it defines the link relations of the
+ instances of the schema, and can be parameterized by the instance
+ values. The link description format can be used on its own in
+ regular (non-schema documents), and use of this format can
+ be declared by referencing the normative link description
+ schema as the the schema for the data structure that uses the
+ links. The URI of the normative link description schema is:
+ http://json-schema.org/links (latest version) or
+ http://json-schema.org/draft-03/links (draft-03 version).
+
+
+
+
+ The value of the "href" link description property
+ indicates the target URI of the related resource. The value
+ of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
+ and MAY be a relative URI. The base URI to be used for relative resolution
+ SHOULD be the URI used to retrieve the instance object (not the schema)
+ when used within a schema. Also, when links are used within a schema, the URI
+ SHOULD be parametrized by the property values of the instance
+ object, if property values exist for the corresponding variables
+ in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more characters,
+ creating an expanded URI. Instance property value substitutions are resolved
+ by using the text between the braces to denote the property name
+ from the instance to get the value to substitute.
+
+
+ For example, if an href value is defined:
+
+
-
-Then it would be resolved by replace the value of the "id" property value from
-the instance object. If the value of the "id" property was "45", the expanded
-URI would be:
-
-
+
+ Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+
+
+ If the value of the "id" property was "45", the expanded URI would be:
+
+
-
-If matching braces are found with the string "@" (no quotes) between the braces, then the
-actual instance value SHOULD be used to replace the braces, rather than a property value.
-This should only be used in situations where the instance is a scalar (string,
-boolean, or number), and not for objects or arrays.
-
-
-
-
-The value of the "rel" property indicates the name of the
-relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-
-
-Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
-
-
-If the relation value is "self", when this property is encountered in
-the instance object, the object represents a resource and the instance object is
-treated as a full representation of the target resource identified by
-the specified URI.
-
-
-This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
-
-
-This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
-This relation indicates that the target of the link
-SHOULD be treated as the root or the body of the representation for the
-purposes of user agent interaction or fragment resolution. All other
-properties of the instance objects can be regarded as meta-data
-descriptions for the data.
-
-
-
-
-The following relations are applicable for schemas (the schema as the "from" resource in the relation):
-
-
-This indicates the target resource that represents collection of instances of a schema.
-
-
-This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
-
-
-
-
-For example, if a schema is defined:
-
-
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the
+ actual instance value SHOULD be used to replace the braces, rather than a property value.
+ This should only be used in situations where the instance is a scalar (string,
+ boolean, or number), and not for objects or arrays.
+
+
+
+
+
+ The value of the "rel" property indicates the name of the
+ relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+
+ If the relation value is "self", when this property is encountered in
+ the instance object, the object represents a resource and the instance object is
+ treated as a full representation of the target resource identified by
+ the specified URI.
+
+
+
+ This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
+
+
+
+ This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
+ This relation indicates that the target of the link
+ SHOULD be treated as the root or the body of the representation for the
+ purposes of user agent interaction or fragment resolution. All other
+ properties of the instance objects can be regarded as meta-data
+ descriptions for the data.
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+ This indicates the target resource that represents collection of instances of a schema.
+ This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+
+
+ For example, if a schema is defined:
+
+
-
-And if a collection of instance resource's JSON representation was
-retrieved:
-
-
+
+
+
+
+ And if a collection of instance resource's JSON representation was retrieved:
+
+
-
+[{
+ "id": "thing",
+ "upId": "parent"
+}, {
+ "id": "thing2",
+ "upId": "parent"
+}]
+]]>
+
+
-This would indicate that for the first item in the collection, its own
-(self) URI would resolve to "/Resource/thing" and the first item's "up"
-relation SHOULD be resolved to the resource at "/Resource/parent".
-The "children" collection would be located at "/Resource/?upId=thing".
-
-
-
-This property value is a schema that defines the expected
-structure of the JSON representation of the target of the link.
-
-
-
-The following properties also apply to link definition objects, and
-provide functionality analogous to HTML forms, in providing a
-means for submitting extra (often user supplied) information to send to a server.
-
-
-
-
-This attribute defines which method can be used to access the target resource.
-In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
-such as "PUT" and "DELETE" have semantics that are clearly implied by
-accessed resources, and do not need to be defined here).
-This defaults to "GET".
-
-
-
-
-
-If present, this property indicates a query media type format that the server
-supports for querying or posting to the collection of instances at the target
-resource. The query can be
-suffixed to the target URI to query the collection with
-property-based constraints on the resources that SHOULD be returned from
-the server or used to post data to the resource (depending on the method).
-For example, with the following schema:
-
-
+
+
+
+ This property value is a schema that defines the expected structure of the JSON representation of the target of the link.
+
+
+
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a
+ means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+ such as "PUT" and "DELETE" have semantics that are clearly implied by
+ accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
+
+
+
+
+ If present, this property indicates a query media type format that the server
+ supports for querying or posting to the collection of instances at the target
+ resource. The query can be
+ suffixed to the target URI to query the collection with
+ property-based constraints on the resources that SHOULD be returned from
+ the server or used to post data to the resource (depending on the method).
+
+
+ For example, with the following schema:
+
+
-
-This indicates that the client can query the server for instances that
-have a specific name:
-
-
+
+ This indicates that the client can query the server for instances that have a specific name.
+
+
+
+ For example:
+
+
-
+]]>
+
+
-If no enctype or method is specified, only the single URI specified by
-the href property is defined. If the method is POST, "application/json" is
-the default media type.
-
-
-
-
-This attribute contains a schema which defines the acceptable structure of the submitted
-request (for a GET request, this schema would define the properties for the query string
-and for a POST request, this would define the body).
-
-
-
-
-
-
-
- This property indicates the fragment resolution protocol to use for
-resolving fragment identifiers in URIs within the instance
-representations. This applies to the instance object URIs and all
-children of the instance object's URIs. The default fragment resolution
-protocol is "slash-delimited", which is defined below. Other fragment
-resolution protocols MAY be used, but are not defined in this
-document.
-
-
-
-The fragment identifier is based on RFC 2396, Sec 5, and defines the
-mechanism for resolving references to entities within a document.
-
-
-With the slash-delimited fragment resolution protocol, the fragment
-identifier is interpreted as a series of property reference tokens that start with and
-are delimited by the "/" character (\x2F). Each property reference token
-is a series of unreserved or escaped URI characters. Each property
-reference token SHOULD be interpreted, starting from the beginning of
-the fragment identifier, as a path reference in the target JSON
-structure. The final target value of the fragment can be determined by
-starting with the root of the JSON structure from the representation of
-the resource identified by the pre-fragment URI. If the target is a JSON
-object, then the new target is the value of the property with the name
-identified by the next property reference token in the fragment. If the
-target is a JSON array, then the target is determined by finding the
-item in array the array with the index defined by the next property
-reference token (which MUST be a number). The target is successively
-updated for each property reference token, until the entire fragment has
-been traversed.
-
-
-Property names SHOULD be URI-encoded. In particular, any "/" in a
-property name MUST be encoded to avoid being interpreted as a property
-delimiter.
-
-
-For example, for the following JSON representation:
-
-
+
+
+
+
+ This attribute contains a schema which defines the acceptable structure of the submitted
+ request (for a GET request, this schema would define the properties for the query string
+ and for a POST request, this would define the body).
+
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment resolution
+ protocol is "slash-delimited", which is defined below. Other fragment
+ resolution protocols MAY be used, but are not defined in this document.
+
+
+
+ The fragment identifier is based on RFC 2396, Sec 5, and defines the
+ mechanism for resolving references to entities within a document.
+
+
+
+
+ With the slash-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens that start with and
+ are delimited by the "/" character (\x2F). Each property reference token
+ is a series of unreserved or escaped URI characters. Each property
+ reference token SHOULD be interpreted, starting from the beginning of
+ the fragment identifier, as a path reference in the target JSON
+ structure. The final target value of the fragment can be determined by
+ starting with the root of the JSON structure from the representation of
+ the resource identified by the pre-fragment URI. If the target is a JSON
+ object, then the new target is the value of the property with the name
+ identified by the next property reference token in the fragment. If the
+ target is a JSON array, then the target is determined by finding the
+ item in array the array with the index defined by the next property
+ reference token (which MUST be a number). The target is successively
+ updated for each property reference token, until the entire fragment has
+ been traversed.
+
+
+
+ Property names SHOULD be URI-encoded. In particular, any "/" in a
+ property name MUST be encoded to avoid being interpreted as a property
+ delimiter.
+
+
+
+
+ For example, for the following JSON representation:
+
+
-
-The following fragment identifiers would be resolved:
-
-
+
+
+
+
+ The following fragment identifiers would be resolved:
+
+
-
-
-
-
-The dot-delimited fragment resolution protocol is the same as
-slash-delimited fragment resolution protocol except that the "." character
-(\x2E) is used as the delimiter between property names (instead of "/") and
-the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
-identifiers for referencing the value of the foo propery.
-
-
-
-
-
-
-This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
-
-
-If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
-
-
-
-
-
-This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
-The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
-and is relative to the instance's URI.
-
-
-When multiple schemas have been referenced for an instance, the user agent
-can determine if this schema is applicable for a particular instance by
-determining if the URI of the instance begins with the the value of the "pathStart"
-attribute. If the URI of the instance does not start with this URI,
-or if another schema specifies a starting URI that is longer and also matches the
-instance, this schema SHOULD NOT be applied to the instance. Any schema
-that does not have a pathStart attribute SHOULD be considered applicable
-to all the instances for which it is referenced.
-
-
-
-
-This attribute defines the media type of the instance representations that this schema is defining.
-
-
-
-
-
-
-
-
-
-This specification is a sub-type of the JSON format, and
-consequently the security considerations are generally the same as RFC 4627.
-However, an additional issue is that when link relation of "self"
-is used to denote a full representation of an object, the user agent
-SHOULD NOT consider the representation to be the authoritative representation
-of the resource denoted by the target URI if the target URI is not
-equivalent to or a sub-path of the the URI used to request the resource
-representation which contains the target URI with the "self" link.
-For example, if a hyper schema was defined:
-
-
+
+
+
+
+
+
+
+ The dot-delimited fragment resolution protocol is the same as
+ slash-delimited fragment resolution protocol except that the "." character
+ (\x2E) is used as the delimiter between property names (instead of "/") and
+ the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
+ identifiers for referencing the value of the foo propery.
+
+
+
+
+
+ This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+
+ If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
+
+
+
+
+ This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+ The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
+ and is relative to the instance's URI.
+
+
+
+ When multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance by
+ determining if the URI of the instance begins with the the value of the "pathStart"
+ attribute. If the URI of the instance does not start with this URI,
+ or if another schema specifies a starting URI that is longer and also matches the
+ instance, this schema SHOULD NOT be applied to the instance. Any schema
+ that does not have a pathStart attribute SHOULD be considered applicable
+ to all the instances for which it is referenced.
+
+
+
+
+ This attribute defines the media type of the instance representations that this schema is defining.
+
+
+
+
+
+ This specification is a sub-type of the JSON format, and
+ consequently the security considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self"
+ is used to denote a full representation of an object, the user agent
+ SHOULD NOT consider the representation to be the authoritative representation
+ of the resource denoted by the target URI if the target URI is not
+ equivalent to or a sub-path of the the URI used to request the resource
+ representation which contains the target URI with the "self" link.
+
+
+ For example, if a hyper schema was defined:
+
+
-
-And a resource was requested from somesite.com:
-
-
+
+
+
+
+ And a resource was requested from somesite.com:
+
+
-
+]]>
+
+
-With a response of:
-
-
+ With a response of:
+
+
-
-
-
-
-
- The proposed MIME media type for JSON Schema is "application/schema+json".
-
-
- Type name: application
-
-
- Subtype name: schema+json
-
-
- Required parameters: profile
-
-
- The value of the profile parameter SHOULD be a URI (relative or absolute) that
- refers to the schema used to define the structure of this structure (the
- meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
- but it is allowable to use other schemas that extend the hyper schema's meta-
- schema.
-
-
- Optional parameters: pretty
-
-
- The value of the pretty parameter MAY be true or false to indicate if additional
- whitespace has been included to make the JSON representation easier to read.
-
-
-
-
-This registry is maintained by IANA per RFC 4287 and this specification adds
-four values: "full", "create", "instances", "root". New
- assignments are subject to IESG Approval, as outlined in RFC 5226.
- Requests should be made by email to IANA, which will then forward the
- request to the IESG, requesting approval.
-
-
-
-
-
-
-
-
-
-
-
- &rfc2045;
- &rfc2119;
- &rfc2396;
- &rfc3339;
- &rfc3986;
- &rfc4287;
-
-
-
- &rfc2616;
- &rfc4627;
- &rfc5226;
- &iddiscovery;
- &uritemplate;
- &linkheader;
- &html401;
- &css21;
-
-
-
-
-
-
-
-
-
- Added example and verbiage to "extends" attribute.
- Defined slash-delimited to use a leading slash.
- Made "root" a relation instead of an attribute.
- Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
- Added more explanation of nullability.
- Removed "alternate" attribute.
- Upper cased many normative usages of must, may, and should.
- Replaced the link submission "properties" attribute to "schema" attribute.
- Replaced "optional" attribute with "required" attribute.
- Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
- Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
- Replaced "requires" attribute with "dependencies" attribute.
- Moved "contentEncoding" attribute to hyper schema.
- Added "additionalItems" attribute.
- Added "id" attribute.
- Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
- Added "patternProperties" attribute.
- Schema URIs are now namespace versioned.
- Added "$ref" and "$schema" attributes.
-
-
-
-
- Replaced "maxDecimal" attribute with "divisibleBy" attribute.
- Added slash-delimited fragment resolution protocol and made it the default.
- Added language about using links outside of schemas by referencing its normative URI.
- Added "uniqueItems" attribute.
- Added "targetSchema" attribute to link description object.
-
-
-
-
-
- Fixed category and updates from template.
-
-
-
-
- Initial draft.
-
-
-
-
-
+[{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+}, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+}, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+}]
+]]>
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is "application/schema+json".
+ Type name: application
+ Subtype name: schema+json
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+ Optional parameters: pretty
+ The value of the pretty parameter MAY be true or false to indicate if additional whitespace has been included to make the JSON representation easier to read.
+
+
+
+ This registry is maintained by IANA per RFC 4287 and this specification adds
+ four values: "full", "create", "instances", "root". New
+ assignments are subject to IESG Approval, as outlined in RFC 5226.
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc2396;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
-
-
-
- Should we give a preference to MIME headers over Link headers (or only use one)?
- Should "root" be a MIME parameter?
- Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
- How should dates be handled?
-
-
-
-
-
+
+
+
+
+
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema" attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
+ Replaced "requires" attribute with "dependencies" attribute.
+ Moved "contentEncoding" attribute to hyper schema.
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
+ Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
+
+
+
+
+
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+ Added slash-delimited fragment resolution protocol and made it the default.
+ Added language about using links outside of schemas by referencing its normative URI.
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
+
+
+
+
+
+ Fixed category and updates from template.
+
+
+
+
+
+ Initial draft.
+
+
+
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should "root" be a MIME parameter?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
+ How should dates be handled?
+
+
+
+
From 6c1d7ffbc183b1690906f17ea6f14559953409e2 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Mon, 25 Jul 2011 09:14:07 -0600
Subject: [PATCH 0049/1659] Added description
---
package.json | 1 +
1 file changed, 1 insertion(+)
diff --git a/package.json b/package.json
index dbdb363a..51db2e9a 100644
--- a/package.json
+++ b/package.json
@@ -2,6 +2,7 @@
"name": "json-schema",
"version": "0.2.0",
"author": "Kris Zyp",
+ "description": "JSON Schema validation and specifications",
"maintainers":[
{"name": "Kris Zyp", "email": "kriszyp@gmail.com"}],
"keywords": [
From 1dd6acbdeda7304b9fd66ce393c940d95ac169a8 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Wed, 28 Sep 2011 13:08:04 -0600
Subject: [PATCH 0050/1659] Clean out modifications to primitives
---
lib/validate.js | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 24662a07..97cbbf6f 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -17,13 +17,15 @@ empty list will be returned. A validation error will have two properties:
define([], function(){
var exports = validate;
// setup primitive classes to be JSON Schema types
-String.type = "string";
-Boolean.type = "boolean";
-Number.type = "number";
exports.Integer = {type:"integer"};
-Object.type = "object";
-Array.type = "array";
-Date.type = "date";
+var primitiveConstructors = {
+ String: String,
+ Boolean: Boolean,
+ Number: Number,
+ Object: Object,
+ Array: Array,
+ Date: Date
+}
exports.validate = validate;
function validate(/*Any*/instance,/*Object*/schema) {
// Summary:
@@ -55,6 +57,9 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if (!options) options = {};
var _changing = options.changing;
+ function getType(schema){
+ return schema.type || (primitiveConstructors[schema.name] == schema && schema.name.toLowerCase());
+ }
var errors = [];
// validate a value against a property definition
function checkProp(value, schema, path,i){
@@ -65,7 +70,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
errors.push({property:path,message:message});
}
- if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && schema.type)){
+ if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && getType(schema))){
if(typeof schema == 'function'){
if(!(value instanceof schema)){
addError("is not an instance of the class/constructor " + schema.name);
@@ -117,7 +122,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
addError("is missing and it is required");
}
}else{
- errors = errors.concat(checkType(schema.type,value));
+ errors = errors.concat(checkType(getType(schema),value));
if(schema.disallow && !checkType(schema.disallow,value).length){
addError(" disallowed value was matched");
}
From e22117ff3b02150b412884cea384c91fbb1365c7 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Tue, 15 Nov 2011 18:33:38 -0700
Subject: [PATCH 0051/1659] Created initial draft-04 schemas. Added JSON
Pointer to spec.
---
changes.md | 5 +
draft-04/hyper-schema | 60 ++++++++++++
draft-04/links | 41 ++++++++
draft-04/schema | 179 +++++++++++++++++++++++++++++++++++
draft-zyp-json-schema-04.xml | 94 ++++--------------
5 files changed, 301 insertions(+), 78 deletions(-)
create mode 100644 changes.md
create mode 100644 draft-04/hyper-schema
create mode 100644 draft-04/links
create mode 100644 draft-04/schema
diff --git a/changes.md b/changes.md
new file mode 100644
index 00000000..b21dab9f
--- /dev/null
+++ b/changes.md
@@ -0,0 +1,5 @@
+* "required" is now an array, for object instances
+* "format" deprecated
+* "slash-delimited" replaced with "json-pointer"
+* new "minProperties" and "maxProperties"
+* new "template" on LDO
\ No newline at end of file
diff --git a/draft-04/hyper-schema b/draft-04/hyper-schema
new file mode 100644
index 00000000..f96d1ac6
--- /dev/null
+++ b/draft-04/hyper-schema
@@ -0,0 +1,60 @@
+{
+ "$schema" : "http://json-schema.org/draft-04/hyper-schema#",
+ "extends" : {"$ref" : "http://json-schema.org/draft-04/schema#"},
+ "id" : "http://json-schema.org/draft-04/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/draft-04/links#"}
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "default" : "json-pointer"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "contentEncoding" : {
+ "type" : "string"
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "format" : "media-type"
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ },
+
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ }
+ ],
+
+ "fragmentResolution" : "json-pointer"
+}
diff --git a/draft-04/links b/draft-04/links
new file mode 100644
index 00000000..de272cc4
--- /dev/null
+++ b/draft-04/links
@@ -0,0 +1,41 @@
+{
+ "$schema" : "http://json-schema.org/draft-04/hyper-schema#",
+ "id" : "http://json-schema.org/draft-04/links#",
+ "type" : "object",
+
+ "properties" : {
+ "rel" : {
+ "type" : "string"
+ },
+
+ "href" : {
+ "type" : "string"
+ },
+
+ "template" : {
+ "type" : "string"
+ },
+
+ "targetSchema" : {"$ref" : "http://json-schema.org/draft-04/hyper-schema#"},
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET"
+ },
+
+ "enctype" : {
+ "type" : "string"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/draft-04/hyper-schema#"}
+ }
+ },
+
+ "required" : ["rel", "href"],
+
+ "dependencies" : {
+ "enctype" : "method"
+ }
+}
\ No newline at end of file
diff --git a/draft-04/schema b/draft-04/schema
new file mode 100644
index 00000000..449e68d7
--- /dev/null
+++ b/draft-04/schema
@@ -0,0 +1,179 @@
+{
+ "$schema" : "http://json-schema.org/draft-04/schema#",
+ "id" : "http://json-schema.org/draft-04/schema#",
+ "type" : "object",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "disallow" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "uniqueItems" : true
+ },
+
+ "extends" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "default" : {}
+ },
+
+ "enum" : {
+ "type" : "array",
+ "minItems" : 1,
+ "uniqueItems" : true
+ },
+
+ "minimum" : {
+ "type" : "number"
+ },
+
+ "maximum" : {
+ "type" : "number"
+ },
+
+ "exclusiveMinimum" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "exclusiveMaximum" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "divisibleBy" : {
+ "type" : "number",
+ "minimum" : 0,
+ "exclusiveMinimum" : true,
+ "default" : 1
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer"
+ },
+
+ "pattern" : {
+ "type" : "string"
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "default" : {}
+ },
+
+ "additionalItems" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "default" : {}
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer",
+ "minimum" : 0
+ },
+
+ "uniqueItems" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "default" : {}
+ },
+
+ "patternProperties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "default" : {}
+ },
+
+ "additionalProperties" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "default" : {}
+ },
+
+ "minProperties" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxProperties" : {
+ "type" : "integer",
+ "minimum" : 0
+ },
+
+ "required" : {
+ "type" : "array",
+ "items" : {
+ "type" : "string"
+ }
+ },
+
+ "dependencies" : {
+ "type" : "object",
+ "additionalProperties" : {
+ "type" : ["string", "array", {"$ref" : "#"}],
+ "items" : {
+ "type" : "string"
+ }
+ },
+ "default" : {}
+ },
+
+ "id" : {
+ "type" : "string"
+ },
+
+ "$ref" : {
+ "type" : "string"
+ },
+
+ "$schema" : {
+ "type" : "string"
+ },
+
+ "title" : {
+ "type" : "string"
+ },
+
+ "description" : {
+ "type" : "string"
+ },
+
+ "default" : {
+ "type" : "any"
+ }
+ },
+
+ "dependencies" : {
+ "exclusiveMinimum" : "minimum",
+ "exclusiveMaximum" : "maximum"
+ },
+
+ "default" : {}
+}
\ No newline at end of file
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 3703f992..eacd96f8 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -8,7 +8,6 @@
-
@@ -825,89 +824,17 @@ GET /Resource/
resolving fragment identifiers in URIs within the instance
representations. This applies to the instance object URIs and all
children of the instance object's URIs. The default fragment resolution
- protocol is "slash-delimited", which is defined below. Other fragment
+ protocol is "json-pointer", which is defined below. Other fragment
resolution protocols MAY be used, but are not defined in this document.
- The fragment identifier is based on RFC 2396, Sec 5, and defines the
+ The fragment identifier is based on RFC 3986, Sec 5, and defines the
mechanism for resolving references to entities within a document.
-
-
- With the slash-delimited fragment resolution protocol, the fragment
- identifier is interpreted as a series of property reference tokens that start with and
- are delimited by the "/" character (\x2F). Each property reference token
- is a series of unreserved or escaped URI characters. Each property
- reference token SHOULD be interpreted, starting from the beginning of
- the fragment identifier, as a path reference in the target JSON
- structure. The final target value of the fragment can be determined by
- starting with the root of the JSON structure from the representation of
- the resource identified by the pre-fragment URI. If the target is a JSON
- object, then the new target is the value of the property with the name
- identified by the next property reference token in the fragment. If the
- target is a JSON array, then the target is determined by finding the
- item in array the array with the index defined by the next property
- reference token (which MUST be a number). The target is successively
- updated for each property reference token, until the entire fragment has
- been traversed.
-
-
-
- Property names SHOULD be URI-encoded. In particular, any "/" in a
- property name MUST be encoded to avoid being interpreted as a property
- delimiter.
-
-
-
-
- For example, for the following JSON representation:
-
-
-
-
-
-
- The following fragment identifiers would be resolved:
-
-
-
-
-
-
-
-
-
- The dot-delimited fragment resolution protocol is the same as
- slash-delimited fragment resolution protocol except that the "." character
- (\x2E) is used as the delimiter between property names (instead of "/") and
- the path does not need to start with a ".". For example, #.foo and #foo are a valid fragment
- identifiers for referencing the value of the foo propery.
-
+
+ The "json-pointer" fragment resolution protocol uses a JSON Pointer to resolve fragment identifiers in URIs within instance representations.
@@ -1037,10 +964,21 @@ Content-Type: application/json; profile=/schema-for-this-data
&rfc2045;
&rfc2119;
- &rfc2396;
&rfc3339;
&rfc3986;
&rfc4287;
+
+
+ JSON Pointer
+
+ ForgeRock US, Inc.
+
+
+ SitePen (USA)
+
+
+
+
&rfc2616;
From baa948a31dddf6642d299c9d4722319a49bccbb1 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Tue, 29 Nov 2011 12:25:33 -0700
Subject: [PATCH 0052/1659] Made core changes to draft: * Changed "required"
attribute to an array of strings. * Removed "format" attribute. * Added
"minProperties" and "maxProperties" attributes. * Replaced "slash-delimited"
fragment resolution with "json-pointer". * Added "template" LDO attribute.
Removed irrelevant "Open Issues" section.
---
changes.md | 5 ---
draft-zyp-json-schema-04.xml | 64 ++++++++++++++----------------------
2 files changed, 25 insertions(+), 44 deletions(-)
delete mode 100644 changes.md
diff --git a/changes.md b/changes.md
deleted file mode 100644
index b21dab9f..00000000
--- a/changes.md
+++ /dev/null
@@ -1,5 +0,0 @@
-* "required" is now an array, for object instances
-* "format" deprecated
-* "slash-delimited" replaced with "json-pointer"
-* new "minProperties" and "maxProperties"
-* new "template" on LDO
\ No newline at end of file
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index eacd96f8..80ea8b2f 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -377,7 +377,7 @@ Content-Type: application/json;
- This attribute indicates if the instance must have a value, and not be undefined. This is false by default, making the instance optional.
+ This attribute is an array of strings that defines all the property names that must exist on the object instance.
@@ -421,6 +421,14 @@ Content-Type: application/json;
This attribute defines the maximum number of values in an array when the array is the instance value.
+
+ This attribute defines the minimum number of properties required on an object instance.
+
+
+
+ This attribute defines the maximum number of properties the object instance can have.
+
+
This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
@@ -463,32 +471,6 @@ Content-Type: application/json;
This attribute is a string that provides a full description of the of purpose the instance property.
-
- This property defines the type of data, content type, or microformat to be expected in the instance property values. A format attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MAY (but are not required to) validate that the instance values conform to a format.
-
-
- The following formats are predefined:
-
-
- This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
- This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
- This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
- This SHOULD be the difference, measured in milliseconds, between the specified time and midnight, 00:00 of January 1, 1970 UTC. The value SHOULD be a number (integer or float).
- A regular expression, following the regular expression specification from ECMA 262/Perl 5.
- This is a CSS color (like "#FF0000" or "red"), based on CSS 2.1.
- This is a CSS style definition (like "color: red; background-color:#FFF"), based on CSS 2.1.
- This SHOULD be a phone number (format MAY follow E.123).
- This value SHOULD be a URI.
- This SHOULD be an email address.
- This SHOULD be an ip version 4 address.
- This SHOULD be an ip version 6 address.
- This SHOULD be a host-name.
-
-
-
- Additional custom formats MAY be created. These custom formats MAY be expressed as an URI, and this URI MAY reference a schema of that format.
-
-
This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
@@ -606,7 +588,7 @@ Content-Type: application/json;
http://json-schema.org/draft-03/links (draft-03 version).
-
+
The value of the "href" link description property
indicates the target URI of the related resource. The value
@@ -741,6 +723,10 @@ GET /Resource/
+
+ This property value is a string that defines the templating language used in the "href" attribute. If no templating language is defined, then the default Link Description Object templating langauge is used.
+
+
This property value is a schema that defines the expected structure of the JSON representation of the target of the link.
@@ -994,6 +980,17 @@ Content-Type: application/json; profile=/schema-for-this-data
+
+
+ Changed "required" attribute to an array of strings.
+ Removed "format" attribute.
+ Added "minProperties" and "maxProperties" attributes.
+ Replaced "slash-delimited" fragment resolution with "json-pointer".
+ Added "template" LDO attribute.
+ Removed irrelevant "Open Issues" section.
+
+
+
Added example and verbiage to "extends" attribute.
@@ -1042,16 +1039,5 @@ Content-Type: application/json; profile=/schema-for-this-data
-
-
-
-
- Should we give a preference to MIME headers over Link headers (or only use one)?
- Should "root" be a MIME parameter?
- Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed?
- How should dates be handled?
-
-
-
From cf45c27f895ba7f8bc95eb7dd96cbd51dc9824a0 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Tue, 29 Nov 2011 18:23:01 -0700
Subject: [PATCH 0053/1659] Core changes: * Removed "integer" type in favor of
{"type":"number", "divisibleBy":1}. * Restricted "type" to only the core JSON
types.
Content changes:
* Improved wording of several sections.
* Merged Conventions and Terminology sections.
* Defined terms used in specification.
---
draft-04/schema | 14 +-
draft-zyp-json-schema-04.xml | 271 +++++++++++++++++++----------------
2 files changed, 162 insertions(+), 123 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 449e68d7..598951e5 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -5,9 +5,19 @@
"properties" : {
"type" : {
- "type" : ["string", "array"],
+ "type" : [
+ {
+ "id" : "#simple-type",
+ "type" : "string",
+ "enum" : ["object", "array", "string", "number", "boolean", "null", "any"]
+ },
+ "array"
+ ],
"items" : {
- "type" : ["string", {"$ref" : "#"}]
+ "type" : [
+ {"$ref" : "#simple-type"},
+ {"$ref" : "#"}
+ ]
},
"uniqueItems" : true,
"default" : "any"
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 80ea8b2f..2b79fccc 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -61,8 +61,7 @@
JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
- a JSON based format for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
+ a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON
data is required for a given application and how to interact with it. JSON
Schema is intended to define validation, documentation, hyperlink
navigation, and interaction control of JSON data.
@@ -81,7 +80,7 @@
-
+
@@ -90,34 +89,49 @@
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
+
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
+ "array", "number", "string", "boolean", "true", "false", and "null" in this
+ document are to be interpreted as defined in RFC 4627.
+
+
+
+ This specification also uses the following defined terms:
+
+
+ A JSON Schema object.
+ Equivalent to "JSON value" as defined in RFC 4627.
+ Equivalent to "member" as defined in RFC 4627.
+ Equivalent to "element" as defined in RFC 4627.
+ A property of a JSON Schema object.
+
+
-
-
JSON Schema defines the media type "application/schema+json" for
- describing the structure of other
- JSON documents. JSON Schema is JSON-based and includes facilities
- for describing the structure of JSON documents in terms of
+ describing the structure of JSON text. JSON Schemas are also written in JSON and includes facilities
+ for describing the structure of JSON in terms of
allowable values, descriptions, and interpreting relations with other resources.
- JSON Schema format is organized into several separate definitions. The first
+ This document is organized into several separate definitions. The first
definition is the core schema specification. This definition is primary
concerned with describing a JSON structure and specifying valid elements
in the structure. The second definition is the Hyper Schema specification
- which is intended define elements in a structure that can be interpreted as
+ which is intended to define elements in a structure that can be interpreted as
hyperlinks.
Hyper Schema builds on JSON Schema to describe the hyperlink structure of
- other JSON documents and elements of interaction. This allows user agents to be able to successfully navigate
- JSON documents based on their schemas.
+ JSON values. This allows user agents to be able to successfully navigate
+ documents containing JSON based on their schemas.
- Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
- property values, as well as define the meaning of the property values
- for the purpose of describing a resource and determining hyperlinks
- within the representation.
+ Cumulatively JSON Schema acts as meta-JSON that can be used to define the
+ required type and constraints on JSON values, as well as define the meaning
+ of the JSON values for the purpose of describing a resource and determining
+ hyperlinks within the representation.
An example JSON Schema that describes products might look like:
@@ -127,19 +141,16 @@
"title": "Product",
"properties": {
"id": {
- "type": "number",
- "description": "Product identifier",
- "required": true
+ "title": "Product Identifier",
+ "type": "number"
},
"name": {
- "description": "Name of the product",
- "type": "string",
- "required": true
+ "title": "Product Name",
+ "type": "string"
},
"price": {
"type": "number",
- "minimum": 0,
- "required": true
+ "minimum": 0
},
"tags": {
"type": "array",
@@ -148,6 +159,7 @@
}
}
},
+ "required" : ["id", "name", "price"],
"links": [{
"rel": "full",
"href": "{id}"
@@ -159,29 +171,20 @@
]]>
- This schema defines the properties of the instance JSON documents,
+ This schema defines the properties of the instance,
the required properties (id, name, and price), as well as an optional
- property (tags). This also defines the link relations of the instance
- JSON documents.
+ property (tags). This also defines the link relations of the instance.
-
-
- For this specification, schema will be used to denote a JSON Schema
- definition, and an instance refers to a JSON value that the schema
- will be describing and validating.
-
-
-
The JSON Schema media type does not attempt to dictate the structure of JSON
- representations that contain data, but rather provides a separate format
- for flexibly communicating how a JSON representation should be
+ values that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON value should be
interpreted and validated, such that user agents can properly understand
acceptable structures and extrapolate hyperlink information
- with the JSON document. It is acknowledged that JSON documents come
+ from the JSON. It is acknowledged that JSON values come
in a variety of structures, and JSON is unique in that the structure
of stored data structures often prescribes a non-ambiguous definite
JSON representation. Attempting to force a specific structure is generally
@@ -204,26 +207,25 @@
- JSON Schema instances are correlated to their schema by the "describedby"
- relation, where the schema is defined to be the target of the relation.
- Instance representations may be of the "application/json" media type or
- any other subtype. Consequently, dictating how an instance
- representation should specify the relation to the schema is beyond the normative scope
- of this document (since this document specifically defines the JSON
- Schema media type, and no other), but it is recommended that instances
+ JSON values are correlated to their schema by the "describedby"
+ relation, where the schema is the target of the relation.
+ JSON values MUST be of the "application/json" media type or
+ any other subtype. Consequently, dictating how a JSON value should
+ specify the relation to the schema is beyond the normative scope
+ of this document since this document specifically defines the JSON
+ Schema media type, and no other. It is RECOMMNENDED that JSON values
specify their schema so that user agents can interpret the instance
- representation and messages may retain the self-descriptive
- characteristic, avoiding the need for out-of-band information about
+ and retain the self-descriptive characteristics. This avoides the need for out-of-band information about
instance data. Two approaches are recommended for declaring the
relation to the schema that describes the meaning of a JSON instance's (or collection
of instances) structure. A MIME type parameter named
- "profile" or a relation of "describedby" (which could be defined by a Link header) may be used:
+ "profile" or a relation of "describedby" (which could be specified by a Link header) may be used:
@@ -234,7 +236,7 @@ Content-Type: application/my-media-type+json;
; rel="describedby"
+Link: ; rel="describedby"
]]>
@@ -242,14 +244,11 @@ Link: ; rel="describedby"
Instances MAY specify multiple schemas, to indicate all the schemas that
are applicable to the data, and the data SHOULD be valid by all the schemas.
The instance data MAY have multiple schemas
- that it is defined by (the instance data SHOULD be valid for those schemas).
+ that it is described by (the instance data SHOULD be valid for those schemas).
Or if the document is a collection of instances, the collection MAY contain
- instances from different schemas. When collections contain heterogeneous
- instances, the "pathStart" attribute MAY be specified in the
- schema to disambiguate which schema should be applied for each item in the
- collection. However, ultimately, the mechanism for referencing a schema is up to the
- media type of the instance documents (if they choose to specify that schemas
- can be referenced).
+ instances from different schemas. The mechanism for referencing a schema is
+ determined by the media type of the instance (if it provides a method for
+ referencing schemas).
@@ -257,18 +256,17 @@ Link: ; rel="describedby"
JSON Schemas can themselves be described using JSON Schemas.
A self-describing JSON Schema for the core JSON Schema can
be found at http://json-schema.org/schema for the latest version or
- http://json-schema.org/draft-03/schema for the draft-03 version. The hyper schema
+ http://json-schema.org/draft-04/schema for the draft-04 version. The hyper schema
self-description can be found at http://json-schema.org/hyper-schema
- or http://json-schema.org/draft-03/hyper-schema. All schemas
- used within a protocol with media type definitions
- SHOULD include a MIME parameter that refers to the self-descriptive
+ or http://json-schema.org/draft-04/hyper-schema. All schemas
+ used within a protocol with a media type specified SHOULD include a MIME parameter that refers to the self-descriptive
hyper schema or another schema that extends this hyper schema:
@@ -278,14 +276,14 @@ Content-Type: application/json;
- A JSON Schema is a JSON Object that defines various attributes
+ A JSON Schema is a JSON object that defines various attributes
(including usage and valid values) of a JSON value. JSON
Schema has recursive capabilities; there are a number of elements
in the structure that allow for nested JSON Schemas.
- An example JSON Schema definition could look like:
+ An example JSON Schema could look like:
- A JSON Schema object may have any of the following properties, called schema
- attributes (all attributes are optional):
+ A JSON Schema object MAY have any of the following optional properties:
-
+
+
+
+
This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
This attribute can take one of two forms:
- A string indicating a primitive or simple type. The following are acceptable string values:
+ A string indicating a primitive or simple type. The string MUST be one of the following values:
- Value MUST be a string.
- Value MUST be a number, floating point numbers are allowed.
- Value MUST be an integer, no floating point numbers are allowed. This is a subset of the number type.
- Value MUST be a boolean.
- Value MUST be an object.
- Value MUST be an array.
- Value MUST be null. Note this is mainly for purpose of being able use union types to define nullability. If this type is not included in a union, null values are not allowed (the primitives listed above do not allow nulls on their own).
- Value MAY be of any type including null.
+ Instance MUST be an object.
+ Instance MUST be an array.
+ Instance MUST be a string.
+ Instance MUST be a number, including floating point numbers.
+ Instance MUST be the JSON literal "true" or "false".
+ Instance MUST be the JSON literal "null". Note that without this type, null values are not allowed.
+ Instance MAY be of any type, including null.
-
- If the property is not defined or is not in this list, then any type of value is acceptable.
- Other type values MAY be used for custom purposes, but minimal validators of the specification
- implementation can allow any instance value on unknown type values.
- An array of two or more simple type definitions. Each item in the array MUST be a simple type definition or a schema.
- The instance value is valid if it is of the same type as one of the simple type definitions, or valid by one of the schemas, in the array.
+ An array of one or more simple or schema types.
+ The instance value is valid if it is of the same type as one of the simple types, or valid by one of the schemas, in the array.
+
+ If this attribute is not specified, then all value types are accepted.
@@ -355,33 +354,54 @@ Content-Type: application/json;
- This attribute is an object with property definitions that define the valid values of instance object property values. When the instance value is an object, the property values of the instance object MUST conform to the property definitions in this object. In this object, each property definition's value MUST be a schema, and the property's name MUST be the name of the instance property that it defines. The instance property value MUST be valid according to the schema from the property definition. Properties are considered unordered, the order of the instance properties MAY be in any order.
+
+ This attribute is an object with properties that specify the schemas for the properties of the instance object.
+ In this attribute's object, each property value MUST be a schema.
+ When the instance value is an object, the value of the instance's properties MUST be valid according to the schemas with the same property names specified in this attribute.
+ Objects are unordered, so therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
+
-
- This attribute is an object that defines the schema for a set of property names of an object instance. The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema. If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+
+
+ This attribute is an object that defines the schema for a set of property names of an object instance.
+ The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema.
+ If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
+
- This attribute defines a schema for all properties that are not explicitly defined in an object type definition. If specified, the value MUST be a schema or a boolean. If false is provided, no additional properties are allowed beyond the properties defined in the schema. The default value is an empty schema which allows any value for additional properties.
+ This attribute specifies how any instance property that is not explicitly defined by either the "properties" or "patternProperties" attributes (hereafter referred to as "additional properties") is handled. If specified, the value MUST be a schema or a boolean.
+ If a schema is provided, then all additional properties MUST be valid according to the schema.
+ If false is provided, then no additional properties are allowed.
+ The default value is an empty schema, which allows any value for additional properties.
-
- This attribute defines the allowed items in an instance array, and MUST be a schema or an array of schemas. The default value is an empty schema which allows any value for items in the instance array.
+
+ This attribute provides the allowed items in an array instance. If specified, this attribute MUST be a schema or an array of schemas.When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
- When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute using the same rules as "additionalProperties" for objects.
+ When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST be valid according to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute the same way as "additionalProperties" for objects is.
- This provides a definition for additional items in an array instance when tuple definitions of the items is provided. This can be false to indicate additional items in the array are not allowed, or it can be a schema that defines the schema of the additional items.
+ This attribute specifies how any item in the array instance that is not explicitly defined by "items" (hereafter referred to as "additional items") is handled. If specified, the value MUST be a schema or a boolean.
+ If a schema is provided:
+
+ If the "items" attribute is unspecified, then all items in the array instance must be valid against this schema.
+ If the "items" attribute is a schema, then this attribute is ignored.
+ If the "items" attribute is an array (during tuple typing), then any additional items MUST be valid against this schema.
+
+
+ If false is provided, then any additional items in the array are not allowed.
+ The default value is an empty schema, which allows any value for additional items.
-
+ This attribute is an array of strings that defines all the property names that must exist on the object instance.
-
- This attribute is an object that defines the requirements of a property on an instance object. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
+
+ This attribute is an object that specifies the requirements of a property on an object instance. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
The dependency value can take one of two forms:
@@ -397,35 +417,35 @@ Content-Type: application/json;
-
+ This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-
+ This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-
+ This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-
+ This attribute defines the minimum number of values in an array when the array is the instance value.
-
+ This attribute defines the maximum number of values in an array when the array is the instance value.
-
+ This attribute defines the minimum number of properties required on an object instance.
-
+ This attribute defines the maximum number of properties the object instance can have.
@@ -443,43 +463,43 @@ Content-Type: application/json;
-
+ When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
+ When the instance value is a string, this defines the minimum length of the string.
-
+ When the instance value is a string, this defines the maximum length of the string.
-
+ This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
-
+ This attribute defines the default value of the instance when the instance is undefined.
-
+ This attribute is a string that provides a short description of the instance property.
-
+ This attribute is a string that provides a full description of the of purpose the instance property.
-
+ This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
-
+ This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-
+ The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
Conceptually, the behavior of extends can be seen as validating an
@@ -513,7 +533,7 @@ Content-Type: application/json;
"type": "boolean"
}
},
- "extends": {"$ref": "http://json-schema.org/draft-03/schema"}
+ "extends": {"$ref": "http://json-schema.org/draft-04/schema"}
}
]]>
@@ -521,7 +541,7 @@ Content-Type: application/json;
-
+
This attribute defines the current URI of this schema (this attribute is
effectively a "self" link). This URI MAY be relative or absolute. If
@@ -534,7 +554,7 @@ Content-Type: application/json;
-
+
This attribute defines a URI of a schema that contains the full representation of this schema.
When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
@@ -542,7 +562,7 @@ Content-Type: application/json;
-
+
This attribute defines a URI of a JSON Schema that is the schema of the current schema.
When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
@@ -574,18 +594,20 @@ Content-Type: application/json;
relations of the instances.
+
+
A link description object is used to describe link relations. In
the context of a schema, it defines the link relations of the
instances of the schema, and can be parameterized by the instance
- values. The link description format can be used on its own in
- regular (non-schema documents), and use of this format can
+ values. The link description format can be used without JSON Schema,
+ and use of this format can
be declared by referencing the normative link description
schema as the the schema for the data structure that uses the
links. The URI of the normative link description schema is:
http://json-schema.org/links (latest version) or
- http://json-schema.org/draft-03/links (draft-03 version).
+ http://json-schema.org/draft-04/links (draft-04 version).
@@ -824,8 +846,10 @@ GET /Resource/
+
+
- This attribute indicates that the instance property SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+ This attribute indicates that the instance value SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
@@ -926,7 +950,7 @@ Content-Type: application/json; profile=/schema-for-this-data
The value of the profile parameter SHOULD be a URI (relative or absolute) that
refers to the schema used to define the structure of this structure (the
- meta-schema). Normally the value would be http://json-schema.org/draft-03/hyper-schema,
+ meta-schema). Normally the value would be http://json-schema.org/draft-04/hyper-schema,
but it is allowable to use other schemas that extend the hyper schema's meta-
schema.
@@ -988,6 +1012,11 @@ Content-Type: application/json; profile=/schema-for-this-data
Replaced "slash-delimited" fragment resolution with "json-pointer".Added "template" LDO attribute.Removed irrelevant "Open Issues" section.
+ Merged Conventions and Terminology sections.
+ Defined terms used in specification.
+ Removed "integer" type in favor of {"type":"number", "divisibleBy":1}.
+ Restricted "type" to only the core JSON types.
+ Improved wording of many sections.
From 9e4df0944fe0ad6ed3b9e108301d94e306e12a08 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 29 Nov 2011 21:20:32 -0700
Subject: [PATCH 0054/1659] Better wording of items and their array indices
---
draft-zyp-json-schema-04.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 3703f992..a3d485c2 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -430,7 +430,7 @@ Content-Type: application/json;
are null; orare booleans/numbers/strings and have the same value; or
- are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+ are arrays, contains the same number of items, and each item in the array is equal to the item at the corresponding index in the other array; orare objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
From 766aca5e06beb76ba3df90dad9ae66bc61666437 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 29 Nov 2011 21:20:38 -0700
Subject: [PATCH 0055/1659] bump version
---
package.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package.json b/package.json
index 51db2e9a..0ff652a7 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "json-schema",
- "version": "0.2.0",
+ "version": "0.2.2",
"author": "Kris Zyp",
"description": "JSON Schema validation and specifications",
"maintainers":[
From dbdb322df03008d1bea7d999002ef2a4d41b1383 Mon Sep 17 00:00:00 2001
From: Enrico Marino
Date: Sat, 3 Dec 2011 19:48:31 +0100
Subject: [PATCH 0056/1659] Replaced "maxDecimal" attribute with "divisibleBy"
attribute
---
lib/validate.js | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 97cbbf6f..63aaf9ea 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -179,9 +179,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
addError("does not have a value in the enumeration " + enumer.join(", "));
}
}
- if(typeof schema.maxDecimal == 'number' &&
- (value.toString().match(new RegExp("\\.[0-9]{" + (schema.maxDecimal + 1) + ",}")))){
- addError("may only have " + schema.maxDecimal + " digits of decimal places");
+ if(typeof schema.divisibleBy == 'number' && (value % schema.divisibleBy !== 0)){
+ addError("may be divisible by " + schema.divisibleBy);
}
}
}
From e81fd46ffde2c4b9eea3fe37aa8b0fde8990c882 Mon Sep 17 00:00:00 2001
From: Camilo Aguilar
Date: Mon, 9 Apr 2012 16:51:20 -0400
Subject: [PATCH 0057/1659] Fixes error message
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 97cbbf6f..fedef5ec 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -218,7 +218,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
delete instance[i];
continue;
} else {
- errors.push({property:path,message:(typeof value) + "The property " + i +
+ errors.push({property:path,message:"The property " + i +
" is not defined in the schema and the schema does not allow additional properties"});
}
}
From 3fefea8fc1a4b75cbd5f7b1120aa3f0d188a12a7 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Wed, 9 May 2012 17:29:06 -0600
Subject: [PATCH 0058/1659] * Restored "integer" type. * Renamed "divisibleBy"
to "mod".
---
draft-zyp-json-schema-04.xml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 2b79fccc..f80af872 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -327,6 +327,7 @@ Content-Type: application/json;
Instance MUST be an array.Instance MUST be a string.Instance MUST be a number, including floating point numbers.
+ Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).Instance MUST be the JSON literal "true" or "false".Instance MUST be the JSON literal "null". Note that without this type, null values are not allowed.Instance MAY be of any type, including null.
@@ -491,7 +492,7 @@ Content-Type: application/json;
This attribute is a string that provides a full description of the of purpose the instance property.
-
+ This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
@@ -1014,8 +1015,8 @@ Content-Type: application/json; profile=/schema-for-this-data
Removed irrelevant "Open Issues" section.Merged Conventions and Terminology sections.Defined terms used in specification.
- Removed "integer" type in favor of {"type":"number", "divisibleBy":1}.Restricted "type" to only the core JSON types.
+ Renamed "divisibleBy" to "mod".Improved wording of many sections.
From 42de4af61660548c3b663910960e3f81710202a8 Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Wed, 13 Jun 2012 16:13:01 -0400
Subject: [PATCH 0059/1659] Add support for uniqueItems.
---
lib/validate.js | 51 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 97cbbf6f..529277f7 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -131,7 +131,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.items){
var itemsIsArray = schema.items instanceof Array;
var propDef = schema.items;
- for (i = 0, l = value.length; i < l; i += 1) {
+ for (var i = 0, l = value.length; i < l; i += 1) {
if (itemsIsArray)
propDef = schema.items[i];
if (options.coerce)
@@ -145,6 +145,16 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.maxItems && value.length > schema.maxItems){
addError("There must be a maximum of " + schema.maxItems + " in the array");
}
+ if(schema.uniqueItems) {
+ for(var i = 0, l = value.length; i < l; i += 1) {
+ for(var j = i + 1; j < l; j += 1) {
+ if(!compareItems(value[i], value[j])) {
+ addError("The items in the array must be unique.");
+ break;
+ }
+ }
+ }
+ }
}else if(schema.properties || schema.additionalProperties){
errors.concat(checkObj(value, schema.properties, path, schema.additionalProperties));
}
@@ -194,8 +204,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(typeof instance != 'object' || instance instanceof Array){
errors.push({property:path,message:"an object is required"});
}
-
- for(var i in objTypeDef){
+
+ for(var i in objTypeDef){
if(objTypeDef.hasOwnProperty(i)){
var value = instance[i];
// skip _not_ specified properties
@@ -212,7 +222,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
}
- for(i in instance){
+ for(var i in instance){
if(instance.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_') && objTypeDef && !objTypeDef[i] && additionalProp===false){
if (options.filter) {
delete instance[i];
@@ -239,6 +249,39 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
return errors;
}
+ // compare a value against another for equality (for uniqueItems)
+ function compareItems(item1, item2) {
+ if(typeof item1 !== typeof item2) {
+ return false;
+ }
+ if(Array.isArray(item1)) {
+ if(item1.length !== item2.length) {
+ return false;
+ }
+ for(var i = 0, l = item1.length; i < l; i += 1) {
+ if(!compareItems(item1[i], item2[i])) {
+ return false;
+ }
+ }
+ return true;
+ }
+ if(item1 instanceof Object) {
+ var item1Keys = Object.keys(item1);
+ var item2Keys = Object.keys(item2);
+ if(item1Keys.length !== item2Keys.length) {
+ return false;
+ }
+ for(var i = 0, l = item1Keys.length; i < l; i += 1) {
+ var key = item1Keys[i];
+ if(!item2.hasOwnProperty(key) ||
+ !compareItems(item1[key], item2[key])) {
+ return false;
+ }
+ }
+ return true;
+ }
+ return item1 === item2;
+ }
if(schema){
checkProp(instance,schema,'',_changing || '');
}
From c515e8eb867cae66412eeea93fece8fc051504db Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Mon, 18 Jun 2012 10:02:07 -0400
Subject: [PATCH 0060/1659] Fix inverted comparison.
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 529277f7..9c8c81ad 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -148,7 +148,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.uniqueItems) {
for(var i = 0, l = value.length; i < l; i += 1) {
for(var j = i + 1; j < l; j += 1) {
- if(!compareItems(value[i], value[j])) {
+ if(compareItems(value[i], value[j])) {
addError("The items in the array must be unique.");
break;
}
From 3cdb2f85ab48651b2b12bdaef61bf13c17a76e35 Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Tue, 19 Jun 2012 15:56:33 -0400
Subject: [PATCH 0061/1659] Fix property path handling.
- avoid "undefined" when top level is an array.
- replace '.' in properties with '\.'.
---
lib/validate.js | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 9c8c81ad..f31f9298 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -65,7 +65,14 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
function checkProp(value, schema, path,i){
var l;
- path += path ? typeof i == 'number' ? '[' + i + ']' : typeof i == 'undefined' ? '' : '.' + i : i;
+ if(typeof i !== 'undefined') {
+ if(typeof i === 'number') {
+ path += '[' + i + ']';
+ } else {
+ var escaped = i.replace(/\./g, '\\.');
+ path += path ? ('.' + escaped) : escaped;
+ }
+ }
function addError(message){
errors.push({property:path,message:message});
}
From 96fce4c3eb7f861caef6d72864d77baedcfb7236 Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Tue, 19 Jun 2012 15:58:02 -0400
Subject: [PATCH 0062/1659] Add value and schema to errors.
---
lib/validate.js | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index f31f9298..ad958f4b 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -73,14 +73,18 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
path += path ? ('.' + escaped) : escaped;
}
}
- function addError(message){
- errors.push({property:path,message:message});
+ function addError(message, value){
+ var error = {property:path,message:message,schema:schema};
+ if(typeof value !== 'undefined') {
+ error.value = value;
+ }
+ errors.push(error);
}
if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && getType(schema))){
if(typeof schema == 'function'){
if(!(value instanceof schema)){
- addError("is not an instance of the class/constructor " + schema.name);
+ addError("is not an instance of the class/constructor " + schema.name, value);
}
}else if(schema){
addError("Invalid schema/property definition " + schema);
@@ -131,7 +135,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}else{
errors = errors.concat(checkType(getType(schema),value));
if(schema.disallow && !checkType(schema.disallow,value).length){
- addError(" disallowed value was matched");
+ addError(" disallowed value was matched", value);
}
if(value !== null){
if(value instanceof Array){
@@ -147,16 +151,16 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
if(schema.minItems && value.length < schema.minItems){
- addError("There must be a minimum of " + schema.minItems + " in the array");
+ addError("There must be a minimum of " + schema.minItems + " in the array", value);
}
if(schema.maxItems && value.length > schema.maxItems){
- addError("There must be a maximum of " + schema.maxItems + " in the array");
+ addError("There must be a maximum of " + schema.maxItems + " in the array", value);
}
if(schema.uniqueItems) {
for(var i = 0, l = value.length; i < l; i += 1) {
for(var j = i + 1; j < l; j += 1) {
if(compareItems(value[i], value[j])) {
- addError("The items in the array must be unique.");
+ addError("The items in the array must be unique.", value);
break;
}
}
@@ -166,21 +170,21 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
errors.concat(checkObj(value, schema.properties, path, schema.additionalProperties));
}
if(schema.pattern && typeof value == 'string' && !value.match(schema.pattern)){
- addError("does not match the regex pattern " + schema.pattern);
+ addError("does not match the regex pattern " + schema.pattern, value);
}
if(schema.maxLength && typeof value == 'string' && value.length > schema.maxLength){
- addError("may only be " + schema.maxLength + " characters long");
+ addError("may only be " + schema.maxLength + " characters long", value);
}
if(schema.minLength && typeof value == 'string' && value.length < schema.minLength){
- addError("must be at least " + schema.minLength + " characters long");
+ addError("must be at least " + schema.minLength + " characters long", value);
}
if(typeof schema.minimum !== undefined && typeof value == typeof schema.minimum &&
schema.minimum > value){
- addError("must have a minimum value of " + schema.minimum);
+ addError("must have a minimum value of " + schema.minimum, value);
}
if(typeof schema.maximum !== undefined && typeof value == typeof schema.maximum &&
schema.maximum < value){
- addError("must have a maximum value of " + schema.maximum);
+ addError("must have a maximum value of " + schema.maximum, value);
}
if(schema['enum']){
var enumer = schema['enum'];
@@ -193,12 +197,12 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
if(!found){
- addError("does not have a value in the enumeration " + enumer.join(", "));
+ addError("does not have a value in the enumeration " + enumer.join(", "), value);
}
}
if(typeof schema.maxDecimal == 'number' &&
(value.toString().match(new RegExp("\\.[0-9]{" + (schema.maxDecimal + 1) + ",}")))){
- addError("may only have " + schema.maxDecimal + " digits of decimal places");
+ addError("may only have " + schema.maxDecimal + " digits of decimal places", value);
}
}
}
From f2b69ffdbe241ba7303de59811723f0b35d78d84 Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Sun, 24 Jun 2012 00:56:10 -0400
Subject: [PATCH 0063/1659] Add missing schema and value to type error.
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index ad958f4b..381361b3 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -105,7 +105,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
!(value instanceof Array && type == 'array') &&
!(value instanceof Date && type == 'date') &&
!(type == 'integer' && value%1===0)){
- return [{property:path,message:(typeof value) + " value found, but a " + type + " is required"}];
+ return [{property:path,message:(typeof value) + " value found, but a " + type + " is required",schema:schema,value:value}];
}
if(type instanceof Array){
var unionErrors=[];
From a8b32121881a20f6b819987de5fd99569a546859 Mon Sep 17 00:00:00 2001
From: Gary Court
Date: Wed, 9 May 2012 17:29:06 -0600
Subject: [PATCH 0064/1659] * Restored "integer" type. * Renamed "divisibleBy"
to "mod".
---
draft-zyp-json-schema-04.xml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index f9c1ea5a..0656ccfb 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -327,6 +327,7 @@ Content-Type: application/json;
Instance MUST be an array.Instance MUST be a string.Instance MUST be a number, including floating point numbers.
+ Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).Instance MUST be the JSON literal "true" or "false".Instance MUST be the JSON literal "null". Note that without this type, null values are not allowed.Instance MAY be of any type, including null.
@@ -491,7 +492,7 @@ Content-Type: application/json;
This attribute is a string that provides a full description of the of purpose the instance property.
-
+ This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
@@ -1014,8 +1015,8 @@ Content-Type: application/json; profile=/schema-for-this-data
Removed irrelevant "Open Issues" section.Merged Conventions and Terminology sections.Defined terms used in specification.
- Removed "integer" type in favor of {"type":"number", "divisibleBy":1}.Restricted "type" to only the core JSON types.
+ Renamed "divisibleBy" to "mod".Improved wording of many sections.
From a721fdf9f2e0473f6f5fb8ff77e754033854da1f Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:47:18 +0200
Subject: [PATCH 0065/1659] draft-04/schema: modify the "type" property
definition
Now that the "integer" type is being reintroduced, we can redefine "type" as it
was in draft v3.
---
draft-04/schema | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 598951e5..449e68d7 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -5,19 +5,9 @@
"properties" : {
"type" : {
- "type" : [
- {
- "id" : "#simple-type",
- "type" : "string",
- "enum" : ["object", "array", "string", "number", "boolean", "null", "any"]
- },
- "array"
- ],
+ "type" : ["string", "array"],
"items" : {
- "type" : [
- {"$ref" : "#simple-type"},
- {"$ref" : "#"}
- ]
+ "type" : ["string", {"$ref" : "#"}]
},
"uniqueItems" : true,
"default" : "any"
From dc768f55d60604e30c8dd7dcae68772be1e21000 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:51:46 +0200
Subject: [PATCH 0066/1659] draft-04/schema: cosmetic: fix whitespaces
---
draft-04/schema | 64 ++++++++++++++++++++++++-------------------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 449e68d7..e1784f43 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -2,7 +2,7 @@
"$schema" : "http://json-schema.org/draft-04/schema#",
"id" : "http://json-schema.org/draft-04/schema#",
"type" : "object",
-
+
"properties" : {
"type" : {
"type" : ["string", "array"],
@@ -12,7 +12,7 @@
"uniqueItems" : true,
"default" : "any"
},
-
+
"disallow" : {
"type" : ["string", "array"],
"items" : {
@@ -20,7 +20,7 @@
},
"uniqueItems" : true
},
-
+
"extends" : {
"type" : [{"$ref" : "#"}, "array"],
"items" : {"$ref" : "#"},
@@ -32,108 +32,108 @@
"minItems" : 1,
"uniqueItems" : true
},
-
+
"minimum" : {
"type" : "number"
},
-
+
"maximum" : {
"type" : "number"
},
-
+
"exclusiveMinimum" : {
"type" : "boolean",
"default" : false
},
-
+
"exclusiveMaximum" : {
"type" : "boolean",
"default" : false
},
-
+
"divisibleBy" : {
"type" : "number",
"minimum" : 0,
"exclusiveMinimum" : true,
"default" : 1
},
-
+
"minLength" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxLength" : {
"type" : "integer"
},
-
+
"pattern" : {
"type" : "string"
},
-
+
"items" : {
"type" : [{"$ref" : "#"}, "array"],
"items" : {"$ref" : "#"},
"default" : {}
},
-
+
"additionalItems" : {
"type" : [{"$ref" : "#"}, "boolean"],
"default" : {}
},
-
+
"minItems" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxItems" : {
"type" : "integer",
"minimum" : 0
},
-
+
"uniqueItems" : {
"type" : "boolean",
"default" : false
},
-
+
"properties" : {
"type" : "object",
"additionalProperties" : {"$ref" : "#"},
"default" : {}
},
-
+
"patternProperties" : {
"type" : "object",
"additionalProperties" : {"$ref" : "#"},
"default" : {}
},
-
+
"additionalProperties" : {
"type" : [{"$ref" : "#"}, "boolean"],
"default" : {}
},
-
+
"minProperties" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxProperties" : {
"type" : "integer",
"minimum" : 0
},
-
+
"required" : {
"type" : "array",
"items" : {
"type" : "string"
}
},
-
+
"dependencies" : {
"type" : "object",
"additionalProperties" : {
@@ -144,36 +144,36 @@
},
"default" : {}
},
-
+
"id" : {
"type" : "string"
},
-
+
"$ref" : {
"type" : "string"
},
-
+
"$schema" : {
"type" : "string"
},
-
+
"title" : {
"type" : "string"
},
-
+
"description" : {
"type" : "string"
},
-
+
"default" : {
"type" : "any"
}
},
-
+
"dependencies" : {
"exclusiveMinimum" : "minimum",
"exclusiveMaximum" : "maximum"
},
-
+
"default" : {}
-}
\ No newline at end of file
+}
From c74ee28cabb8d48b984b49e8b6450349b1fd654f Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:52:14 +0200
Subject: [PATCH 0067/1659] draft-04/schema: catch up with "divisibleBy" rename
It is now called "mod".
---
draft-04/schema | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-04/schema b/draft-04/schema
index e1784f43..027c1c1e 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -51,7 +51,7 @@
"default" : false
},
- "divisibleBy" : {
+ "mod" : {
"type" : "number",
"minimum" : 0,
"exclusiveMinimum" : true,
From ba1a92c67d306a5266f67715560aa3b85da63360 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:52:50 +0200
Subject: [PATCH 0068/1659] Re-introduce "format" keyword, with some
differences
* Get rid of the "color" and "style" format attributes.
* Specify the different instance types which can be validated by attributes.
* Specify that if an instance is not of a type which the format attribute can
validate, the validation MUST succeed.
* "regex" is an ECMA 262 regular expression, remove "/perl5" since these
dialects are not compatible (perl5 supports lookbehinds, ECMA 262 doesn't).
* Remove paragraph allowing other format attributes to be specified.
---
draft-04/schema | 12 ++++++++----
draft-zyp-json-schema-04.xml | 34 +++++++++++++++++++++++++++++++++-
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 027c1c1e..be519795 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -69,7 +69,8 @@
},
"pattern" : {
- "type" : "string"
+ "type" : "string",
+ "format": "regex"
},
"items" : {
@@ -146,15 +147,18 @@
},
"id" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"$ref" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"$schema" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"title" : {
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 0656ccfb..fe1d0ca5 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -463,7 +463,39 @@ Content-Type: application/json;
-
+
+
+ This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format
+ attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format
+ SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MUST validate that the
+ instance values conform to a format.
+
+ A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance
+ is not a member of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are
+ listed along with the primitive types they validate.
+
+ The following formats are predefined:
+
+
+ (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
+ This is the recommended form of date/timestamp.
+ (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
+ "date-time" format instead of "date" unless you need to transfer only the date part.
+ (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
+ "date-time" format instead of "time" unless you need to transfer only the time part.
+ (number) This SHOULD be the difference, measured in milliseconds, between the
+ specified time and midnight, 00:00 of January 1, 1970 UTC.
+ (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
+ (string) This SHOULD be a phone number (format MAY follow E.123).
+ (string) This value SHOULD be a URI.
+ (string) This SHOULD be an email address.
+ (string) This SHOULD be an ip version 4 address.
+ (string) This SHOULD be an ip version 6 address.
+ (string) This SHOULD be a host-name.
+
+
+
+
When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
From d433449190dc5631b54b3397b7689d4469bc0ed3 Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Wed, 11 Jul 2012 16:29:20 -0400
Subject: [PATCH 0069/1659] Add more verbose handling.
- Use a common addError in checkObj.
- Print out schema and value if given.
---
lib/validate.js | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 381361b3..be4a93b2 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -62,7 +62,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
var errors = [];
// validate a value against a property definition
- function checkProp(value, schema, path,i){
+ function checkProp(value, schema, path, i){
var l;
if(typeof i !== 'undefined') {
@@ -211,9 +211,17 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
// validate an object against a schema
function checkObj(instance,objTypeDef,path,additionalProp){
+ function addError(message, value){
+ var error = {property:path,message:message,schema:objTypeDef};
+ if(typeof value !== 'undefined') {
+ error.value = value;
+ }
+ errors.push(error);
+ }
+
if(typeof objTypeDef =='object'){
if(typeof instance != 'object' || instance instanceof Array){
- errors.push({property:path,message:"an object is required"});
+ addError("an object is required", instance);
}
for(var i in objTypeDef){
@@ -239,13 +247,13 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
delete instance[i];
continue;
} else {
- errors.push({property:path,message:(typeof value) + "The property " + i +
- " is not defined in the schema and the schema does not allow additional properties"});
+ addError("The property '" + i +
+ "' is not defined in the schema and the schema does not allow additional properties", instance);
}
}
var requires = objTypeDef && objTypeDef[i] && objTypeDef[i].requires;
if(requires && !(requires in instance)){
- errors.push({property:path,message:"the presence of the property " + i + " requires that " + requires + " also be present"});
+ addError("the presence of the property " + i + " requires that " + requires + " also be present", instance);
}
value = instance[i];
if(additionalProp && (!(objTypeDef && typeof objTypeDef == 'object') || !(i in objTypeDef))){
From 0077b4d3c3cb14a6227bbbb00310dfdb3a0921f7 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Thu, 12 Jul 2012 00:22:07 +0200
Subject: [PATCH 0070/1659] Separate core schema keywords into different
sections
Keywords are split into three types:
* keywords validating only a certain type of instances;
* keywords validating all instance types;
* keywords not participating in instance validation.
---
draft-zyp-json-schema-04.xml | 686 ++++++++++++++++++++---------------
1 file changed, 399 insertions(+), 287 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index fe1d0ca5..6ba842ee 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -305,307 +305,419 @@ Content-Type: application/json;
]]>
-
-
- A JSON Schema object MAY have any of the following optional properties:
-
-
-
-
-
-
-
- This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
- This attribute can take one of two forms:
-
-
- A string indicating a primitive or simple type. The string MUST be one of the following values:
+ A JSON Schema object MAY have one or more of the properties defined in this section. These properties (called "keywords" in this section) are
+ grouped in subsections according to the type of instance they can validate, while some properties apply to all instance types. Some other keywords
+ do not participate in instance validation and are into a section of their own.
-
- Instance MUST be an object.
- Instance MUST be an array.
- Instance MUST be a string.
- Instance MUST be a number, including floating point numbers.
- Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).
- Instance MUST be the JSON literal "true" or "false".
- Instance MUST be the JSON literal "null". Note that without this type, null values are not allowed.
- Instance MAY be of any type, including null.
-
-
-
-
- An array of one or more simple or schema types.
- The instance value is valid if it is of the same type as one of the simple types, or valid by one of the schemas, in the array.
-
-
-
- If this attribute is not specified, then all value types are accepted.
-
-
-
- For example, a schema that defines if an instance can be a string or a number would be:
-
+
+
+
+
+ The value of this keyword is a number which defines the minimum value of the instance.
+
+
+
+
+
+ The value of this keyword is a number which defines the maximum value of the instance.
+
+
+
+
+
+ This keyword MUST be paired with "minimum". Its value is a boolean. If false (the default), then the instance may be greater than or equal to "minimum". If true, then the instance must be strictly greater than "minimum".
+
+
+
+
+
+ This keyword MUST be paired with "maximum". Its value is a boolean. If false (the default), then the instance may be less than or equal to "maximum". If true, then the instance must be strictly lower than "maximum".
+
+
+
+
+
+ This keyword's value is a number which must divide instance with no remainder (that is, the result of the division must be an integer.) The value of this keyword MUST NOT be 0.
+
+
+
+
+
+
+
+
+
+ The value of this keyword is an ECMA 262 regular expression that the instance MUST match in order to be valid.
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum length of the instance.
+
+
+
+
+
+ The value of this keyword is an integer which defines the maximum length of the instance.
+
+
+
+
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum number of elements in the instance.
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum number of elements in the instance.
+
+
+
+
+
+ This keyword defines a set of allowed items in the instance. The value of this keyword MUST be a schema or an array of schemas:
+
+ if it is a schema, then all items in the instance MUST be valid against this schema;
+ if it is an array of schemas, then the item at a given position in the instance MUST be valid according to the corresponding schema at
+ the same position in the keyword value. This is called tuple typing. Constraints on items in the instance which have no corresponding
+ schema in the keyword value are defined by "additionalItems".
+
+
+
+
+
+
+
+ This keyword specifies how to handle items in the instance which are is not explicitly defined by "items". Its value
+ MUST be a schema or a boolean. Boolean value true is equivalent to an empty schema.
+
+ If "items" is present and its value is a schema, "additionalItems" is ignored.
+
+ If "items" is defined and is an array of n elements, then:
+
+ if "additionalItems" is false, then the instance is valid with regards to this keyword if and only if it has at most n elements;
+ if "additionalItems" is a schema, then all instance elements of index n or greater (assuming array indexes start at 0) MUST be valid
+ against this schema.
+
+
+
+ If "items" is not defined, then:
+
+ if "additionalItems" is false, then the instance is invalid;
+ if "additionalItems" is a schema, then all instance elements MUST be valid against this schema.
+
+
+
+ The default value is an empty schema, which allows any value for additional items.
+
+
+
+
+
+ This keyword indicates that all items in the instance MUST be unique (contains no two identical values).
+
+
+ Two JSON instances are consider equal if they are both of the same type and:
+
+ are null; or
+ are booleans/numbers/strings and have the same value; or
+ are arrays, contain the same number of items, and each item in the array is equal to the item at the corresponding index in the other
+ array; or
+ are objects, contain the same set of property names, and each property in the object is equal to the corresponding property in the other
+ object.
+
+
+
+
+
+
+
+
+
+
+
+ The value of this keyword is a positive integer which defines the minimum number of properties the instance must have.
+
+
+
+
+
+ The value of this keyword is a positive integer which defines the maximum number of properties the instance must have.
+
+
+
+
+
+ The value of this keyword is an object where:
+
+ property name match equivalent property names in the instance, if any, and
+ property values are schemas.
+
+
+
+ If the instance has a property name which is equal to a property name defined in this keyword, then the property value MUST be valid against the
+ corresponding schema.
+
+ Objects are unordered, therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
+
+
+
+
+
+ The value of this keyword is an object where:
+
+ property names are ECMA 262 regular expressions, and
+ property values are schemas.
+
+
+
+ For each property name of the instance, if it is matched by one or more regular expressions defined by this keyword, then the matching value MUST
+ be valid against all such schemas.
+
+ Note that regular expressions are not anchored.
+
+
+
+
+
+ This keyword defines how to handle an instance's properties which could not be matched by either "properties" or
+ "patternProperties" (here after referred to as "additional properties"). Its value MUST be either a schema
+ or a boolean. Boolean value true is equivalent to an empty schema.
+
+ If the value of this keyword is false, then the instance is valid if and only if there are no additional properties in the instance.
+
+ If the value of this keyword is a schema, then all additional properties MUST be valid against this schema.
+
+ The default value is an empty schema, which allows any value for additional properties.
+
+
+
+
+
+ The value of this keyword is an array of strings which defines all the property names that must exist on the instance for it to be valid.
+
+
+
+
+
+ The value of this keyword is an object. Property names of this object match equivalent property names in the instance, if any. Property values are either of:
+
+ a string or an array of strings; in this case, the instance is valid if and only if the instance has the corresponding property name(s);
+ a schema; in this case, the instance is valid if and only if the value of the corresponding property name is valid against this schema.
+
+
+
+
+
+
+
+ It should be noted that validation by "properties" and "patternProperties" are not exclusive: if a property name in an instance is matched by
+ both a property name in "properties" and one or more regular expressions in "patternProperties", then the corresponding value MUST validate against
+ all of these schemas.
+
+
+
+
+
+
+
+
+
+ This keyword defines what the primitive type or the schema of the instance MUST be in order to validate. This attribute can take one of two
+ forms:
+
+ A string indicating a primitive or simple type. The string MUST be one of the following values:
+
+ Instance MUST be an object.
+ Instance MUST be an array.
+ Instance MUST be a string.
+ Instance MUST be a number, including floating point numbers.
+ Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).
+ Instance MUST be a JSON boolean (true or false).
+ Instance MUST be the JSON literal null. Note that without this type, null values are not allowed.
+ Instance MAY be of any type, including null.
+
+
+ An array of one or more simple types or schemas. The instance value is valid if it is of the same type as one of
+ the simple types, or valid by one of the schemas.
+
+
+
+ If this attribute is not specified, then all value types are accepted.
+
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
-
-
-
-
-
- This attribute is an object with properties that specify the schemas for the properties of the instance object.
- In this attribute's object, each property value MUST be a schema.
- When the instance value is an object, the value of the instance's properties MUST be valid according to the schemas with the same property names specified in this attribute.
- Objects are unordered, so therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
-
-
-
-
-
- This attribute is an object that defines the schema for a set of property names of an object instance.
- The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema.
- If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
-
-
-
-
- This attribute specifies how any instance property that is not explicitly defined by either the "properties" or "patternProperties" attributes (hereafter referred to as "additional properties") is handled. If specified, the value MUST be a schema or a boolean.
- If a schema is provided, then all additional properties MUST be valid according to the schema.
- If false is provided, then no additional properties are allowed.
- The default value is an empty schema, which allows any value for additional properties.
-
-
-
- This attribute provides the allowed items in an array instance. If specified, this attribute MUST be a schema or an array of schemas.
- When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
- When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST be valid according to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute the same way as "additionalProperties" for objects is.
-
-
-
- This attribute specifies how any item in the array instance that is not explicitly defined by "items" (hereafter referred to as "additional items") is handled. If specified, the value MUST be a schema or a boolean.
- If a schema is provided:
-
- If the "items" attribute is unspecified, then all items in the array instance must be valid against this schema.
- If the "items" attribute is a schema, then this attribute is ignored.
- If the "items" attribute is an array (during tuple typing), then any additional items MUST be valid against this schema.
-
-
- If false is provided, then any additional items in the array are not allowed.
- The default value is an empty schema, which allows any value for additional items.
-
-
-
- This attribute is an array of strings that defines all the property names that must exist on the object instance.
-
-
-
- This attribute is an object that specifies the requirements of a property on an object instance. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
-
- The dependency value can take one of two forms:
-
-
-
- If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value.
- If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
-
-
- If the dependency value is a schema, then the instance object MUST be valid against the schema.
-
-
-
-
-
-
- This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-
-
-
- This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-
-
-
- This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-
-
-
- This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-
-
-
- This attribute defines the minimum number of values in an array when the array is the instance value.
-
-
-
- This attribute defines the maximum number of values in an array when the array is the instance value.
-
-
-
- This attribute defines the minimum number of properties required on an object instance.
-
-
-
- This attribute defines the maximum number of properties the object instance can have.
-
-
-
- This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
-
- Two instance are consider equal if they are both of the same type and:
-
-
- are null; or
- are booleans/numbers/strings and have the same value; or
- are arrays, contains the same number of items, and each item in the array is equal to the item at the corresponding index in the other array; or
- are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
-
-
-
+]]>
+
+
-
- This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format
- attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format
- SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MUST validate that the
- instance values conform to a format.
-
- A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance
- is not a member of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are
- listed along with the primitive types they validate.
-
- The following formats are predefined:
-
-
- (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
- This is the recommended form of date/timestamp.
- (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
- "date-time" format instead of "date" unless you need to transfer only the date part.
- (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
- "date-time" format instead of "time" unless you need to transfer only the time part.
- (number) This SHOULD be the difference, measured in milliseconds, between the
- specified time and midnight, 00:00 of January 1, 1970 UTC.
- (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
- (string) This SHOULD be a phone number (format MAY follow E.123).
- (string) This value SHOULD be a URI.
- (string) This SHOULD be an email address.
- (string) This SHOULD be an ip version 4 address.
- (string) This SHOULD be an ip version 6 address.
- (string) This SHOULD be a host-name.
-
-
-
-
-
- When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
-
-
- When the instance value is a string, this defines the minimum length of the string.
-
-
-
- When the instance value is a string, this defines the maximum length of the string.
-
-
-
- This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
-
-
-
- This attribute defines the default value of the instance when the instance is undefined.
-
-
-
- This attribute is a string that provides a short description of the instance property.
-
-
-
- This attribute is a string that provides a full description of the of purpose the instance property.
-
-
-
- This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
-
-
-
- This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-
-
-
- The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
-
- Conceptually, the behavior of extends can be seen as validating an
- instance against all constraints in the extending schema as well as
- the extended schema(s). More optimized implementations that merge
- schemas are possible, but are not required. Some examples of using "extends":
-
-
-
+
+
+
+
+ This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the
+ instance matches any type or schema in the array, then this instance is not valid.
+
+
+
+
+
+
+
+ This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format attribute MAY be one
+ of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to
+ primitive types (string, integer, number, or boolean). Validators MUST validate that instances conform to a format.
+
+ A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance is not a member
+ of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are listed along with the primitive
+ types they validate.
+
+ The following formats are predefined:
+
+ (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
+ This is the recommended form of date/timestamp.
+ (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
+ "date-time" format instead of "date" unless you need to transfer only the date part.
+ (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
+ "date-time" format instead of "time" unless you need to transfer only the time part.
+ (number) This SHOULD be the difference, measured in milliseconds, between the
+ specified time and midnight, 00:00 of January 1, 1970 UTC.
+ (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
+ (string) This SHOULD be a phone number (format MAY follow E.123).
+ (string) This value SHOULD be a URI.
+ (string) This SHOULD be an email address.
+ (string) This SHOULD be an ip version 4 address.
+ (string) This SHOULD be an ip version 6 address.
+ (string) This SHOULD be a host-name.
+
+
+
+
+
+
+
+ The value of this keyword is an array which provides an enumeration of JSON instances. The instance value MUST be one of the values in the array in order
+ for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+ The array MUST have at least one element. Elements in the array MUST be unique.
+
+
+
+
+
+ The value of this keyword MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance
+ rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an
+ array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional
+ attributes, constrain existing attributes, or add other constraints.
+
+ Conceptually, the behavior of extends can be seen as validating an instance against all constraints in the extending schema as well as the
+ extended schema(s). More optimized implementations that merge schemas are possible, but are not required. Some examples of using "extends":
+
+
+
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
-
-
- This attribute defines the current URI of this schema (this attribute is
- effectively a "self" link). This URI MAY be relative or absolute. If
- the URI is relative it is resolved against the current URI of the parent
- schema it is contained in. If this schema is not contained in any
- parent schema, the current URI of the parent schema is held to be the
- URI under which this schema was addressed. If id is missing, the current URI of a schema is
- defined to be that of the parent schema. The current URI of the schema
- is also used to construct relative references such as for $ref.
-
-
-
-
-
- This attribute defines a URI of a schema that contains the full representation of this schema.
- When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
- This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
-
-
-
-
-
- This attribute defines a URI of a JSON Schema that is the schema of the current schema.
- When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
-
-
-
- A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
- Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
-
-
+
+
+
+
+
+
+
+
+
+
+ The following keywords do not play any role in instance validation "per se", however three of them ("$ref", "id" and "$schema") play an important role in the validation process.
+
+
+
+ This keyword defines the default value of the instance when the instance is undefined.
+
+ Note that it is NOT required that the value of the instance matches the enclosing schema.
+
+
+
+
+
+ This keyword is a string that provides a short description of the instance property.
+
+
+
+
+
+ This keyword is a string that provides a full description of the of purpose the instance property.
+
+
+
+
+
+
+ This keyword defines the current URI of this schema (this attribute is effectively a "self" link). This URI MAY be relative or absolute. If the
+ URI is relative it is resolved against the current URI of the parent schema it is contained in. If this schema is not contained in any parent
+ schema, the current URI of the parent schema is held to be the URI under which this schema was addressed. If id is missing, the current URI of a
+ schema is defined to be that of the parent schema. The current URI of the schema is also used to construct relative references such as for $ref.
+
+
+
+
+
+ This attribute defines a URI of a schema that contains the full representation of this schema. When a validator encounters this attribute, it
+ SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance. This URI MAY
+ be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+
+ This attribute defines a URI of a JSON Schema that is the schema of the current schema. When this attribute is defined, a validator SHOULD use
+ the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+ A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the
+ appropriate validation features and behavior. Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to
+ prevent conflicts with future JSON Schema specification changes.
+
+
+
+
+
From 53510356d66385a59bc5f7d2aa70799742e7baf4 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 29 Nov 2011 21:20:32 -0700
Subject: [PATCH 0071/1659] Better wording of items and their array indices
---
draft-zyp-json-schema-04.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index f80af872..0656ccfb 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -458,7 +458,7 @@ Content-Type: application/json;
are null; orare booleans/numbers/strings and have the same value; or
- are arrays, contains the same number of items, and each item in the array is equal to the corresponding item in the other array; or
+ are arrays, contains the same number of items, and each item in the array is equal to the item at the corresponding index in the other array; orare objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
From 63131cd17a4c5facf4e34e67b47c6720d6d1914f Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 29 Nov 2011 21:20:38 -0700
Subject: [PATCH 0072/1659] bump version
---
package.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package.json b/package.json
index 51db2e9a..0ff652a7 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "json-schema",
- "version": "0.2.0",
+ "version": "0.2.2",
"author": "Kris Zyp",
"description": "JSON Schema validation and specifications",
"maintainers":[
From 2ac67ad70e0fbeca2beb68b6d1c148f05dcd5518 Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Wed, 13 Jun 2012 16:13:01 -0400
Subject: [PATCH 0073/1659] Add support for uniqueItems.
---
lib/validate.js | 51 +++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 97cbbf6f..529277f7 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -131,7 +131,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.items){
var itemsIsArray = schema.items instanceof Array;
var propDef = schema.items;
- for (i = 0, l = value.length; i < l; i += 1) {
+ for (var i = 0, l = value.length; i < l; i += 1) {
if (itemsIsArray)
propDef = schema.items[i];
if (options.coerce)
@@ -145,6 +145,16 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.maxItems && value.length > schema.maxItems){
addError("There must be a maximum of " + schema.maxItems + " in the array");
}
+ if(schema.uniqueItems) {
+ for(var i = 0, l = value.length; i < l; i += 1) {
+ for(var j = i + 1; j < l; j += 1) {
+ if(!compareItems(value[i], value[j])) {
+ addError("The items in the array must be unique.");
+ break;
+ }
+ }
+ }
+ }
}else if(schema.properties || schema.additionalProperties){
errors.concat(checkObj(value, schema.properties, path, schema.additionalProperties));
}
@@ -194,8 +204,8 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(typeof instance != 'object' || instance instanceof Array){
errors.push({property:path,message:"an object is required"});
}
-
- for(var i in objTypeDef){
+
+ for(var i in objTypeDef){
if(objTypeDef.hasOwnProperty(i)){
var value = instance[i];
// skip _not_ specified properties
@@ -212,7 +222,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
}
- for(i in instance){
+ for(var i in instance){
if(instance.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_') && objTypeDef && !objTypeDef[i] && additionalProp===false){
if (options.filter) {
delete instance[i];
@@ -239,6 +249,39 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
return errors;
}
+ // compare a value against another for equality (for uniqueItems)
+ function compareItems(item1, item2) {
+ if(typeof item1 !== typeof item2) {
+ return false;
+ }
+ if(Array.isArray(item1)) {
+ if(item1.length !== item2.length) {
+ return false;
+ }
+ for(var i = 0, l = item1.length; i < l; i += 1) {
+ if(!compareItems(item1[i], item2[i])) {
+ return false;
+ }
+ }
+ return true;
+ }
+ if(item1 instanceof Object) {
+ var item1Keys = Object.keys(item1);
+ var item2Keys = Object.keys(item2);
+ if(item1Keys.length !== item2Keys.length) {
+ return false;
+ }
+ for(var i = 0, l = item1Keys.length; i < l; i += 1) {
+ var key = item1Keys[i];
+ if(!item2.hasOwnProperty(key) ||
+ !compareItems(item1[key], item2[key])) {
+ return false;
+ }
+ }
+ return true;
+ }
+ return item1 === item2;
+ }
if(schema){
checkProp(instance,schema,'',_changing || '');
}
From 4ce673f7d2538e9db3724640b141f17b6b4761ae Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Mon, 18 Jun 2012 10:02:07 -0400
Subject: [PATCH 0074/1659] Fix inverted comparison.
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 529277f7..9c8c81ad 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -148,7 +148,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
if(schema.uniqueItems) {
for(var i = 0, l = value.length; i < l; i += 1) {
for(var j = i + 1; j < l; j += 1) {
- if(!compareItems(value[i], value[j])) {
+ if(compareItems(value[i], value[j])) {
addError("The items in the array must be unique.");
break;
}
From 786b881f75c76b5919a319d80eb1b0e665f3e858 Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Tue, 19 Jun 2012 15:56:33 -0400
Subject: [PATCH 0075/1659] Fix property path handling.
- avoid "undefined" when top level is an array.
- replace '.' in properties with '\.'.
---
lib/validate.js | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index 9c8c81ad..f31f9298 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -65,7 +65,14 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
function checkProp(value, schema, path,i){
var l;
- path += path ? typeof i == 'number' ? '[' + i + ']' : typeof i == 'undefined' ? '' : '.' + i : i;
+ if(typeof i !== 'undefined') {
+ if(typeof i === 'number') {
+ path += '[' + i + ']';
+ } else {
+ var escaped = i.replace(/\./g, '\\.');
+ path += path ? ('.' + escaped) : escaped;
+ }
+ }
function addError(message){
errors.push({property:path,message:message});
}
From fa2c61bd435a51d582a5b169c13adc6ed7f2f12f Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Tue, 19 Jun 2012 15:58:02 -0400
Subject: [PATCH 0076/1659] Add value and schema to errors.
---
lib/validate.js | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index f31f9298..ad958f4b 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -73,14 +73,18 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
path += path ? ('.' + escaped) : escaped;
}
}
- function addError(message){
- errors.push({property:path,message:message});
+ function addError(message, value){
+ var error = {property:path,message:message,schema:schema};
+ if(typeof value !== 'undefined') {
+ error.value = value;
+ }
+ errors.push(error);
}
if((typeof schema != 'object' || schema instanceof Array) && (path || typeof schema != 'function') && !(schema && getType(schema))){
if(typeof schema == 'function'){
if(!(value instanceof schema)){
- addError("is not an instance of the class/constructor " + schema.name);
+ addError("is not an instance of the class/constructor " + schema.name, value);
}
}else if(schema){
addError("Invalid schema/property definition " + schema);
@@ -131,7 +135,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}else{
errors = errors.concat(checkType(getType(schema),value));
if(schema.disallow && !checkType(schema.disallow,value).length){
- addError(" disallowed value was matched");
+ addError(" disallowed value was matched", value);
}
if(value !== null){
if(value instanceof Array){
@@ -147,16 +151,16 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
if(schema.minItems && value.length < schema.minItems){
- addError("There must be a minimum of " + schema.minItems + " in the array");
+ addError("There must be a minimum of " + schema.minItems + " in the array", value);
}
if(schema.maxItems && value.length > schema.maxItems){
- addError("There must be a maximum of " + schema.maxItems + " in the array");
+ addError("There must be a maximum of " + schema.maxItems + " in the array", value);
}
if(schema.uniqueItems) {
for(var i = 0, l = value.length; i < l; i += 1) {
for(var j = i + 1; j < l; j += 1) {
if(compareItems(value[i], value[j])) {
- addError("The items in the array must be unique.");
+ addError("The items in the array must be unique.", value);
break;
}
}
@@ -166,21 +170,21 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
errors.concat(checkObj(value, schema.properties, path, schema.additionalProperties));
}
if(schema.pattern && typeof value == 'string' && !value.match(schema.pattern)){
- addError("does not match the regex pattern " + schema.pattern);
+ addError("does not match the regex pattern " + schema.pattern, value);
}
if(schema.maxLength && typeof value == 'string' && value.length > schema.maxLength){
- addError("may only be " + schema.maxLength + " characters long");
+ addError("may only be " + schema.maxLength + " characters long", value);
}
if(schema.minLength && typeof value == 'string' && value.length < schema.minLength){
- addError("must be at least " + schema.minLength + " characters long");
+ addError("must be at least " + schema.minLength + " characters long", value);
}
if(typeof schema.minimum !== undefined && typeof value == typeof schema.minimum &&
schema.minimum > value){
- addError("must have a minimum value of " + schema.minimum);
+ addError("must have a minimum value of " + schema.minimum, value);
}
if(typeof schema.maximum !== undefined && typeof value == typeof schema.maximum &&
schema.maximum < value){
- addError("must have a maximum value of " + schema.maximum);
+ addError("must have a maximum value of " + schema.maximum, value);
}
if(schema['enum']){
var enumer = schema['enum'];
@@ -193,12 +197,12 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
}
if(!found){
- addError("does not have a value in the enumeration " + enumer.join(", "));
+ addError("does not have a value in the enumeration " + enumer.join(", "), value);
}
}
if(typeof schema.maxDecimal == 'number' &&
(value.toString().match(new RegExp("\\.[0-9]{" + (schema.maxDecimal + 1) + ",}")))){
- addError("may only have " + schema.maxDecimal + " digits of decimal places");
+ addError("may only have " + schema.maxDecimal + " digits of decimal places", value);
}
}
}
From 839db826e0558a21f16f309366c9849ecaa14834 Mon Sep 17 00:00:00 2001
From: Dave Longley
Date: Sun, 24 Jun 2012 00:56:10 -0400
Subject: [PATCH 0077/1659] Add missing schema and value to type error.
---
lib/validate.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/validate.js b/lib/validate.js
index ad958f4b..381361b3 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -105,7 +105,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
!(value instanceof Array && type == 'array') &&
!(value instanceof Date && type == 'date') &&
!(type == 'integer' && value%1===0)){
- return [{property:path,message:(typeof value) + " value found, but a " + type + " is required"}];
+ return [{property:path,message:(typeof value) + " value found, but a " + type + " is required",schema:schema,value:value}];
}
if(type instanceof Array){
var unionErrors=[];
From 40524f08043a2afc7dfb9e07207175280e57d2e5 Mon Sep 17 00:00:00 2001
From: "David I. Lehn"
Date: Wed, 11 Jul 2012 16:29:20 -0400
Subject: [PATCH 0078/1659] Add more verbose handling.
- Use a common addError in checkObj.
- Print out schema and value if given.
---
lib/validate.js | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/validate.js b/lib/validate.js
index 381361b3..be4a93b2 100644
--- a/lib/validate.js
+++ b/lib/validate.js
@@ -62,7 +62,7 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
}
var errors = [];
// validate a value against a property definition
- function checkProp(value, schema, path,i){
+ function checkProp(value, schema, path, i){
var l;
if(typeof i !== 'undefined') {
@@ -211,9 +211,17 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
// validate an object against a schema
function checkObj(instance,objTypeDef,path,additionalProp){
+ function addError(message, value){
+ var error = {property:path,message:message,schema:objTypeDef};
+ if(typeof value !== 'undefined') {
+ error.value = value;
+ }
+ errors.push(error);
+ }
+
if(typeof objTypeDef =='object'){
if(typeof instance != 'object' || instance instanceof Array){
- errors.push({property:path,message:"an object is required"});
+ addError("an object is required", instance);
}
for(var i in objTypeDef){
@@ -239,13 +247,13 @@ var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*O
delete instance[i];
continue;
} else {
- errors.push({property:path,message:(typeof value) + "The property " + i +
- " is not defined in the schema and the schema does not allow additional properties"});
+ addError("The property '" + i +
+ "' is not defined in the schema and the schema does not allow additional properties", instance);
}
}
var requires = objTypeDef && objTypeDef[i] && objTypeDef[i].requires;
if(requires && !(requires in instance)){
- errors.push({property:path,message:"the presence of the property " + i + " requires that " + requires + " also be present"});
+ addError("the presence of the property " + i + " requires that " + requires + " also be present", instance);
}
value = instance[i];
if(additionalProp && (!(objTypeDef && typeof objTypeDef == 'object') || !(i in objTypeDef))){
From 2ea755241ebf65f78e7d7392aa66743a85a799c0 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:47:18 +0200
Subject: [PATCH 0079/1659] draft-04/schema: modify the "type" property
definition
Now that the "integer" type is being reintroduced, we can redefine "type" as it
was in draft v3.
---
draft-04/schema | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 598951e5..449e68d7 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -5,19 +5,9 @@
"properties" : {
"type" : {
- "type" : [
- {
- "id" : "#simple-type",
- "type" : "string",
- "enum" : ["object", "array", "string", "number", "boolean", "null", "any"]
- },
- "array"
- ],
+ "type" : ["string", "array"],
"items" : {
- "type" : [
- {"$ref" : "#simple-type"},
- {"$ref" : "#"}
- ]
+ "type" : ["string", {"$ref" : "#"}]
},
"uniqueItems" : true,
"default" : "any"
From 6920f2b1af1425506a1df89d1e220b68a5fa4414 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:51:46 +0200
Subject: [PATCH 0080/1659] draft-04/schema: cosmetic: fix whitespaces
---
draft-04/schema | 64 ++++++++++++++++++++++++-------------------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 449e68d7..e1784f43 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -2,7 +2,7 @@
"$schema" : "http://json-schema.org/draft-04/schema#",
"id" : "http://json-schema.org/draft-04/schema#",
"type" : "object",
-
+
"properties" : {
"type" : {
"type" : ["string", "array"],
@@ -12,7 +12,7 @@
"uniqueItems" : true,
"default" : "any"
},
-
+
"disallow" : {
"type" : ["string", "array"],
"items" : {
@@ -20,7 +20,7 @@
},
"uniqueItems" : true
},
-
+
"extends" : {
"type" : [{"$ref" : "#"}, "array"],
"items" : {"$ref" : "#"},
@@ -32,108 +32,108 @@
"minItems" : 1,
"uniqueItems" : true
},
-
+
"minimum" : {
"type" : "number"
},
-
+
"maximum" : {
"type" : "number"
},
-
+
"exclusiveMinimum" : {
"type" : "boolean",
"default" : false
},
-
+
"exclusiveMaximum" : {
"type" : "boolean",
"default" : false
},
-
+
"divisibleBy" : {
"type" : "number",
"minimum" : 0,
"exclusiveMinimum" : true,
"default" : 1
},
-
+
"minLength" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxLength" : {
"type" : "integer"
},
-
+
"pattern" : {
"type" : "string"
},
-
+
"items" : {
"type" : [{"$ref" : "#"}, "array"],
"items" : {"$ref" : "#"},
"default" : {}
},
-
+
"additionalItems" : {
"type" : [{"$ref" : "#"}, "boolean"],
"default" : {}
},
-
+
"minItems" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxItems" : {
"type" : "integer",
"minimum" : 0
},
-
+
"uniqueItems" : {
"type" : "boolean",
"default" : false
},
-
+
"properties" : {
"type" : "object",
"additionalProperties" : {"$ref" : "#"},
"default" : {}
},
-
+
"patternProperties" : {
"type" : "object",
"additionalProperties" : {"$ref" : "#"},
"default" : {}
},
-
+
"additionalProperties" : {
"type" : [{"$ref" : "#"}, "boolean"],
"default" : {}
},
-
+
"minProperties" : {
"type" : "integer",
"minimum" : 0,
"default" : 0
},
-
+
"maxProperties" : {
"type" : "integer",
"minimum" : 0
},
-
+
"required" : {
"type" : "array",
"items" : {
"type" : "string"
}
},
-
+
"dependencies" : {
"type" : "object",
"additionalProperties" : {
@@ -144,36 +144,36 @@
},
"default" : {}
},
-
+
"id" : {
"type" : "string"
},
-
+
"$ref" : {
"type" : "string"
},
-
+
"$schema" : {
"type" : "string"
},
-
+
"title" : {
"type" : "string"
},
-
+
"description" : {
"type" : "string"
},
-
+
"default" : {
"type" : "any"
}
},
-
+
"dependencies" : {
"exclusiveMinimum" : "minimum",
"exclusiveMaximum" : "maximum"
},
-
+
"default" : {}
-}
\ No newline at end of file
+}
From 4a8331ab83716f7b804c7520db7285da89cf5662 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:52:14 +0200
Subject: [PATCH 0081/1659] draft-04/schema: catch up with "divisibleBy" rename
It is now called "mod".
---
draft-04/schema | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/draft-04/schema b/draft-04/schema
index e1784f43..027c1c1e 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -51,7 +51,7 @@
"default" : false
},
- "divisibleBy" : {
+ "mod" : {
"type" : "number",
"minimum" : 0,
"exclusiveMinimum" : true,
From 689ed03680b8e112c96a490c423cdbba545bdd84 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 11 Jul 2012 19:52:50 +0200
Subject: [PATCH 0082/1659] Re-introduce "format" keyword, with some
differences
* Get rid of the "color" and "style" format attributes.
* Specify the different instance types which can be validated by attributes.
* Specify that if an instance is not of a type which the format attribute can
validate, the validation MUST succeed.
* "regex" is an ECMA 262 regular expression, remove "/perl5" since these
dialects are not compatible (perl5 supports lookbehinds, ECMA 262 doesn't).
* Remove paragraph allowing other format attributes to be specified.
---
draft-04/schema | 12 ++++++++----
draft-zyp-json-schema-04.xml | 34 +++++++++++++++++++++++++++++++++-
2 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index 027c1c1e..be519795 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -69,7 +69,8 @@
},
"pattern" : {
- "type" : "string"
+ "type" : "string",
+ "format": "regex"
},
"items" : {
@@ -146,15 +147,18 @@
},
"id" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"$ref" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"$schema" : {
- "type" : "string"
+ "type" : "string",
+ "format": "uri"
},
"title" : {
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 0656ccfb..fe1d0ca5 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -463,7 +463,39 @@ Content-Type: application/json;
-
+
+
+ This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format
+ attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format
+ SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MUST validate that the
+ instance values conform to a format.
+
+ A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance
+ is not a member of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are
+ listed along with the primitive types they validate.
+
+ The following formats are predefined:
+
+
+ (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
+ This is the recommended form of date/timestamp.
+ (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
+ "date-time" format instead of "date" unless you need to transfer only the date part.
+ (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
+ "date-time" format instead of "time" unless you need to transfer only the time part.
+ (number) This SHOULD be the difference, measured in milliseconds, between the
+ specified time and midnight, 00:00 of January 1, 1970 UTC.
+ (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
+ (string) This SHOULD be a phone number (format MAY follow E.123).
+ (string) This value SHOULD be a URI.
+ (string) This SHOULD be an email address.
+ (string) This SHOULD be an ip version 4 address.
+ (string) This SHOULD be an ip version 6 address.
+ (string) This SHOULD be a host-name.
+
+
+
+
When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
From 0b15bcefad0ee511cb4eabf8cd58e28d33f6b7ed Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Thu, 12 Jul 2012 00:22:07 +0200
Subject: [PATCH 0083/1659] Separate core schema keywords into different
sections
Keywords are split into three types:
* keywords validating only a certain type of instances;
* keywords validating all instance types;
* keywords not participating in instance validation.
---
draft-zyp-json-schema-04.xml | 686 ++++++++++++++++++++---------------
1 file changed, 399 insertions(+), 287 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index fe1d0ca5..6ba842ee 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -305,307 +305,419 @@ Content-Type: application/json;
]]>
-
-
- A JSON Schema object MAY have any of the following optional properties:
-
-
-
-
-
-
-
- This attribute defines what the primitive type or the schema of the instance MUST be in order to validate.
- This attribute can take one of two forms:
-
-
- A string indicating a primitive or simple type. The string MUST be one of the following values:
+ A JSON Schema object MAY have one or more of the properties defined in this section. These properties (called "keywords" in this section) are
+ grouped in subsections according to the type of instance they can validate, while some properties apply to all instance types. Some other keywords
+ do not participate in instance validation and are into a section of their own.
-
- Instance MUST be an object.
- Instance MUST be an array.
- Instance MUST be a string.
- Instance MUST be a number, including floating point numbers.
- Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).
- Instance MUST be the JSON literal "true" or "false".
- Instance MUST be the JSON literal "null". Note that without this type, null values are not allowed.
- Instance MAY be of any type, including null.
-
-
-
-
- An array of one or more simple or schema types.
- The instance value is valid if it is of the same type as one of the simple types, or valid by one of the schemas, in the array.
-
-
-
- If this attribute is not specified, then all value types are accepted.
-
-
-
- For example, a schema that defines if an instance can be a string or a number would be:
-
+
+
+
+
+ The value of this keyword is a number which defines the minimum value of the instance.
+
+
+
+
+
+ The value of this keyword is a number which defines the maximum value of the instance.
+
+
+
+
+
+ This keyword MUST be paired with "minimum". Its value is a boolean. If false (the default), then the instance may be greater than or equal to "minimum". If true, then the instance must be strictly greater than "minimum".
+
+
+
+
+
+ This keyword MUST be paired with "maximum". Its value is a boolean. If false (the default), then the instance may be less than or equal to "maximum". If true, then the instance must be strictly lower than "maximum".
+
+
+
+
+
+ This keyword's value is a number which must divide instance with no remainder (that is, the result of the division must be an integer.) The value of this keyword MUST NOT be 0.
+
+
+
+
+
+
+
+
+
+ The value of this keyword is an ECMA 262 regular expression that the instance MUST match in order to be valid.
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum length of the instance.
+
+
+
+
+
+ The value of this keyword is an integer which defines the maximum length of the instance.
+
+
+
+
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum number of elements in the instance.
+
+
+
+
+
+ The value of this keyword is an integer which defines the minimum number of elements in the instance.
+
+
+
+
+
+ This keyword defines a set of allowed items in the instance. The value of this keyword MUST be a schema or an array of schemas:
+
+ if it is a schema, then all items in the instance MUST be valid against this schema;
+ if it is an array of schemas, then the item at a given position in the instance MUST be valid according to the corresponding schema at
+ the same position in the keyword value. This is called tuple typing. Constraints on items in the instance which have no corresponding
+ schema in the keyword value are defined by "additionalItems".
+
+
+
+
+
+
+
+ This keyword specifies how to handle items in the instance which are is not explicitly defined by "items". Its value
+ MUST be a schema or a boolean. Boolean value true is equivalent to an empty schema.
+
+ If "items" is present and its value is a schema, "additionalItems" is ignored.
+
+ If "items" is defined and is an array of n elements, then:
+
+ if "additionalItems" is false, then the instance is valid with regards to this keyword if and only if it has at most n elements;
+ if "additionalItems" is a schema, then all instance elements of index n or greater (assuming array indexes start at 0) MUST be valid
+ against this schema.
+
+
+
+ If "items" is not defined, then:
+
+ if "additionalItems" is false, then the instance is invalid;
+ if "additionalItems" is a schema, then all instance elements MUST be valid against this schema.
+
+
+
+ The default value is an empty schema, which allows any value for additional items.
+
+
+
+
+
+ This keyword indicates that all items in the instance MUST be unique (contains no two identical values).
+
+
+ Two JSON instances are consider equal if they are both of the same type and:
+
+ are null; or
+ are booleans/numbers/strings and have the same value; or
+ are arrays, contain the same number of items, and each item in the array is equal to the item at the corresponding index in the other
+ array; or
+ are objects, contain the same set of property names, and each property in the object is equal to the corresponding property in the other
+ object.
+
+
+
+
+
+
+
+
+
+
+
+ The value of this keyword is a positive integer which defines the minimum number of properties the instance must have.
+
+
+
+
+
+ The value of this keyword is a positive integer which defines the maximum number of properties the instance must have.
+
+
+
+
+
+ The value of this keyword is an object where:
+
+ property name match equivalent property names in the instance, if any, and
+ property values are schemas.
+
+
+
+ If the instance has a property name which is equal to a property name defined in this keyword, then the property value MUST be valid against the
+ corresponding schema.
+
+ Objects are unordered, therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
+
+
+
+
+
+ The value of this keyword is an object where:
+
+ property names are ECMA 262 regular expressions, and
+ property values are schemas.
+
+
+
+ For each property name of the instance, if it is matched by one or more regular expressions defined by this keyword, then the matching value MUST
+ be valid against all such schemas.
+
+ Note that regular expressions are not anchored.
+
+
+
+
+
+ This keyword defines how to handle an instance's properties which could not be matched by either "properties" or
+ "patternProperties" (here after referred to as "additional properties"). Its value MUST be either a schema
+ or a boolean. Boolean value true is equivalent to an empty schema.
+
+ If the value of this keyword is false, then the instance is valid if and only if there are no additional properties in the instance.
+
+ If the value of this keyword is a schema, then all additional properties MUST be valid against this schema.
+
+ The default value is an empty schema, which allows any value for additional properties.
+
+
+
+
+
+ The value of this keyword is an array of strings which defines all the property names that must exist on the instance for it to be valid.
+
+
+
+
+
+ The value of this keyword is an object. Property names of this object match equivalent property names in the instance, if any. Property values are either of:
+
+ a string or an array of strings; in this case, the instance is valid if and only if the instance has the corresponding property name(s);
+ a schema; in this case, the instance is valid if and only if the value of the corresponding property name is valid against this schema.
+
+
+
+
+
+
+
+ It should be noted that validation by "properties" and "patternProperties" are not exclusive: if a property name in an instance is matched by
+ both a property name in "properties" and one or more regular expressions in "patternProperties", then the corresponding value MUST validate against
+ all of these schemas.
+
+
+
+
+
+
+
+
+
+ This keyword defines what the primitive type or the schema of the instance MUST be in order to validate. This attribute can take one of two
+ forms:
+
+ A string indicating a primitive or simple type. The string MUST be one of the following values:
+
+ Instance MUST be an object.
+ Instance MUST be an array.
+ Instance MUST be a string.
+ Instance MUST be a number, including floating point numbers.
+ Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).
+ Instance MUST be a JSON boolean (true or false).
+ Instance MUST be the JSON literal null. Note that without this type, null values are not allowed.
+ Instance MAY be of any type, including null.
+
+
+ An array of one or more simple types or schemas. The instance value is valid if it is of the same type as one of
+ the simple types, or valid by one of the schemas.
+
+
+
+ If this attribute is not specified, then all value types are accepted.
+
+
+ For example, a schema that defines if an instance can be a string or a number would be:
+
-
-
-
-
-
- This attribute is an object with properties that specify the schemas for the properties of the instance object.
- In this attribute's object, each property value MUST be a schema.
- When the instance value is an object, the value of the instance's properties MUST be valid according to the schemas with the same property names specified in this attribute.
- Objects are unordered, so therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
-
-
-
-
-
- This attribute is an object that defines the schema for a set of property names of an object instance.
- The name of each property of this attribute's object is a regular expression pattern in the ECMA 262/Perl 5 format, while the value is a schema.
- If the pattern matches the name of a property on the instance object, the value of the instance's property MUST be valid against the pattern name's schema value.
-
-
-
-
- This attribute specifies how any instance property that is not explicitly defined by either the "properties" or "patternProperties" attributes (hereafter referred to as "additional properties") is handled. If specified, the value MUST be a schema or a boolean.
- If a schema is provided, then all additional properties MUST be valid according to the schema.
- If false is provided, then no additional properties are allowed.
- The default value is an empty schema, which allows any value for additional properties.
-
-
-
- This attribute provides the allowed items in an array instance. If specified, this attribute MUST be a schema or an array of schemas.
- When this attribute value is a schema and the instance value is an array, then all the items in the array MUST be valid according to the schema.
- When this attribute value is an array of schemas and the instance value is an array, each position in the instance array MUST be valid according to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the "additionalItems" attribute the same way as "additionalProperties" for objects is.
-
-
-
- This attribute specifies how any item in the array instance that is not explicitly defined by "items" (hereafter referred to as "additional items") is handled. If specified, the value MUST be a schema or a boolean.
- If a schema is provided:
-
- If the "items" attribute is unspecified, then all items in the array instance must be valid against this schema.
- If the "items" attribute is a schema, then this attribute is ignored.
- If the "items" attribute is an array (during tuple typing), then any additional items MUST be valid against this schema.
-
-
- If false is provided, then any additional items in the array are not allowed.
- The default value is an empty schema, which allows any value for additional items.
-
-
-
- This attribute is an array of strings that defines all the property names that must exist on the object instance.
-
-
-
- This attribute is an object that specifies the requirements of a property on an object instance. If an object instance has a property with the same name as a property in this attribute's object, then the instance must be valid against the attribute's property value (hereafter referred to as the "dependency value").
-
- The dependency value can take one of two forms:
-
-
-
- If the dependency value is a string, then the instance object MUST have a property with the same name as the dependency value.
- If the dependency value is an array of strings, then the instance object MUST have a property with the same name as each string in the dependency value's array.
-
-
- If the dependency value is a schema, then the instance object MUST be valid against the schema.
-
-
-
-
-
-
- This attribute defines the minimum value of the instance property when the type of the instance value is a number.
-
-
-
- This attribute defines the maximum value of the instance property when the type of the instance value is a number.
-
-
-
- This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "minimum" attribute. This is false by default, meaning the instance value can be greater then or equal to the minimum value.
-
-
-
- This attribute indicates if the value of the instance (if the instance is a number) can not equal the number defined by the "maximum" attribute. This is false by default, meaning the instance value can be less then or equal to the maximum value.
-
-
-
- This attribute defines the minimum number of values in an array when the array is the instance value.
-
-
-
- This attribute defines the maximum number of values in an array when the array is the instance value.
-
-
-
- This attribute defines the minimum number of properties required on an object instance.
-
-
-
- This attribute defines the maximum number of properties the object instance can have.
-
-
-
- This attribute indicates that all items in an array instance MUST be unique (contains no two identical values).
-
- Two instance are consider equal if they are both of the same type and:
-
-
- are null; or
- are booleans/numbers/strings and have the same value; or
- are arrays, contains the same number of items, and each item in the array is equal to the item at the corresponding index in the other array; or
- are objects, contains the same property names, and each property in the object is equal to the corresponding property in the other object.
-
-
-
+]]>
+
+
-
- This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format
- attribute MAY be one of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format
- SHOULD only be used to give meaning to primitive types (string, integer, number, or boolean). Validators MUST validate that the
- instance values conform to a format.
-
- A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance
- is not a member of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are
- listed along with the primitive types they validate.
-
- The following formats are predefined:
-
-
- (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
- This is the recommended form of date/timestamp.
- (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
- "date-time" format instead of "date" unless you need to transfer only the date part.
- (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
- "date-time" format instead of "time" unless you need to transfer only the time part.
- (number) This SHOULD be the difference, measured in milliseconds, between the
- specified time and midnight, 00:00 of January 1, 1970 UTC.
- (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
- (string) This SHOULD be a phone number (format MAY follow E.123).
- (string) This value SHOULD be a URI.
- (string) This SHOULD be an email address.
- (string) This SHOULD be an ip version 4 address.
- (string) This SHOULD be an ip version 6 address.
- (string) This SHOULD be a host-name.
-
-
-
-
-
- When the instance value is a string, this provides a regular expression that a string instance MUST match in order to be valid. Regular expressions SHOULD follow the regular expression specification from ECMA 262/Perl 5
-
-
-
- When the instance value is a string, this defines the minimum length of the string.
-
-
-
- When the instance value is a string, this defines the maximum length of the string.
-
-
-
- This provides an enumeration of all possible values that are valid for the instance property. This MUST be an array, and each item in the array represents a possible value for the instance value. If this attribute is defined, the instance value MUST be one of the values in the array in order for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
-
-
-
- This attribute defines the default value of the instance when the instance is undefined.
-
-
-
- This attribute is a string that provides a short description of the instance property.
-
-
-
- This attribute is a string that provides a full description of the of purpose the instance property.
-
-
-
- This attribute defines what value the number instance must be divisible by with no remainder (the result of the division must be an integer.) The value of this attribute SHOULD NOT be 0.
-
-
-
- This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, then this instance is not valid.
-
-
-
- The value of this property MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional attributes, constrain existing attributes, or add other constraints.
-
- Conceptually, the behavior of extends can be seen as validating an
- instance against all constraints in the extending schema as well as
- the extended schema(s). More optimized implementations that merge
- schemas are possible, but are not required. Some examples of using "extends":
-
-
-
+
+
+
+
+ This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the
+ instance matches any type or schema in the array, then this instance is not valid.
+
+
+
+
+
+
+
+ This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format attribute MAY be one
+ of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to
+ primitive types (string, integer, number, or boolean). Validators MUST validate that instances conform to a format.
+
+ A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance is not a member
+ of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are listed along with the primitive
+ types they validate.
+
+ The following formats are predefined:
+
+ (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
+ This is the recommended form of date/timestamp.
+ (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
+ "date-time" format instead of "date" unless you need to transfer only the date part.
+ (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
+ "date-time" format instead of "time" unless you need to transfer only the time part.
+ (number) This SHOULD be the difference, measured in milliseconds, between the
+ specified time and midnight, 00:00 of January 1, 1970 UTC.
+ (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
+ (string) This SHOULD be a phone number (format MAY follow E.123).
+ (string) This value SHOULD be a URI.
+ (string) This SHOULD be an email address.
+ (string) This SHOULD be an ip version 4 address.
+ (string) This SHOULD be an ip version 6 address.
+ (string) This SHOULD be a host-name.
+
+
+
+
+
+
+
+ The value of this keyword is an array which provides an enumeration of JSON instances. The instance value MUST be one of the values in the array in order
+ for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+
+ The array MUST have at least one element. Elements in the array MUST be unique.
+
+
+
+
+
+ The value of this keyword MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance
+ rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an
+ array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional
+ attributes, constrain existing attributes, or add other constraints.
+
+ Conceptually, the behavior of extends can be seen as validating an instance against all constraints in the extending schema as well as the
+ extended schema(s). More optimized implementations that merge schemas are possible, but are not required. Some examples of using "extends":
+
+
+
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
-
-
- This attribute defines the current URI of this schema (this attribute is
- effectively a "self" link). This URI MAY be relative or absolute. If
- the URI is relative it is resolved against the current URI of the parent
- schema it is contained in. If this schema is not contained in any
- parent schema, the current URI of the parent schema is held to be the
- URI under which this schema was addressed. If id is missing, the current URI of a schema is
- defined to be that of the parent schema. The current URI of the schema
- is also used to construct relative references such as for $ref.
-
-
-
-
-
- This attribute defines a URI of a schema that contains the full representation of this schema.
- When a validator encounters this attribute, it SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance.
- This URI MAY be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
-
-
-
-
-
- This attribute defines a URI of a JSON Schema that is the schema of the current schema.
- When this attribute is defined, a validator SHOULD use the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
-
-
-
- A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the appropriate validation features and behavior.
- Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to prevent conflicts with future JSON Schema specification changes.
-
-
+
+
+
+
+
+
+
+
+
+
+ The following keywords do not play any role in instance validation "per se", however three of them ("$ref", "id" and "$schema") play an important role in the validation process.
+
+
+
+ This keyword defines the default value of the instance when the instance is undefined.
+
+ Note that it is NOT required that the value of the instance matches the enclosing schema.
+
+
+
+
+
+ This keyword is a string that provides a short description of the instance property.
+
+
+
+
+
+ This keyword is a string that provides a full description of the of purpose the instance property.
+
+
+
+
+
+
+ This keyword defines the current URI of this schema (this attribute is effectively a "self" link). This URI MAY be relative or absolute. If the
+ URI is relative it is resolved against the current URI of the parent schema it is contained in. If this schema is not contained in any parent
+ schema, the current URI of the parent schema is held to be the URI under which this schema was addressed. If id is missing, the current URI of a
+ schema is defined to be that of the parent schema. The current URI of the schema is also used to construct relative references such as for $ref.
+
+
+
+
+
+ This attribute defines a URI of a schema that contains the full representation of this schema. When a validator encounters this attribute, it
+ SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance. This URI MAY
+ be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+
+
+
+
+
+ This attribute defines a URI of a JSON Schema that is the schema of the current schema. When this attribute is defined, a validator SHOULD use
+ the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+
+ A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the
+ appropriate validation features and behavior. Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to
+ prevent conflicts with future JSON Schema specification changes.
+
+
+
+
+
From 33ef30fbdd14083f9664a605e215cc4aa14fc8f9 Mon Sep 17 00:00:00 2001
From: Nick Lombard
Date: Mon, 20 Aug 2012 14:42:57 +0300
Subject: [PATCH 0084/1659] Update README.md
Modified Readme introduction to new collaborated effort.
---
README.md | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/README.md b/README.md
index 4de01244..0a6ff1be 100644
--- a/README.md
+++ b/README.md
@@ -1,5 +1,7 @@
-JSON Schema is a repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema (not the only JavaScript implementation of JSON Schema, JSV is another excellent JavaScript validator).
+## New Home JSON Schema repository
-Code is licensed under the AFL or BSD license as part of the Persevere
-project which is administered under the Dojo foundation,
-and all contributions require a Dojo CLA.
\ No newline at end of file
+Is the repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema (not the only JavaScript implementation of JSON Schema, JSV is another excellent JavaScript validator).
+
+Code is licensed under the AFL or BSD license.
+
+Contributors welcome!
\ No newline at end of file
From f56cecb21b176755ad91f58c1ccfa55e5fb93186 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Thu, 30 Aug 2012 13:12:35 -0600
Subject: [PATCH 0085/1659] Add CNAME, I think this is needed to have
json-schema.org point to it.
---
CNAME | 1 +
1 file changed, 1 insertion(+)
create mode 100644 CNAME
diff --git a/CNAME b/CNAME
new file mode 100644
index 00000000..f6ca064a
--- /dev/null
+++ b/CNAME
@@ -0,0 +1 @@
+json-schema.org
\ No newline at end of file
From b5621d702637ffb9668c89aba2e22ee5c188015b Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Fri, 31 Aug 2012 12:59:49 +0200
Subject: [PATCH 0086/1659] draft-zyp-json-schema-04.xml: remove trailing
whitespaces
---
draft-zyp-json-schema-04.xml | 288 +++++++++++++++++------------------
1 file changed, 144 insertions(+), 144 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 6ba842ee..3a1e2acf 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -23,7 +23,7 @@
A JSON Media Type for Describing the Structure and Meaning of JSON Documents
-
+
SitePen (USA)
@@ -36,7 +36,7 @@
kris@sitepen.com
-
+
@@ -47,7 +47,7 @@
gary.court@gmail.com
-
+
Internet Engineering Task ForceJSON
@@ -57,48 +57,48 @@
NotationHyper SchemaHypermedia
-
+
- JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
- a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
+ JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
+ a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
-
+
- JSON (JavaScript Object Notation) Schema is a JSON media type for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
-
+
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+
+ 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.
-
+
- The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
- "array", "number", "string", "boolean", "true", "false", and "null" in this
+ The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
+ "array", "number", "string", "boolean", "true", "false", and "null" in this
document are to be interpreted as defined in RFC 4627.
-
+
This specification also uses the following defined terms:
-
+
A JSON Schema object.Equivalent to "JSON value" as defined in RFC 4627.
@@ -108,35 +108,35 @@
-
+
- JSON Schema defines the media type "application/schema+json" for
- describing the structure of JSON text. JSON Schemas are also written in JSON and includes facilities
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of JSON text. JSON Schemas are also written in JSON and includes facilities
for describing the structure of JSON in terms of
allowable values, descriptions, and interpreting relations with other resources.
- This document is organized into several separate definitions. The first
- definition is the core schema specification. This definition is primary
+ This document is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
concerned with describing a JSON structure and specifying valid elements
in the structure. The second definition is the Hyper Schema specification
which is intended to define elements in a structure that can be interpreted as
hyperlinks.
- Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
JSON values. This allows user agents to be able to successfully navigate
documents containing JSON based on their schemas.
- Cumulatively JSON Schema acts as meta-JSON that can be used to define the
+ Cumulatively JSON Schema acts as meta-JSON that can be used to define the
required type and constraints on JSON values, as well as define the meaning
of the JSON values for the purpose of describing a resource and determining
- hyperlinks within the representation.
+ hyperlinks within the representation.
An example JSON Schema that describes products might look like:
-
- This schema defines the properties of the instance,
+ This schema defines the properties of the instance,
the required properties (id, name, and price), as well as an optional
property (tags). This also defines the link relations of the instance.
-
+
The JSON Schema media type does not attempt to dictate the structure of JSON
@@ -195,7 +195,7 @@
This specification is protocol agnostic.
The underlying protocol (such as HTTP) should sufficiently define the
semantics of the client-server interface, the retrieval of resource
- representations linked to by JSON representations, and modification of
+ representations linked to by JSON representations, and modification of
those resources. The goal of this
format is to sufficiently describe JSON structures such that one can
utilize existing information available in existing JSON
@@ -204,35 +204,35 @@
-
+
JSON values are correlated to their schema by the "describedby"
relation, where the schema is the target of the relation.
JSON values MUST be of the "application/json" media type or
- any other subtype. Consequently, dictating how a JSON value should
+ any other subtype. Consequently, dictating how a JSON value should
specify the relation to the schema is beyond the normative scope
of this document since this document specifically defines the JSON
Schema media type, and no other. It is RECOMMNENDED that JSON values
specify their schema so that user agents can interpret the instance
and retain the self-descriptive characteristics. This avoides the need for out-of-band information about
instance data. Two approaches are recommended for declaring the
- relation to the schema that describes the meaning of a JSON instance's (or collection
+ relation to the schema that describes the meaning of a JSON instance's (or collection
of instances) structure. A MIME type parameter named
"profile" or a relation of "describedby" (which could be specified by a Link header) may be used:
-
+
-
-
+
or if the content is being transferred by a protocol (such as HTTP) that
provides headers, a Link header can be used:
-
+
; rel="describedby"
]]>
-
- Instances MAY specify multiple schemas, to indicate all the schemas that
- are applicable to the data, and the data SHOULD be valid by all the schemas.
- The instance data MAY have multiple schemas
- that it is described by (the instance data SHOULD be valid for those schemas).
- Or if the document is a collection of instances, the collection MAY contain
- instances from different schemas. The mechanism for referencing a schema is
- determined by the media type of the instance (if it provides a method for
+
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data, and the data SHOULD be valid by all the schemas.
+ The instance data MAY have multiple schemas
+ that it is described by (the instance data SHOULD be valid for those schemas).
+ Or if the document is a collection of instances, the collection MAY contain
+ instances from different schemas. The mechanism for referencing a schema is
+ determined by the media type of the instance (if it provides a method for
referencing schemas).
-
+
- JSON Schemas can themselves be described using JSON Schemas.
+ JSON Schemas can themselves be described using JSON Schemas.
A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema for the latest version or
- http://json-schema.org/draft-04/schema for the draft-04 version. The hyper schema
- self-description can be found at http://json-schema.org/hyper-schema
+ be found at http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-04/schema for the draft-04 version. The hyper schema
+ self-description can be found at http://json-schema.org/hyper-schema
or http://json-schema.org/draft-04/hyper-schema. All schemas
used within a protocol with a media type specified SHOULD include a MIME parameter that refers to the self-descriptive
hyper schema or another schema that extends this hyper schema:
-
+
-
@@ -273,15 +273,15 @@ Content-Type: application/json;
-
+
- A JSON Schema is a JSON object that defines various attributes
+ A JSON Schema is a JSON object that defines various attributes
(including usage and valid values) of a JSON value. JSON
Schema has recursive capabilities; there are a number of elements
in the structure that allow for nested JSON Schemas.
-
+
An example JSON Schema could look like:
@@ -719,7 +719,7 @@ Content-Type: application/json;
-
+
The following attributes are specified in addition to those
@@ -731,30 +731,30 @@ Content-Type: application/json;
essentially describes plain JSON (no constraints on the structures).
Addition of attributes provides additive information for user agents.
-
+
- The value of the links property MUST be an array, where each item
+ The value of the links property MUST be an array, where each item
in the array is a link description object which describes the link
relations of the instances.
-
+
-
+
- A link description object is used to describe link relations. In
- the context of a schema, it defines the link relations of the
+ A link description object is used to describe link relations. In
+ the context of a schema, it defines the link relations of the
instances of the schema, and can be parameterized by the instance
- values. The link description format can be used without JSON Schema,
+ values. The link description format can be used without JSON Schema,
and use of this format can
be declared by referencing the normative link description
- schema as the the schema for the data structure that uses the
- links. The URI of the normative link description schema is:
+ schema as the the schema for the data structure that uses the
+ links. The URI of the normative link description schema is:
http://json-schema.org/links (latest version) or
http://json-schema.org/draft-04/links (draft-04 version).
-
+
The value of the "href" link description property
@@ -762,19 +762,19 @@ Content-Type: application/json;
of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
and MAY be a relative URI. The base URI to be used for relative resolution
SHOULD be the URI used to retrieve the instance object (not the schema)
- when used within a schema. Also, when links are used within a schema, the URI
- SHOULD be parametrized by the property values of the instance
+ when used within a schema. Also, when links are used within a schema, the URI
+ SHOULD be parametrized by the property values of the instance
object, if property values exist for the corresponding variables
in the template (otherwise they MAY be provided from alternate sources, like user input).
-
+
Instance property values SHOULD be substituted into the URIs where
matching braces ('{', '}') are found surrounding zero or more characters,
creating an expanded URI. Instance property value substitutions are resolved
by using the text between the braces to denote the property name
- from the instance to get the value to substitute.
-
+ from the instance to get the value to substitute.
+
For example, if an href value is defined:
@@ -784,7 +784,7 @@ http://somesite.com/{id}
Then it would be resolved by replace the value of the "id" property value from the instance object.
-
+
If the value of the "id" property was "45", the expanded URI would be:
@@ -793,23 +793,23 @@ http://somesite.com/45
]]>
-
- If matching braces are found with the string "@" (no quotes) between the braces, then the
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the
actual instance value SHOULD be used to replace the braces, rather than a property value.
- This should only be used in situations where the instance is a scalar (string,
+ This should only be used in situations where the instance is a scalar (string,
boolean, or number), and not for objects or arrays.
-
+
- The value of the "rel" property indicates the name of the
+ The value of the "rel" property indicates the name of the
relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-
+
Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
-
+
If the relation value is "self", when this property is encountered in
@@ -817,15 +817,15 @@ http://somesite.com/45
treated as a full representation of the target resource identified by
the specified URI.
-
+
This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
-
+
This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
+
This relation indicates that the target of the link
SHOULD be treated as the root or the body of the representation for the
@@ -835,7 +835,7 @@ http://somesite.com/45
-
+
The following relations are applicable for schemas (the schema as the "from" resource in the relation):
@@ -844,7 +844,7 @@ http://somesite.com/45
This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
-
+
For example, if a schema is defined:
@@ -865,7 +865,7 @@ http://somesite.com/45
]]>
-
+
And if a collection of instance resource's JSON representation was retrieved:
@@ -889,41 +889,41 @@ GET /Resource/
The "children" collection would be located at "/Resource/?upId=thing".
-
+
This property value is a string that defines the templating language used in the "href" attribute. If no templating language is defined, then the default Link Description Object templating langauge is used.
-
+
This property value is a schema that defines the expected structure of the JSON representation of the target of the link.
-
+
- The following properties also apply to link definition objects, and
- provide functionality analogous to HTML forms, in providing a
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a
means for submitting extra (often user supplied) information to send to a server.
-
+
- This attribute defines which method can be used to access the target resource.
- In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
- such as "PUT" and "DELETE" have semantics that are clearly implied by
- accessed resources, and do not need to be defined here).
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+ such as "PUT" and "DELETE" have semantics that are clearly implied by
+ accessed resources, and do not need to be defined here).
This defaults to "GET".
-
+
If present, this property indicates a query media type format that the server
- supports for querying or posting to the collection of instances at the target
- resource. The query can be
+ supports for querying or posting to the collection of instances at the target
+ resource. The query can be
suffixed to the target URI to query the collection with
property-based constraints on the resources that SHOULD be returned from
the server or used to post data to the resource (depending on the method).
-
+
For example, with the following schema:
@@ -944,7 +944,7 @@ GET /Resource/
This indicates that the client can query the server for instances that have a specific name.
-
+
For example:
@@ -954,23 +954,23 @@ GET /Resource/
- If no enctype or method is specified, only the single URI specified by
- the href property is defined. If the method is POST, "application/json" is
+ If no enctype or method is specified, only the single URI specified by
+ the href property is defined. If the method is POST, "application/json" is
the default media type.
-
+
This attribute contains a schema which defines the acceptable structure of the submitted
- request (for a GET request, this schema would define the properties for the query string
+ request (for a GET request, this schema would define the properties for the query string
and for a POST request, this would define the body).
-
+
This property indicates the fragment resolution protocol to use for
@@ -980,62 +980,62 @@ GET /Resource/
protocol is "json-pointer", which is defined below. Other fragment
resolution protocols MAY be used, but are not defined in this document.
-
+
The fragment identifier is based on RFC 3986, Sec 5, and defines the
mechanism for resolving references to entities within a document.
-
+
The "json-pointer" fragment resolution protocol uses a JSON Pointer to resolve fragment identifiers in URIs within instance representations.
-
+
-
+
This attribute indicates that the instance value SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
-
+
If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
-
+
- This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
- The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
+ This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+ The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
and is relative to the instance's URI.
-
+
- When multiple schemas have been referenced for an instance, the user agent
- can determine if this schema is applicable for a particular instance by
+ When multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance by
determining if the URI of the instance begins with the the value of the "pathStart"
- attribute. If the URI of the instance does not start with this URI,
- or if another schema specifies a starting URI that is longer and also matches the
- instance, this schema SHOULD NOT be applied to the instance. Any schema
- that does not have a pathStart attribute SHOULD be considered applicable
+ attribute. If the URI of the instance does not start with this URI,
+ or if another schema specifies a starting URI that is longer and also matches the
+ instance, this schema SHOULD NOT be applied to the instance. Any schema
+ that does not have a pathStart attribute SHOULD be considered applicable
to all the instances for which it is referenced.
-
+
This attribute defines the media type of the instance representations that this schema is defining.
-
+
- This specification is a sub-type of the JSON format, and
- consequently the security considerations are generally the same as RFC 4627.
+ This specification is a sub-type of the JSON format, and
+ consequently the security considerations are generally the same as RFC 4627.
However, an additional issue is that when link relation of "self"
- is used to denote a full representation of an object, the user agent
+ is used to denote a full representation of an object, the user agent
SHOULD NOT consider the representation to be the authoritative representation
of the resource denoted by the target URI if the target URI is not
- equivalent to or a sub-path of the the URI used to request the resource
+ equivalent to or a sub-path of the the URI used to request the resource
representation which contains the target URI with the "self" link.
-
+
For example, if a hyper schema was defined:
@@ -1049,7 +1049,7 @@ GET /Resource/
]]>
-
+
And a resource was requested from somesite.com:
@@ -1086,22 +1086,22 @@ Content-Type: application/json; profile=/schema-for-this-data
-
+
The proposed MIME media type for JSON Schema is "application/schema+json".Type name: applicationSubtype name: schema+jsonRequired parameters: profile
- The value of the profile parameter SHOULD be a URI (relative or absolute) that
- refers to the schema used to define the structure of this structure (the
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
meta-schema). Normally the value would be http://json-schema.org/draft-04/hyper-schema,
but it is allowable to use other schemas that extend the hyper schema's meta-
schema.
Optional parameters: prettyThe value of the pretty parameter MAY be true or false to indicate if additional whitespace has been included to make the JSON representation easier to read.
-
+
This registry is maintained by IANA per RFC 4287 and this specification adds
@@ -1113,7 +1113,7 @@ Content-Type: application/json; profile=/schema-for-this-data
-
+
@@ -1164,7 +1164,7 @@ Content-Type: application/json; profile=/schema-for-this-data
Improved wording of many sections.
-
+
Added example and verbiage to "extends" attribute.
@@ -1188,7 +1188,7 @@ Content-Type: application/json; profile=/schema-for-this-data
Added "$ref" and "$schema" attributes.
-
+
Replaced "maxDecimal" attribute with "divisibleBy" attribute.
@@ -1198,13 +1198,13 @@ Content-Type: application/json; profile=/schema-for-this-data
Added "targetSchema" attribute to link description object.
-
+
Fixed category and updates from template.
-
+
Initial draft.
From 1239aa1ba8b2e7f4b0663da8949c8c95732b71c5 Mon Sep 17 00:00:00 2001
From: nickl-
Date: Fri, 31 Aug 2012 13:28:29 +0200
Subject: [PATCH 0087/1659] CNAME should be on gh-pages see #3
---
CNAME | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 CNAME
diff --git a/CNAME b/CNAME
deleted file mode 100644
index f6ca064a..00000000
--- a/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-json-schema.org
\ No newline at end of file
From d24139d6c732d7b2fcaf84e453264769525dfe14 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 2 Sep 2012 21:17:07 +0200
Subject: [PATCH 0088/1659] draft-zyp-json-schema-04.xml: unify style
* Tabs are 4 in length, expanded to spaces.
* 100 chars maximum per line.
---
draft-zyp-json-schema-04.xml | 1782 ++++++++++++++++++----------------
1 file changed, 959 insertions(+), 823 deletions(-)
diff --git a/draft-zyp-json-schema-04.xml b/draft-zyp-json-schema-04.xml
index 3a1e2acf..ec7ebe14 100644
--- a/draft-zyp-json-schema-04.xml
+++ b/draft-zyp-json-schema-04.xml
@@ -21,324 +21,338 @@
-
- A JSON Media Type for Describing the Structure and Meaning of JSON Documents
-
-
- SitePen (USA)
-
-
- 530 Lytton Avenue
- Palo Alto, CA 94301
- USA
-
- +1 650 968 8787
- kris@sitepen.com
-
-
-
-
-
-
-
- Calgary, AB
- Canada
-
- gary.court@gmail.com
-
-
-
-
- Internet Engineering Task Force
- JSON
- Schema
- JavaScript
- Object
- Notation
- Hyper Schema
- Hypermedia
-
-
-
- JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json",
- a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
-
-
-
- JSON (JavaScript Object Notation) Schema is a JSON media type for defining
- the structure of JSON data. JSON Schema provides a contract for what JSON
- data is required for a given application and how to interact with it. JSON
- Schema is intended to define validation, documentation, hyperlink
- navigation, and interaction control of JSON data.
-
-
-
-
-
-
-
- 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.
-
-
-
- The terms "JSON", "JSON text", "JSON value", "member", "element", "object",
- "array", "number", "string", "boolean", "true", "false", and "null" in this
- document are to be interpreted as defined in RFC 4627.
-
-
-
- This specification also uses the following defined terms:
-
-
- A JSON Schema object.
- Equivalent to "JSON value" as defined in RFC 4627.
- Equivalent to "member" as defined in RFC 4627.
- Equivalent to "element" as defined in RFC 4627.
- A property of a JSON Schema object.
-
-
-
-
-
-
- JSON Schema defines the media type "application/schema+json" for
- describing the structure of JSON text. JSON Schemas are also written in JSON and includes facilities
- for describing the structure of JSON in terms of
- allowable values, descriptions, and interpreting relations with other resources.
-
-
- This document is organized into several separate definitions. The first
- definition is the core schema specification. This definition is primary
- concerned with describing a JSON structure and specifying valid elements
- in the structure. The second definition is the Hyper Schema specification
- which is intended to define elements in a structure that can be interpreted as
- hyperlinks.
- Hyper Schema builds on JSON Schema to describe the hyperlink structure of
- JSON values. This allows user agents to be able to successfully navigate
- documents containing JSON based on their schemas.
-
-
- Cumulatively JSON Schema acts as meta-JSON that can be used to define the
- required type and constraints on JSON values, as well as define the meaning
- of the JSON values for the purpose of describing a resource and determining
- hyperlinks within the representation.
-
-
- An example JSON Schema that describes products might look like:
-
+
+ A JSON Media Type for Describing the Structure and
+ Meaning of JSON Documents
+
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ JavaScript
+ Object
+ Notation
+ Hyper Schema
+ Hypermedia
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type
+ "application/schema+json", a JSON based format for defining the structure of JSON
+ data. JSON Schema provides a contract for what JSON data is required for a given
+ application and how to interact with it. JSON Schema is intended to define
+ validation, documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining the
+ structure of JSON data. JSON Schema provides a contract for what JSON data is
+ required for a given application and how to interact with it. JSON Schema is
+ intended to define validation, documentation, hyperlink navigation, and interaction
+ control of JSON data.
+
+
+
+
+
+
+
+ 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.
+
+
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array",
+ "number", "string", "boolean", "true", "false", and "null" in this document are to
+ be interpreted as defined in RFC 4627.
+
+
+
+ This specification also uses the following defined terms:
+
+
+ A JSON Schema object.
+ Equivalent to "JSON value" as defined in RFC 4627.
+ Equivalent to "member" as defined in RFC 4627.
+ Equivalent to "element" as defined in RFC 4627.
+ A property of a JSON Schema object.
+
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json" for describing the
+ structure of JSON text. JSON Schemas are also written in JSON and includes
+ facilities for describing the structure of JSON in terms of allowable values,
+ descriptions, and interpreting relations with other resources.
+
+
+ This document is organized into several separate definitions. The first definition
+ is the core schema specification. This definition is primary concerned with
+ describing a JSON structure and specifying valid elements in the structure. The
+ second definition is the Hyper Schema specification which is intended to define
+ elements in a structure that can be interpreted as hyperlinks. Hyper Schema builds
+ on JSON Schema to describe the hyperlink structure of JSON values. This allows user
+ agents to be able to successfully navigate documents containing JSON based on their
+ schemas.
+
+
+ Cumulatively JSON Schema acts as meta-JSON that can be used to define the required
+ type and constraints on JSON values, as well as define the meaning of the JSON
+ values for the purpose of describing a resource and determining hyperlinks within
+ the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
-
-
- This schema defines the properties of the instance,
- the required properties (id, name, and price), as well as an optional
- property (tags). This also defines the link relations of the instance.
-
-
-
-
-
- The JSON Schema media type does not attempt to dictate the structure of JSON
- values that contain data, but rather provides a separate format
- for flexibly communicating how a JSON value should be
- interpreted and validated, such that user agents can properly understand
- acceptable structures and extrapolate hyperlink information
- from the JSON. It is acknowledged that JSON values come
- in a variety of structures, and JSON is unique in that the structure
- of stored data structures often prescribes a non-ambiguous definite
- JSON representation. Attempting to force a specific structure is generally
- not viable, and therefore JSON Schema allows for a great flexibility
- in the structure of the JSON data that it describes.
-
-
- This specification is protocol agnostic.
- The underlying protocol (such as HTTP) should sufficiently define the
- semantics of the client-server interface, the retrieval of resource
- representations linked to by JSON representations, and modification of
- those resources. The goal of this
- format is to sufficiently describe JSON structures such that one can
- utilize existing information available in existing JSON
- representations from a large variety of services that leverage a representational state transfer
- architecture using existing protocols.
-
-
-
-
-
-
- JSON values are correlated to their schema by the "describedby"
- relation, where the schema is the target of the relation.
- JSON values MUST be of the "application/json" media type or
- any other subtype. Consequently, dictating how a JSON value should
- specify the relation to the schema is beyond the normative scope
- of this document since this document specifically defines the JSON
- Schema media type, and no other. It is RECOMMNENDED that JSON values
- specify their schema so that user agents can interpret the instance
- and retain the self-descriptive characteristics. This avoides the need for out-of-band information about
- instance data. Two approaches are recommended for declaring the
- relation to the schema that describes the meaning of a JSON instance's (or collection
- of instances) structure. A MIME type parameter named
- "profile" or a relation of "describedby" (which could be specified by a Link header) may be used:
-
-
-
+
+
+ This schema defines the properties of the instance, the required properties (id,
+ name, and price), as well as an optional property (tags). This also defines the
+ link relations of the instance.
+
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ values that contain data, but rather provides a separate format for flexibly
+ communicating how a JSON value should be interpreted and validated, such that
+ user agents can properly understand acceptable structures and extrapolate
+ hyperlink information from the JSON. It is acknowledged that JSON values come in
+ a variety of structures, and JSON is unique in that the structure of stored data
+ structures often prescribes a non-ambiguous definite JSON representation.
+ Attempting to force a specific structure is generally not viable, and therefore
+ JSON Schema allows for a great flexibility in the structure of the JSON data
+ that it describes.
+
+
+ This specification is protocol agnostic. The underlying protocol (such as HTTP)
+ should sufficiently define the semantics of the client-server interface, the
+ retrieval of resource representations linked to by JSON representations, and
+ modification of those resources. The goal of this format is to sufficiently
+ describe JSON structures such that one can utilize existing information
+ available in existing JSON representations from a large variety of services that
+ leverage a representational state transfer architecture using existing
+ protocols.
+
+
+
+
+
+
+ JSON values are correlated to their schema by the "describedby" relation, where the
+ schema is the target of the relation. JSON values MUST be of the "application/json"
+ media type or any other subtype. Consequently, dictating how a JSON value should
+ specify the relation to the schema is beyond the normative scope of this document
+ since this document specifically defines the JSON Schema media type, and no other.
+ It is RECOMMNENDED that JSON values specify their schema so that user agents can
+ interpret the instance and retain the self-descriptive characteristics. This
+ avoides the need for out-of-band information about instance data. Two approaches are
+ recommended for declaring the relation to the schema that describes the meaning of a
+ JSON instance's (or collection of instances) structure. A MIME type parameter named
+ "profile" or a relation of "describedby" (which could be specified by a Link header)
+ may be used:
+
+
+
-
-
+
+
- or if the content is being transferred by a protocol (such as HTTP) that
- provides headers, a Link header can be used:
+ or if the content is being transferred by a protocol (such as HTTP) that provides
+ headers, a Link header can be used:
-
-
+
+
; rel="describedby"
]]>
-
-
-
- Instances MAY specify multiple schemas, to indicate all the schemas that
- are applicable to the data, and the data SHOULD be valid by all the schemas.
- The instance data MAY have multiple schemas
- that it is described by (the instance data SHOULD be valid for those schemas).
- Or if the document is a collection of instances, the collection MAY contain
- instances from different schemas. The mechanism for referencing a schema is
- determined by the media type of the instance (if it provides a method for
- referencing schemas).
-
-
-
-
- JSON Schemas can themselves be described using JSON Schemas.
- A self-describing JSON Schema for the core JSON Schema can
- be found at http://json-schema.org/schema for the latest version or
- http://json-schema.org/draft-04/schema for the draft-04 version. The hyper schema
- self-description can be found at http://json-schema.org/hyper-schema
- or http://json-schema.org/draft-04/hyper-schema. All schemas
- used within a protocol with a media type specified SHOULD include a MIME parameter that refers to the self-descriptive
- hyper schema or another schema that extends this hyper schema:
-
-
-
+
+
+
+ Instances MAY specify multiple schemas, to indicate all the schemas that are
+ applicable to the data, and the data SHOULD be valid by all the schemas. The
+ instance data MAY have multiple schemas that it is described by (the instance data
+ SHOULD be valid for those schemas). Or if the document is a collection of
+ instances, the collection MAY contain instances from different schemas. The
+ mechanism for referencing a schema is determined by the media type of the instance
+ (if it provides a method for referencing schemas).
+
+
+
+
+ JSON Schemas can themselves be described using JSON Schemas. A self-describing
+ JSON Schema for the core JSON Schema can be found at http://json-schema.org/schema for
+ the latest version or http://json-schema.org/draft-04/schema
+ for the draft-04 version. The hyper schema self-description can be found at
+ http://json-schema.org/hyper-schema
+ or http://json-schema.org/draft-04/hyper-schema.
+ All schemas used within a protocol with a media type specified SHOULD include a
+ MIME parameter that refers to the self-descriptive hyper schema or another
+ schema that extends this hyper schema:
+
+
+
-
-
-
-
-
-
-
-
- A JSON Schema is a JSON object that defines various attributes
- (including usage and valid values) of a JSON value. JSON
- Schema has recursive capabilities; there are a number of elements
- in the structure that allow for nested JSON Schemas.
-
-
-
- An example JSON Schema could look like:
-
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON object that defines various attributes (including usage and
+ valid values) of a JSON value. JSON Schema has recursive capabilities; there are a
+ number of elements in the structure that allow for nested JSON Schemas.
+
+
+
+ An example JSON Schema could look like:
+
-
-
+
+
- A JSON Schema object MAY have one or more of the properties defined in this section. These properties (called "keywords" in this section) are
- grouped in subsections according to the type of instance they can validate, while some properties apply to all instance types. Some other keywords
- do not participate in instance validation and are into a section of their own.
+ A JSON Schema object MAY have one or more of the properties defined in this section.
+ These properties (called "keywords" in this section) are grouped in subsections
+ according to the type of instance they can validate, while some properties apply to all
+ instance types. Some other keywords do not participate in instance validation and are
+ into a section of their own.
- The value of this keyword is a number which defines the minimum value of the instance.
+ The value of this keyword is a number which defines the minimum value of the
+ instance.
- The value of this keyword is a number which defines the maximum value of the instance.
+ The value of this keyword is a number which defines the maximum value of the
+ instance.
- This keyword MUST be paired with "minimum". Its value is a boolean. If false (the default), then the instance may be greater than or equal to "minimum". If true, then the instance must be strictly greater than "minimum".
+ This keyword MUST be paired with "minimum". Its value is a boolean. If false (the
+ default), then the instance may be greater than or equal to "minimum". If true, then the
+ instance must be strictly greater than "minimum".
- This keyword MUST be paired with "maximum". Its value is a boolean. If false (the default), then the instance may be less than or equal to "maximum". If true, then the instance must be strictly lower than "maximum".
+ This keyword MUST be paired with "maximum". Its value is a boolean. If false (the
+ default), then the instance may be less than or equal to "maximum". If true, then the
+ instance must be strictly lower than "maximum".
- This keyword's value is a number which must divide instance with no remainder (that is, the result of the division must be an integer.) The value of this keyword MUST NOT be 0.
+ This keyword's value is a number which must divide instance with no remainder (that
+ is, the result of the division must be an integer.) The value of this keyword MUST NOT
+ be 0.
@@ -348,19 +362,22 @@ Content-Type: application/json;
- The value of this keyword is an ECMA 262 regular expression that the instance MUST match in order to be valid.
+ The value of this keyword is an ECMA 262 regular expression that the instance MUST
+ match in order to be valid.
- The value of this keyword is an integer which defines the minimum length of the instance.
+ The value of this keyword is an integer which defines the minimum length of the
+ instance.
- The value of this keyword is an integer which defines the maximum length of the instance.
+ The value of this keyword is an integer which defines the maximum length of the
+ instance.
@@ -370,24 +387,30 @@ Content-Type: application/json;
- The value of this keyword is an integer which defines the minimum number of elements in the instance.
+ The value of this keyword is an integer which defines the minimum number of elements
+ in the instance.
- The value of this keyword is an integer which defines the minimum number of elements in the instance.
+ The value of this keyword is an integer which defines the minimum number of elements
+ in the instance.
- This keyword defines a set of allowed items in the instance. The value of this keyword MUST be a schema or an array of schemas:
+ This keyword defines a set of allowed items in the instance. The value of this
+ keyword MUST be a schema or an array of schemas:
- if it is a schema, then all items in the instance MUST be valid against this schema;
- if it is an array of schemas, then the item at a given position in the instance MUST be valid according to the corresponding schema at
- the same position in the keyword value. This is called tuple typing. Constraints on items in the instance which have no corresponding
- schema in the keyword value are defined by "additionalItems".
+ if it is a schema, then all items in the instance MUST be valid against this
+ schema;
+ if it is an array of schemas, then the item at a given position in the
+ instance MUST be valid according to the corresponding schema at the same
+ position in the keyword value. This is called tuple typing. Constraints on items
+ in the instance which have no corresponding schema in the keyword value are
+ defined by "additionalItems".
@@ -395,43 +418,50 @@ Content-Type: application/json;
- This keyword specifies how to handle items in the instance which are is not explicitly defined by "items". Its value
- MUST be a schema or a boolean. Boolean value true is equivalent to an empty schema.
+ This keyword specifies how to handle items in the instance which are is not
+ explicitly defined by "items". Its value MUST be a schema or
+ a boolean. Boolean value true is equivalent to an empty schema.
- If "items" is present and its value is a schema, "additionalItems" is ignored.
+ If "items" is present and its value is a schema,
+ "additionalItems" is ignored.If "items" is defined and is an array of n elements, then:
- if "additionalItems" is false, then the instance is valid with regards to this keyword if and only if it has at most n elements;
- if "additionalItems" is a schema, then all instance elements of index n or greater (assuming array indexes start at 0) MUST be valid
- against this schema.
+ if "additionalItems" is false, then the instance is valid with regards to
+ this keyword if and only if it has at most n elements;
+ if "additionalItems" is a schema, then all instance elements of index n or
+ greater (assuming array indexes start at 0) MUST be valid against this
+ schema.If "items" is not defined, then:
if "additionalItems" is false, then the instance is invalid;
- if "additionalItems" is a schema, then all instance elements MUST be valid against this schema.
+ if "additionalItems" is a schema, then all instance elements MUST be valid
+ against this schema.
- The default value is an empty schema, which allows any value for additional items.
+ The default value is an empty schema, which allows any value for additional
+ items.
- This keyword indicates that all items in the instance MUST be unique (contains no two identical values).
+ This keyword indicates that all items in the instance MUST be unique (contains no two
+ identical values).
Two JSON instances are consider equal if they are both of the same type and:
are null; orare booleans/numbers/strings and have the same value; or
- are arrays, contain the same number of items, and each item in the array is equal to the item at the corresponding index in the other
- array; or
- are objects, contain the same set of property names, and each property in the object is equal to the corresponding property in the other
- object.
+ are arrays, contain the same number of items, and each item in the array is
+ equal to the item at the corresponding index in the other array; or
+ are objects, contain the same set of property names, and each property in the
+ object is equal to the corresponding property in the other object.
@@ -443,13 +473,15 @@ Content-Type: application/json;
- The value of this keyword is a positive integer which defines the minimum number of properties the instance must have.
+ The value of this keyword is a positive integer which defines the minimum number of
+ properties the instance must have.
- The value of this keyword is a positive integer which defines the maximum number of properties the instance must have.
+ The value of this keyword is a positive integer which defines the maximum number of
+ properties the instance must have.
@@ -457,15 +489,17 @@ Content-Type: application/json;
The value of this keyword is an object where:
- property name match equivalent property names in the instance, if any, and
+ property name match equivalent property names in the instance, if any,
+ andproperty values are schemas.
- If the instance has a property name which is equal to a property name defined in this keyword, then the property value MUST be valid against the
- corresponding schema.
+ If the instance has a property name which is equal to a property name defined in this
+ keyword, then the property value MUST be valid against the corresponding schema.
- Objects are unordered, therefore the order of the instance properties or attribute properties MUST NOT determine validation success.
+ Objects are unordered, therefore the order of the instance properties or attribute
+ properties MUST NOT determine validation success.
@@ -478,8 +512,9 @@ Content-Type: application/json;
- For each property name of the instance, if it is matched by one or more regular expressions defined by this keyword, then the matching value MUST
- be valid against all such schemas.
+ For each property name of the instance, if it is matched by one or more regular
+ expressions defined by this keyword, then the matching value MUST be valid against all
+ such schemas.Note that regular expressions are not anchored.
@@ -487,30 +522,39 @@ Content-Type: application/json;
- This keyword defines how to handle an instance's properties which could not be matched by either "properties" or
- "patternProperties" (here after referred to as "additional properties"). Its value MUST be either a schema
- or a boolean. Boolean value true is equivalent to an empty schema.
+ This keyword defines how to handle an instance's properties which could not be
+ matched by either "properties" or "patternProperties" (here after referred to as
+ "additional properties"). Its value MUST be either a schema or a boolean. Boolean value
+ true is equivalent to an empty schema.
- If the value of this keyword is false, then the instance is valid if and only if there are no additional properties in the instance.
+ If the value of this keyword is false, then the instance is valid if and only if
+ there are no additional properties in the instance.
- If the value of this keyword is a schema, then all additional properties MUST be valid against this schema.
+ If the value of this keyword is a schema, then all additional properties MUST be
+ valid against this schema.
- The default value is an empty schema, which allows any value for additional properties.
+ The default value is an empty schema, which allows any value for additional
+ properties.
- The value of this keyword is an array of strings which defines all the property names that must exist on the instance for it to be valid.
+ The value of this keyword is an array of strings which defines all the property names
+ that must exist on the instance for it to be valid.
- The value of this keyword is an object. Property names of this object match equivalent property names in the instance, if any. Property values are either of:
+ The value of this keyword is an object. Property names of this object match
+ equivalent property names in the instance, if any. Property values are either of:
- a string or an array of strings; in this case, the instance is valid if and only if the instance has the corresponding property name(s);
- a schema; in this case, the instance is valid if and only if the value of the corresponding property name is valid against this schema.
+ a string or an array of strings; in this case, the instance is valid if and
+ only if the instance has the corresponding property name(s);
+ a schema; in this case, the instance is valid if and only if the value of the
+ corresponding property name is valid against this schema.
@@ -518,9 +562,10 @@ Content-Type: application/json;
- It should be noted that validation by "properties" and "patternProperties" are not exclusive: if a property name in an instance is matched by
- both a property name in "properties" and one or more regular expressions in "patternProperties", then the corresponding value MUST validate against
- all of these schemas.
+ It should be noted that validation by "properties" and "patternProperties" are not
+ exclusive: if a property name in an instance is matched by both a property name in
+ "properties" and one or more regular expressions in "patternProperties", then the
+ corresponding value MUST validate against all of these schemas.
@@ -530,30 +575,37 @@ Content-Type: application/json;
- This keyword defines what the primitive type or the schema of the instance MUST be in order to validate. This attribute can take one of two
- forms:
+ This keyword defines what the primitive type or the schema of the instance MUST be in
+ order to validate. This attribute can take one of two forms:
- A string indicating a primitive or simple type. The string MUST be one of the following values:
+ A string indicating a primitive or simple type. The
+ string MUST be one of the following values:
Instance MUST be an object.Instance MUST be an array.Instance MUST be a string.
- Instance MUST be a number, including floating point numbers.
- Instance MUST be an integer number (a positive or negative natural number with no fractional or decimal component).
- Instance MUST be a JSON boolean (true or false).
- Instance MUST be the JSON literal null. Note that without this type, null values are not allowed.
+ Instance MUST be a number, including floating point
+ numbers.
+ Instance MUST be an integer number (a positive or
+ negative natural number with no fractional or decimal component).
+ Instance MUST be a JSON boolean (true or
+ false).
+ Instance MUST be the JSON literal null. Note that
+ without this type, null values are not allowed.Instance MAY be of any type, including null.
- An array of one or more simple types or schemas. The instance value is valid if it is of the same type as one of
- the simple types, or valid by one of the schemas.
+ An array of one or more simple types or schemas. The
+ instance value is valid if it is of the same type as one of the simple types, or
+ valid by one of the schemas. If this attribute is not specified, then all value types are accepted.
- For example, a schema that defines if an instance can be a string or a number would be:
+ For example, a schema that defines if an instance can be a string or a
+ number would be:
- This attribute takes the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the
- instance matches any type or schema in the array, then this instance is not valid.
+ This attribute takes the same values as the "type" attribute, however if the instance
+ matches the type or if this value is an array and the instance matches any type or
+ schema in the array, then this instance is not valid.
@@ -576,26 +629,35 @@ Content-Type: application/json;
- This property helps to refine the type of data, content type, or microformat an instance value must adhere to. A format attribute MAY be one
- of the values listed below, and if so, SHOULD adhere to the semantics describing for the format. A format SHOULD only be used to give meaning to
- primitive types (string, integer, number, or boolean). Validators MUST validate that instances conform to a format.
+ This property helps to refine the type of data, content type, or microformat an
+ instance value must adhere to. A format attribute MAY be one of the values listed
+ below, and if so, SHOULD adhere to the semantics describing for the format. A format
+ SHOULD only be used to give meaning to primitive types (string, integer, number, or
+ boolean). Validators MUST validate that instances conform to a format.
- A format attribute only validates a defined set of primitive types. If the primitive type of the currently validated instance is not a member
- of this set, the instance MUST be considered valid for this keyword. All format attributes defined below are listed along with the primitive
- types they validate.
+ A format attribute only validates a defined set of primitive types. If the
+ primitive type of the currently validated instance is not a member of this set, the
+ instance MUST be considered valid for this keyword. All format attributes defined
+ below are listed along with the primitive types they validate.The following formats are predefined:
- (string) This SHOULD be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time.
- This is the recommended form of date/timestamp.
- (string) This SHOULD be a date in the format of YYYY-MM-DD. It is recommended that you use the
- "date-time" format instead of "date" unless you need to transfer only the date part.
- (string) This SHOULD be a time in the format of hh:mm:ss. It is recommended that you use the
- "date-time" format instead of "time" unless you need to transfer only the time part.
- (number) This SHOULD be the difference, measured in milliseconds, between the
- specified time and midnight, 00:00 of January 1, 1970 UTC.
- (string) This SHOULD be an ECMA 262 (ie, JavaScript) regular expression.
- (string) This SHOULD be a phone number (format MAY follow E.123).
+ (string) This SHOULD be a date in ISO 8601 format of
+ YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of
+ date/timestamp.
+ (string) This SHOULD be a date in the format of
+ YYYY-MM-DD. It is recommended that you use the "date-time" format instead of
+ "date" unless you need to transfer only the date part.
+ (string) This SHOULD be a time in the format of hh:mm:ss.
+ It is recommended that you use the "date-time" format instead of "time"
+ unless you need to transfer only the time part.
+ (number) This SHOULD be the difference, measured
+ in milliseconds, between the specified time and midnight, 00:00 of January 1,
+ 1970 UTC.
+ (string) This SHOULD be an ECMA 262 (ie, JavaScript)
+ regular expression.
+ (string) This SHOULD be a phone number (format MAY follow
+ E.123).(string) This value SHOULD be a URI.(string) This SHOULD be an email address.(string) This SHOULD be an ip version 4 address.
@@ -608,8 +670,10 @@ Content-Type: application/json;
- The value of this keyword is an array which provides an enumeration of JSON instances. The instance value MUST be one of the values in the array in order
- for the schema to be valid. Comparison of enum values uses the same algorithm as defined in "uniqueItems".
+ The value of this keyword is an array which provides an enumeration of JSON
+ instances. The instance value MUST be one of the values in the array in order for the
+ schema to be valid. Comparison of enum values uses the same algorithm as defined in
+ "uniqueItems".The array MUST have at least one element. Elements in the array MUST be unique.
@@ -617,13 +681,17 @@ Content-Type: application/json;
- The value of this keyword MUST be another schema which will provide a base schema which the current schema will inherit from. The inheritance
- rules are such that any instance that is valid according to the current schema MUST be valid according to the referenced schema. This MAY also be an
- array, in which case, the instance MUST be valid for all the schemas in the array. A schema that extends another schema MAY define additional
- attributes, constrain existing attributes, or add other constraints.
+ The value of this keyword MUST be another schema which will provide a base schema
+ which the current schema will inherit from. The inheritance rules are such that any
+ instance that is valid according to the current schema MUST be valid according to the
+ referenced schema. This MAY also be an array, in which case, the instance MUST be valid
+ for all the schemas in the array. A schema that extends another schema MAY define
+ additional attributes, constrain existing attributes, or add other constraints.
- Conceptually, the behavior of extends can be seen as validating an instance against all constraints in the extending schema as well as the
- extended schema(s). More optimized implementations that merge schemas are possible, but are not required. Some examples of using "extends":
+ Conceptually, the behavior of extends can be seen as validating an instance against
+ all constraints in the extending schema as well as the extended schema(s). More
+ optimized implementations that merge schemas are possible, but are not required. Some
+ examples of using "extends":
@@ -664,554 +732,622 @@ Content-Type: application/json;
- The following keywords do not play any role in instance validation "per se", however three of them ("$ref", "id" and "$schema") play an important role in the validation process.
+ The following keywords do not play any role in instance validation "per se", however
+ three of them ("$ref", "id" and "$schema") play an important role in the validation
+ process.
- This keyword defines the default value of the instance when the instance is undefined.
+ This keyword defines the default value of the instance when the instance is
+ undefined.
- Note that it is NOT required that the value of the instance matches the enclosing schema.
+ Note that it is NOT required that the value of the instance matches the enclosing
+ schema.
- This keyword is a string that provides a short description of the instance property.
+ This keyword is a string that provides a short description of the instance
+ property.
- This keyword is a string that provides a full description of the of purpose the instance property.
+ This keyword is a string that provides a full description of the of purpose the
+ instance property.
- This keyword defines the current URI of this schema (this attribute is effectively a "self" link). This URI MAY be relative or absolute. If the
- URI is relative it is resolved against the current URI of the parent schema it is contained in. If this schema is not contained in any parent
- schema, the current URI of the parent schema is held to be the URI under which this schema was addressed. If id is missing, the current URI of a
- schema is defined to be that of the parent schema. The current URI of the schema is also used to construct relative references such as for $ref.
+ This keyword defines the current URI of this schema (this attribute is effectively a
+ "self" link). This URI MAY be relative or absolute. If the URI is relative it is
+ resolved against the current URI of the parent schema it is contained in. If this schema
+ is not contained in any parent schema, the current URI of the parent schema is held to
+ be the URI under which this schema was addressed. If id is missing, the current URI of a
+ schema is defined to be that of the parent schema. The current URI of the schema is also
+ used to construct relative references such as for $ref.
- This attribute defines a URI of a schema that contains the full representation of this schema. When a validator encounters this attribute, it
- SHOULD replace the current schema with the schema referenced by the value's URI (if known and available) and re-validate the instance. This URI MAY
- be relative or absolute, and relative URIs SHOULD be resolved against the URI of the current schema.
+ This attribute defines a URI of a schema that contains the full representation of
+ this schema. When a validator encounters this attribute, it SHOULD replace the current
+ schema with the schema referenced by the value's URI (if known and available) and
+ re-validate the instance. This URI MAY be relative or absolute, and relative URIs
+ SHOULD be resolved against the URI of the current schema.
- This attribute defines a URI of a JSON Schema that is the schema of the current schema. When this attribute is defined, a validator SHOULD use
- the schema referenced by the value's URI (if known and available) when resolving Hyper Schemalinks.
+ This attribute defines a URI of a JSON Schema that is the schema of the current
+ schema. When this attribute is defined, a validator SHOULD use the schema referenced by
+ the value's URI (if known and available) when resolving Hyper Schemalinks.
- A validator MAY use this attribute's value to determine which version of JSON Schema the current schema is written in, and provide the
- appropriate validation features and behavior. Therefore, it is RECOMMENDED that all schema authors include this attribute in their schemas to
- prevent conflicts with future JSON Schema specification changes.
+ A validator MAY use this attribute's value to determine which version of JSON Schema
+ the current schema is written in, and provide the appropriate validation features and
+ behavior. Therefore, it is RECOMMENDED that all schema authors include this attribute
+ in their schemas to prevent conflicts with future JSON Schema specification changes.
+
-
-
-
-
- The following attributes are specified in addition to those
- attributes that already provided by the core schema with the specific
- purpose of informing user agents of relations between resources based
- on JSON data. Just as with JSON
- schema attributes, all the attributes in hyper schemas are optional.
- Therefore, an empty object is a valid (non-informative) schema, and
- essentially describes plain JSON (no constraints on the structures).
- Addition of attributes provides additive information for user agents.
-
-
-
-
- The value of the links property MUST be an array, where each item
- in the array is a link description object which describes the link
- relations of the instances.
-
-
-
-
-
-
- A link description object is used to describe link relations. In
- the context of a schema, it defines the link relations of the
- instances of the schema, and can be parameterized by the instance
- values. The link description format can be used without JSON Schema,
- and use of this format can
- be declared by referencing the normative link description
- schema as the the schema for the data structure that uses the
- links. The URI of the normative link description schema is:
- http://json-schema.org/links (latest version) or
- http://json-schema.org/draft-04/links (draft-04 version).
-
-
-
-
- The value of the "href" link description property
- indicates the target URI of the related resource. The value
- of the instance property SHOULD be resolved as a URI-Reference per RFC 3986
- and MAY be a relative URI. The base URI to be used for relative resolution
- SHOULD be the URI used to retrieve the instance object (not the schema)
- when used within a schema. Also, when links are used within a schema, the URI
- SHOULD be parametrized by the property values of the instance
- object, if property values exist for the corresponding variables
- in the template (otherwise they MAY be provided from alternate sources, like user input).
-
-
-
- Instance property values SHOULD be substituted into the URIs where
- matching braces ('{', '}') are found surrounding zero or more characters,
- creating an expanded URI. Instance property value substitutions are resolved
- by using the text between the braces to denote the property name
- from the instance to get the value to substitute.
-
-
- For example, if an href value is defined:
-
+
+
+
+
+ The following attributes are specified in addition to those attributes that already
+ provided by the core schema with the specific purpose of informing user agents of
+ relations between resources based on JSON data. Just as with JSON schema attributes,
+ all the attributes in hyper schemas are optional. Therefore, an empty object is a
+ valid (non-informative) schema, and essentially describes plain JSON (no constraints
+ on the structures). Addition of attributes provides additive information for user
+ agents.
+
+
+
+
+ The value of the links property MUST be an array, where each item in the array
+ is a link description object which describes the link relations of the
+ instances.
+
+
+
+
+
+
+ A link description object is used to describe link relations. In the context
+ of a schema, it defines the link relations of the instances of the schema,
+ and can be parameterized by the instance values. The link description format
+ can be used without JSON Schema, and use of this format can be declared by
+ referencing the normative link description schema as the the schema for the
+ data structure that uses the links. The URI of the normative link
+ description schema is: http://json-schema.org/links
+ (latest version) or http://json-schema.org/draft-04/links
+ (draft-04 version).
+
+
+
+
+ The value of the "href" link description property indicates the target
+ URI of the related resource. The value of the instance property SHOULD
+ be resolved as a URI-Reference per RFC
+ 3986 and MAY be a relative URI. The base URI to be used for
+ relative resolution SHOULD be the URI used to retrieve the instance
+ object (not the schema) when used within a schema. Also, when links are
+ used within a schema, the URI SHOULD be parametrized by the property
+ values of the instance object, if property values exist for the
+ corresponding variables in the template (otherwise they MAY be provided
+ from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute.
+
+
+ For example, if an href value is defined:
+
-
- Then it would be resolved by replace the value of the "id" property value from the instance object.
-
-
-
- If the value of the "id" property was "45", the expanded URI would be:
-
+
+ Then it would be resolved by replace the value of the
+ "id" property value from the instance object.
+
+
+
+ If the value of the "id" property was "45", the expanded
+ URI would be:
+
-
-
-
- If matching braces are found with the string "@" (no quotes) between the braces, then the
- actual instance value SHOULD be used to replace the braces, rather than a property value.
- This should only be used in situations where the instance is a scalar (string,
- boolean, or number), and not for objects or arrays.
-
-
-
-
-
- The value of the "rel" property indicates the name of the
- relation to the target resource. The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource MUST be indicated with the schema describing the top level JSON representation.
-
-
-
- Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287). However, we define these relations here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
-
-
-
- If the relation value is "self", when this property is encountered in
- the instance object, the object represents a resource and the instance object is
- treated as a full representation of the target resource identified by
- the specified URI.
-
-
-
- This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.
-
-
-
- This indicates the target of the link is the schema for the instance object. This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
-
-
- This relation indicates that the target of the link
- SHOULD be treated as the root or the body of the representation for the
- purposes of user agent interaction or fragment resolution. All other
- properties of the instance objects can be regarded as meta-data
- descriptions for the data.
-
-
-
-
-
- The following relations are applicable for schemas (the schema as the "from" resource in the relation):
-
-
- This indicates the target resource that represents collection of instances of a schema.
- This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
-
-
-
-
-
- For example, if a schema is defined:
-
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the
+ braces, then the actual instance value SHOULD be used to replace the
+ braces, rather than a property value. This should only be used in
+ situations where the instance is a scalar (string, boolean, or number),
+ and not for objects or arrays.
+
+
+
+
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target SHOULD be interpreted as
+ specifically from the instance object that the schema (or sub-schema)
+ applies to, not just the top level resource that contains the object
+ within its hierarchy. If a resource JSON representation contains a sub
+ object with a property interpreted as a link, that sub-object holds the
+ relation with the target. A relation to target from the top level
+ resource MUST be indicated with the schema describing the top level JSON
+ representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users
+ are encouraged to utilize existing accepted relation definitions,
+ including those in existing relation registries (see RFC 4287). However, we define these relations
+ here for clarity of normative interpretation within the context of JSON
+ hyper schema defined relations:
+
+
+
+ If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the
+ specified URI.
+
+
+
+ This indicates that the target of the link is the full
+ representation for the instance object. The object that contains
+ this link possibly may not be the full representation.
+
+
+
+ This indicates the target of the link is the schema for the
+ instance object. This MAY be used to specifically denote the
+ schemas of objects within a JSON object hierarchy, facilitating
+ polymorphic type data structures.
+
+
+
+ This relation indicates that the target of the link SHOULD be
+ treated as the root or the body of the representation for the
+ purposes of user agent interaction or fragment resolution. All
+ other properties of the instance objects can be regarded as
+ meta-data descriptions for the data.
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the
+ "from" resource in the relation):
+
+
+ This indicates the target resource that
+ represents collection of instances of a schema.
+ This indicates a target to use for creating new
+ instances of a schema. This link definition SHOULD be a submission
+ link with a non-safe method (like POST).
+
+
+
+
+
+ For example, if a schema is defined:
+
-
-
+
+
-
- And if a collection of instance resource's JSON representation was retrieved:
-
+
+ And if a collection of instance resource's JSON
+ representation was retrieved:
+
-
-
-
- This would indicate that for the first item in the collection, its own
- (self) URI would resolve to "/Resource/thing" and the first item's "up"
- relation SHOULD be resolved to the resource at "/Resource/parent".
- The "children" collection would be located at "/Resource/?upId=thing".
-
-
-
-
- This property value is a string that defines the templating language used in the "href" attribute. If no templating language is defined, then the default Link Description Object templating langauge is used.
-
-
-
- This property value is a schema that defines the expected structure of the JSON representation of the target of the link.
-
-
-
-
- The following properties also apply to link definition objects, and
- provide functionality analogous to HTML forms, in providing a
- means for submitting extra (often user supplied) information to send to a server.
-
-
-
-
- This attribute defines which method can be used to access the target resource.
- In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
- such as "PUT" and "DELETE" have semantics that are clearly implied by
- accessed resources, and do not need to be defined here).
- This defaults to "GET".
-
-
-
-
-
- If present, this property indicates a query media type format that the server
- supports for querying or posting to the collection of instances at the target
- resource. The query can be
- suffixed to the target URI to query the collection with
- property-based constraints on the resources that SHOULD be returned from
- the server or used to post data to the resource (depending on the method).
-
-
- For example, with the following schema:
-
+
+
+
+ This would indicate that for the first item in the collection, its own
+ (self) URI would resolve to "/Resource/thing" and the first item's "up"
+ relation SHOULD be resolved to the resource at "/Resource/parent". The
+ "children" collection would be located at "/Resource/?upId=thing".
+
+
+
+
+ This property value is a string that defines the templating language used
+ in the "href" attribute. If no templating
+ language is defined, then the default Link Description
+ Object templating langauge is used.
+
+
+
+ This property value is a schema that defines the expected structure of
+ the JSON representation of the target of the link.
+
+
+
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means for
+ submitting extra (often user supplied) information to send to a server.
+
+
+
+
+ This attribute defines which method can be used to access the target
+ resource. In an HTTP environment, this would be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+
+
+
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints
+ on the resources that SHOULD be returned from the server or used to
+ post data to the resource (depending on the method).
+
+
+ For example, with the following schema:
+
-
- This indicates that the client can query the server for instances that have a specific name.
-
-
-
- For example:
-
+
+ This indicates that the client can query the server
+ for instances that have a specific name.
+
+
+
+ For example:
+
-
-
-
- If no enctype or method is specified, only the single URI specified by
- the href property is defined. If the method is POST, "application/json" is
- the default media type.
-
-
-
-
-
- This attribute contains a schema which defines the acceptable structure of the submitted
- request (for a GET request, this schema would define the properties for the query string
- and for a POST request, this would define the body).
-
-
-
-
-
-
-
-
- This property indicates the fragment resolution protocol to use for
- resolving fragment identifiers in URIs within the instance
- representations. This applies to the instance object URIs and all
- children of the instance object's URIs. The default fragment resolution
- protocol is "json-pointer", which is defined below. Other fragment
- resolution protocols MAY be used, but are not defined in this document.
-
-
-
- The fragment identifier is based on RFC 3986, Sec 5, and defines the
- mechanism for resolving references to entities within a document.
-
-
-
- The "json-pointer" fragment resolution protocol uses a JSON Pointer to resolve fragment identifiers in URIs within instance representations.
-
-
-
-
-
-
- This attribute indicates that the instance value SHOULD NOT be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
-
-
-
- If the instance property value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists the possible values for this property.
-
-
-
-
- This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
- The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5,
- and is relative to the instance's URI.
-
-
-
- When multiple schemas have been referenced for an instance, the user agent
- can determine if this schema is applicable for a particular instance by
- determining if the URI of the instance begins with the the value of the "pathStart"
- attribute. If the URI of the instance does not start with this URI,
- or if another schema specifies a starting URI that is longer and also matches the
- instance, this schema SHOULD NOT be applied to the instance. Any schema
- that does not have a pathStart attribute SHOULD be considered applicable
- to all the instances for which it is referenced.
-
-
-
-
- This attribute defines the media type of the instance representations that this schema is defining.
-
-
-
-
-
- This specification is a sub-type of the JSON format, and
- consequently the security considerations are generally the same as RFC 4627.
- However, an additional issue is that when link relation of "self"
- is used to denote a full representation of an object, the user agent
- SHOULD NOT consider the representation to be the authoritative representation
- of the resource denoted by the target URI if the target URI is not
- equivalent to or a sub-path of the the URI used to request the resource
- representation which contains the target URI with the "self" link.
-
-
- For example, if a hyper schema was defined:
-
+
+
+
+ If no enctype or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST,
+ "application/json" is the default media type.
+
+
+
+
+
+ This attribute contains a schema which defines the acceptable
+ structure of the submitted request (for a GET request, this schema
+ would define the properties for the query string and for a POST
+ request, this would define the body).
+
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for resolving
+ fragment identifiers in URIs within the instance representations. This applies
+ to the instance object URIs and all children of the instance object's URIs. The
+ default fragment resolution protocol is "json-pointer", which is defined below.
+ Other fragment resolution protocols MAY be used, but are not defined in this
+ document.
+
+
+
+ The fragment identifier is based on RFC 3986, Sec
+ 5, and defines the mechanism for resolving references to entities within
+ a document.
+
+
+
+ The "json-pointer" fragment resolution protocol uses a JSON Pointer to resolve fragment identifiers in
+ URIs within instance representations.
+
+
+
+
+
+
+ This attribute indicates that the instance value SHOULD NOT be changed. Attempts
+ by a user agent to modify the value of this property are expected to be rejected by
+ a server.
+
+
+
+ If the instance property value is a string, this attribute defines that the
+ string SHOULD be interpreted as binary data and decoded using the encoding named by
+ this schema property. RFC 2045, Sec 6.1 lists the
+ possible values for this property.
+
+
+
+
+ This attribute is a URI that defines what the instance's URI MUST start with in
+ order to validate. The value of the "pathStart" attribute MUST be resolved as
+ per RFC 3986, Sec 5, and is relative to the
+ instance's URI.
+
+
+
+ When multiple schemas have been referenced for an instance, the user agent can
+ determine if this schema is applicable for a particular instance by determining
+ if the URI of the instance begins with the the value of the "pathStart"
+ attribute. If the URI of the instance does not start with this URI, or if
+ another schema specifies a starting URI that is longer and also matches the
+ instance, this schema SHOULD NOT be applied to the instance. Any schema that
+ does not have a pathStart attribute SHOULD be considered applicable to all the
+ instances for which it is referenced.
+
+
+
+
+ This attribute defines the media type of the instance representations that this
+ schema is defining.
+
+
+
+
+
+ This specification is a sub-type of the JSON format, and consequently the security
+ considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self" is used to denote
+ a full representation of an object, the user agent SHOULD NOT consider the
+ representation to be the authoritative representation of the resource denoted by the
+ target URI if the target URI is not equivalent to or a sub-path of the the URI used
+ to request the resource representation which contains the target URI with the "self"
+ link.
+
+
+ For example, if a hyper schema was defined:
+
-
-
+
+
-
- And a resource was requested from somesite.com:
-
+
+ And a resource was requested from somesite.com:
+
-
-
+
+
-
- With a response of:
-
+
+ With a response of:
+
-
-
-
-
-
-
- The proposed MIME media type for JSON Schema is "application/schema+json".
- Type name: application
- Subtype name: schema+json
- Required parameters: profile
-
- The value of the profile parameter SHOULD be a URI (relative or absolute) that
- refers to the schema used to define the structure of this structure (the
- meta-schema). Normally the value would be http://json-schema.org/draft-04/hyper-schema,
- but it is allowable to use other schemas that extend the hyper schema's meta-
- schema.
-
- Optional parameters: pretty
- The value of the pretty parameter MAY be true or false to indicate if additional whitespace has been included to make the JSON representation easier to read.
-
-
-
- This registry is maintained by IANA per RFC 4287 and this specification adds
- four values: "full", "create", "instances", "root". New
- assignments are subject to IESG Approval, as outlined in RFC 5226.
- Requests should be made by email to IANA, which will then forward the
- request to the IESG, requesting approval.
-
-
-
-
-
-
-
-
- &rfc2045;
- &rfc2119;
- &rfc3339;
- &rfc3986;
- &rfc4287;
-
-
- JSON Pointer
-
- ForgeRock US, Inc.
-
-
- SitePen (USA)
-
-
-
-
-
-
- &rfc2616;
- &rfc4627;
- &rfc5226;
- &iddiscovery;
- &uritemplate;
- &linkheader;
- &html401;
- &css21;
-
-
-
-
-
-
-
- Changed "required" attribute to an array of strings.
- Removed "format" attribute.
- Added "minProperties" and "maxProperties" attributes.
- Replaced "slash-delimited" fragment resolution with "json-pointer".
- Added "template" LDO attribute.
- Removed irrelevant "Open Issues" section.
- Merged Conventions and Terminology sections.
- Defined terms used in specification.
- Restricted "type" to only the core JSON types.
- Renamed "divisibleBy" to "mod".
- Improved wording of many sections.
-
-
-
-
-
- Added example and verbiage to "extends" attribute.
- Defined slash-delimited to use a leading slash.
- Made "root" a relation instead of an attribute.
- Removed address values, and MIME media type from format to reduce confusion (mediaType already exists, so it can be used for MIME types).
- Added more explanation of nullability.
- Removed "alternate" attribute.
- Upper cased many normative usages of must, may, and should.
- Replaced the link submission "properties" attribute to "schema" attribute.
- Replaced "optional" attribute with "required" attribute.
- Replaced "maximumCanEqual" attribute with "exclusiveMaximum" attribute.
- Replaced "minimumCanEqual" attribute with "exclusiveMinimum" attribute.
- Replaced "requires" attribute with "dependencies" attribute.
- Moved "contentEncoding" attribute to hyper schema.
- Added "additionalItems" attribute.
- Added "id" attribute.
- Switched self-referencing variable substitution from "-this" to "@" to align with reserved characters in URI template.
- Added "patternProperties" attribute.
- Schema URIs are now namespace versioned.
- Added "$ref" and "$schema" attributes.
-
-
-
-
-
- Replaced "maxDecimal" attribute with "divisibleBy" attribute.
- Added slash-delimited fragment resolution protocol and made it the default.
- Added language about using links outside of schemas by referencing its normative URI.
- Added "uniqueItems" attribute.
- Added "targetSchema" attribute to link description object.
-
-
-
-
-
- Fixed category and updates from template.
-
-
-
-
-
- Initial draft.
-
-
-
-
-
-
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is "application/schema+json".
+ Type name: application
+ Subtype name: schema+json
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be
+ http://json-schema.org/draft-04/hyper-schema, but it is allowable to use other
+ schemas that extend the hyper schema's meta- schema.
+
+ Optional parameters: pretty
+ The value of the pretty parameter MAY be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+ This registry is maintained by IANA per RFC 4287
+ and this specification adds four values: "full", "create", "instances", "root".
+ New assignments are subject to IESG Approval, as outlined in RFC 5226. Requests should be made by email to IANA,
+ which will then forward the request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+ JSON Pointer
+
+ ForgeRock US, Inc.
+
+
+ SitePen (USA)
+
+
+
+
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
+
+
+
+
+
+
+ Changed "required" attribute to an array of strings.
+ Removed "format" attribute.
+ Added "minProperties" and "maxProperties" attributes.
+ Replaced "slash-delimited" fragment resolution with
+ "json-pointer".
+ Added "template" LDO attribute.
+ Removed irrelevant "Open Issues" section.
+ Merged Conventions and Terminology sections.
+ Defined terms used in specification.
+ Restricted "type" to only the core JSON types.
+ Renamed "divisibleBy" to "mod".
+ Improved wording of many sections.
+
+
+
+
+
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce
+ confusion (mediaType already exists, so it can be used for MIME
+ types).
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema"
+ attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum"
+ attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum"
+ attribute.
+ Replaced "requires" attribute with "dependencies" attribute.
+ Moved "contentEncoding" attribute to hyper schema.
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@"
+ to align with reserved characters in URI template.
+ Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
+
+
+
+
+
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+ Added slash-delimited fragment resolution protocol and made it the
+ default.
+ Added language about using links outside of schemas by referencing
+ its normative URI.
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
+
+
+
+
+
+ Fixed category and updates from template.
+
+
+
+
+
+ Initial draft.
+
+
+
+
+
+
From fc213b70b80a629bc5ea463efa08385fb5eaff65 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 4 Sep 2012 21:51:22 +0200
Subject: [PATCH 0089/1659] draft-04/schema: fix two issues, unify style
Both "disallow" and "type", when arrays, must have at least one element.
Unify style in the document:
* spaces, not tabs;
* tabs are 4 characters;
* no space between an object member and a semicolon;
* spaces after the opening bracket/before the closing bracket;
* spaces after the opening accolade/before the closing accolade.
---
draft-04/schema | 364 ++++++++++++++++++++++++------------------------
1 file changed, 183 insertions(+), 181 deletions(-)
diff --git a/draft-04/schema b/draft-04/schema
index be519795..694459a2 100644
--- a/draft-04/schema
+++ b/draft-04/schema
@@ -1,183 +1,185 @@
{
- "$schema" : "http://json-schema.org/draft-04/schema#",
- "id" : "http://json-schema.org/draft-04/schema#",
- "type" : "object",
-
- "properties" : {
- "type" : {
- "type" : ["string", "array"],
- "items" : {
- "type" : ["string", {"$ref" : "#"}]
- },
- "uniqueItems" : true,
- "default" : "any"
- },
-
- "disallow" : {
- "type" : ["string", "array"],
- "items" : {
- "type" : ["string", {"$ref" : "#"}]
- },
- "uniqueItems" : true
- },
-
- "extends" : {
- "type" : [{"$ref" : "#"}, "array"],
- "items" : {"$ref" : "#"},
- "default" : {}
- },
-
- "enum" : {
- "type" : "array",
- "minItems" : 1,
- "uniqueItems" : true
- },
-
- "minimum" : {
- "type" : "number"
- },
-
- "maximum" : {
- "type" : "number"
- },
-
- "exclusiveMinimum" : {
- "type" : "boolean",
- "default" : false
- },
-
- "exclusiveMaximum" : {
- "type" : "boolean",
- "default" : false
- },
-
- "mod" : {
- "type" : "number",
- "minimum" : 0,
- "exclusiveMinimum" : true,
- "default" : 1
- },
-
- "minLength" : {
- "type" : "integer",
- "minimum" : 0,
- "default" : 0
- },
-
- "maxLength" : {
- "type" : "integer"
- },
-
- "pattern" : {
- "type" : "string",
- "format": "regex"
- },
-
- "items" : {
- "type" : [{"$ref" : "#"}, "array"],
- "items" : {"$ref" : "#"},
- "default" : {}
- },
-
- "additionalItems" : {
- "type" : [{"$ref" : "#"}, "boolean"],
- "default" : {}
- },
-
- "minItems" : {
- "type" : "integer",
- "minimum" : 0,
- "default" : 0
- },
-
- "maxItems" : {
- "type" : "integer",
- "minimum" : 0
- },
-
- "uniqueItems" : {
- "type" : "boolean",
- "default" : false
- },
-
- "properties" : {
- "type" : "object",
- "additionalProperties" : {"$ref" : "#"},
- "default" : {}
- },
-
- "patternProperties" : {
- "type" : "object",
- "additionalProperties" : {"$ref" : "#"},
- "default" : {}
- },
-
- "additionalProperties" : {
- "type" : [{"$ref" : "#"}, "boolean"],
- "default" : {}
- },
-
- "minProperties" : {
- "type" : "integer",
- "minimum" : 0,
- "default" : 0
- },
-
- "maxProperties" : {
- "type" : "integer",
- "minimum" : 0
- },
-
- "required" : {
- "type" : "array",
- "items" : {
- "type" : "string"
- }
- },
-
- "dependencies" : {
- "type" : "object",
- "additionalProperties" : {
- "type" : ["string", "array", {"$ref" : "#"}],
- "items" : {
- "type" : "string"
- }
- },
- "default" : {}
- },
-
- "id" : {
- "type" : "string",
- "format": "uri"
- },
-
- "$ref" : {
- "type" : "string",
- "format": "uri"
- },
-
- "$schema" : {
- "type" : "string",
- "format": "uri"
- },
-
- "title" : {
- "type" : "string"
- },
-
- "description" : {
- "type" : "string"
- },
-
- "default" : {
- "type" : "any"
- }
- },
-
- "dependencies" : {
- "exclusiveMinimum" : "minimum",
- "exclusiveMaximum" : "maximum"
- },
-
- "default" : {}
+ "$schema": "http://json-schema.org/draft-04/schema#",
+ "id": "http://json-schema.org/draft-04/schema#",
+ "type": "object",
+
+ "properties": {
+ "type": {
+ "type": [ "string", "array" ],
+ "items": {
+ "type": [ "string", {"$ref": "#"} ]
+ },
+ "uniqueItems": true,
+ "minItems": 1,
+ "default": "any"
+ },
+
+ "disallow": {
+ "type": [ "string", "array" ],
+ "items": {
+ "type": [ "string", { "$ref": "#" } ]
+ },
+ "uniqueItems": true,
+ "minItems": 1
+ },
+
+ "extends": {
+ "type": [ {"$ref": "#" }, "array" ],
+ "items": { "$ref": "#" },
+ "default": {}
+ },
+
+ "enum": {
+ "type": "array",
+ "minItems": 1,
+ "uniqueItems": true
+ },
+
+ "minimum": {
+ "type": "number"
+ },
+
+ "maximum": {
+ "type": "number"
+ },
+
+ "exclusiveMinimum": {
+ "type": "boolean",
+ "default": false
+ },
+
+ "exclusiveMaximum": {
+ "type": "boolean",
+ "default": false
+ },
+
+ "mod": {
+ "type": "number",
+ "minimum": 0,
+ "exclusiveMinimum": true,
+ "default": 1
+ },
+
+ "minLength": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+
+ "maxLength": {
+ "type": "integer"
+ },
+
+ "pattern": {
+ "type": "string",
+ "format": "regex"
+ },
+
+ "items": {
+ "type": [ { "$ref": "#" }, "array" ],
+ "items": {"$ref": "#"},
+ "default": {}
+ },
+
+ "additionalItems": {
+ "type": [ { "$ref": "#" }, "boolean" ],
+ "default": {}
+ },
+
+ "minItems": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+
+ "maxItems": {
+ "type": "integer",
+ "minimum": 0
+ },
+
+ "uniqueItems": {
+ "type": "boolean",
+ "default": false
+ },
+
+ "properties": {
+ "type": "object",
+ "additionalProperties": { "$ref": "#" },
+ "default": {}
+ },
+
+ "patternProperties": {
+ "type": "object",
+ "additionalProperties": { "$ref": "#" },
+ "default": {}
+ },
+
+ "additionalProperties": {
+ "type": [ {"$ref": "#" }, "boolean" ],
+ "default": {}
+ },
+
+ "minProperties": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+
+ "maxProperties": {
+ "type": "integer",
+ "minimum": 0
+ },
+
+ "required": {
+ "type": "array",
+ "items": {
+ "type": "string"
+ }
+ },
+
+ "dependencies": {
+ "type": "object",
+ "additionalProperties": {
+ "type": [ "string", "array", { "$ref": "#" } ],
+ "items": {
+ "type": "string"
+ }
+ },
+ "default": {}
+ },
+
+ "id": {
+ "type": "string",
+ "format": "uri"
+ },
+
+ "$ref": {
+ "type": "string",
+ "format": "uri"
+ },
+
+ "$schema": {
+ "type": "string",
+ "format": "uri"
+ },
+
+ "title": {
+ "type": "string"
+ },
+
+ "description": {
+ "type": "string"
+ },
+
+ "default": {
+ "type": "any"
+ }
+ },
+
+ "dependencies": {
+ "exclusiveMinimum": "minimum",
+ "exclusiveMaximum": "maximum"
+ },
+
+ "default": {}
}
From 46ef7d0f67c79d8bc1a69c22938130dd7288a987 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 4 Sep 2012 22:17:55 +0200
Subject: [PATCH 0090/1659] README updates
Needed!
---
README.md | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/README.md b/README.md
index 0a6ff1be..01f397e1 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,20 @@
-## New Home JSON Schema repository
+## Welcome to JSON Schema
-Is the repository for the JSON Schema specification, reference schemas and a CommonJS implementation of JSON Schema (not the only JavaScript implementation of JSON Schema, JSV is another excellent JavaScript validator).
+This repository contains the current, and historical, JSON Schema
+specifications, along wit a CommonJS implementation (authored by Kris Zyp, one
+of the initiators of JSON Schema).
-Code is licensed under the AFL or BSD license.
+The wiki contains
+a detailed description of JSON Schema, and discussion about the next version of
+the specification.
+
+See also the JSON Schema web site: http://json-schema.org
+
+Note that the content of the aforementioned web site is available from this
+repository (branch gh-pages). Pull requests to improve the content of
+the site will be considered.
+
+## License
+
+The source material in this repository is licensed under the AFL or BSD license.
-Contributors welcome!
\ No newline at end of file
From e6e84430ab63d5887be40efd97b21b46b9c62496 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 11 Sep 2012 21:28:18 +0200
Subject: [PATCH 0091/1659] Candidate draft for core JSON Schema definition
Not complete, of course. Lots of RFC link sprinkles need to be added all around.
And some other stuff.
---
proposals/json-schema-core.xml | 579 +++++++++++++++++++++++++++++++++
1 file changed, 579 insertions(+)
create mode 100644 proposals/json-schema-core.xml
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
new file mode 100644
index 00000000..cb808aa3
--- /dev/null
+++ b/proposals/json-schema-core.xml
@@ -0,0 +1,579 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+ JSON Schema: core definitions and purposes
+
+
+
+ fgaliegue@gmail.com
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ Hyper Schema
+ Hypermedia
+
+
+
+ JSON Schema defines the media type "application/schema+json", a JSON based format
+ for defining the structure of JSON data. JSON Schema provides a contract for what
+ JSON data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink navigation, and
+ interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON Schema is a JSON media type for defining the structure of JSON data. JSON
+ Schema provides a contract for what JSON data is required for a given application
+ and how to interact with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON data.
+
+
+
+ This document defines the core terminology used by JSON Schema. Other linked
+ specifications, which expand on a particular role of JSON Schema, will use that
+ terminology.
+
+
+
+ This document also defines inter schema relationships: how a particular JSON Schema
+ is identified (in a possibly unique way), how to address a JSON Schema in full, or
+ only parts of it.
+
+
+
+
+
+
+
+ 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.
+
+
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array",
+ "number", "string", "boolean", "true", "false", and "null" in this document are to
+ be interpreted as defined in RFC 4627.
+
+
+
+
+
+
+
+ A JSON Schema is a JSON document, and that document MUST be an object. Object
+ members of a JSON Schema are called keywords, or schema keywords.
+
+
+
+ A JSON Schema MAY be empty.
+
+
+
+
+
+ JSON Schemas can be nested, as in this example:
+
+
+
+
+
+
+
+
+ In this example, the enclosing schema of both "nested" and "alsonested" is
+ "parent". The schema with name "parent" is said to be a parent schema because it
+ is not enclosed within another schema.
+
+
+
+
+
+ JSON Schema defines seven primitive types for JSON values:
+
+
+
+ A JSON array.
+ A JSON boolean (true or false).
+ A JSON number without a decimal part.
+ Any JSON number. Number includes integer.
+ The JSON null value.
+ A JSON object.
+ A JSON string.
+
+
+
+
+
+
+ An instance is any JSON value which is being processed by a JSON Schema. The
+ specification may also refer to an instance as a JSON instance.
+
+
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json" for describing the
+ structure of JSON instances. JSON Schemas are themselves written in JSON and include
+ facilities for describing the structure of JSON in terms of allowable values,
+ descriptions, and interpreting relations with other resources.
+
+
+
+ JSON Schema serves different purposes, which are summarized below. Each purpose has
+ a defined set of keywords which is described in its own specification.
+
+
+
+ JSON Schema can be used to decorate either itself, or
+ instances, with descriptive text highlighting the schema's, or instance's,
+ purposes.
+ JSON Schema can be used to associate an instance to a
+ Link Description Object, as defined by FIXME.
+ JSON Schema can be used to validate the structure of an
+ instance. Keywords also exist for semantic analysis, although implementations are
+ not required to implement them.
+
+
+
+
+ JSON Schema provides a separate format for flexibly communicating how a JSON
+ value should be interpreted and/or validated, such that clients can properly
+ understand acceptable structures for, and/or extract the needed information
+ from, the JSON instance being processed.
+
+
+ It is acknowledged that JSON values can be of any type defined by the JSON
+ specification. As such, JSON Schema does not mandate that the instance being
+ processed be of a particular type: JSON Schema can process any JSON value,
+ including null. It is the domain of JSON Schema validation to add useful
+ constraints to the structure and, optionally, semantics, of the JSON instance
+ being processed.
+
+
+ JSON Schema is agnostic with regards to both protocols and programming
+ languages. In particular, this means that defining the semantics of the
+ client-server interface is dependent on the protocol being used.
+
+
+
+
+
+
+
+
+ This section describes the following:
+
+
+
+ available mechanisms for identifying the schema in a unique way: its
+ location, but also the version of the JSON Schema specification it is written
+ against;
+ available mechanisms for addressing a JSON Schema, or a specific subschema in
+ a JSON Schema.
+
+
+
+
+
+ The three keywords defined for this purpose are "$ref", "id" and "$schema".
+
+
+
+
+
+
+ The value for these keywords MUST be JSON strings. These strings MUST be
+ valid URIs, as defined in FIXME.
+
+
+
+
+
+
+
+ This keyword serves two purposes:
+
+
+
+ implementations use this value to determine which version of the draft this
+ schema is written against;
+ it is also a link to a resource which is itself a JSON Schema, against which
+ the schema MUST validate successfully.
+
+
+
+ This keyword SHOULD NOT be used in subschemas. In the event that it is
+ encountered in a subschema, implementations SHALL ignore it.
+
+
+
+ If a schema does not have a "$schema" keyword, implementations SHOULD consider
+ that the schema is written against the most current published version of the
+ JSON Schema specification.
+
+
+
+
+
+
+
+ In addition to being a URI, additional constraints are placed on this keyword
+ depending on whether it is being used in a parent schema or a subschema.
+
+
+
+
+
+ In parent schemas, the value of "id" SHOULD be an absolute URI. This URI
+ SHOULD have either no fragment part, or an empty fragment part.
+
+
+
+ If the two requirements above are not fulfilled, implementations SHOULD NOT
+ consider this URI as being the schema location, as this URI is effectively
+ unreferenceable from any other schema.
+
+
+
+ In addition, if the JSON Schema has been fetched from a URI which differs
+ from this schema's "id" keyword value, implementations SHOULD consider that
+ the schema location is the URI having been used to fetch the schema.
+
+
+
+
+
+
+ In subschemas, the value of "id" SHOULD be a path component. This path
+ component MUST NOT start with a slash. In a same schema, there MUST NOT be
+ two identical values for "id" in different subschemas.
+
+
+
+ If the two requirements above are not fulfilled, implementations SHOULD fail
+ to look up a subschema by this id (see next section).
+
+
+
+
+
+
+
+
+ A JSON Schema with a keyword named "$ref" MUST be handled as a JSON Reference,
+ as described by --FIXME: link to draft--. Implementations MUST follow the rules
+ defined by this specification. Among other rules, it is important to note that
+ when processing a JSON Reference, other schema keywords, if any, SHALL be
+ ignored.
+
+
+
+ In addition, JSON Schema defines the following extensions to JSON Reference:
+
+
+
+ when an initial JSON Reference is encountered, implementations MUST resolve
+ the reference's URI against the current schema's URI, as described in FIXME;
+ if the fragment is not a valid JSON Pointer (FIXME: link to draft),
+ implementations SHOULD try and find a subschema with an id by the same value in
+ the target schema.
+
+
+
+ Handling JSON Reference processing failures, for whatever reason (unable to
+ dereference URI, inappropriate content at URI, or JSON Reference loop), is out
+ of the normative scope of this document.
+
+
+
+
+
+
+
+
+
+
+ A JSON instance MAY be correlated to a JSON Schema. This correlation MAY be
+ embodied witin existing protocol headers; failing that, a correlation MAY be
+ embodied in a JSON instance if this instance is an object, by means of a member
+ named "describedby", and provided that this member not be used for any other
+ purpose by the instance.
+
+
+
+ In addition:
+
+
+
+ if the protocol also carries media type information (by means, for instance,
+ of a "Content-Type" header), an instance MUST be one of "application/json" or
+ any other subtype;
+ implementations SHOULD prefer correlation information carried by the protocol
+ in preference to similar information embodied within JSON object instances.
+
+
+
+ Should both scenarios above be inapplicable, due either to the absence of, or
+ restrictions on, protocol headers, or to the JSON instance not being an object
+ value, such a correlation is out of the normative scope of this specification.
+
+
+
+
+
+ Provided that this particular member is not used for other purposes (see
+ above), a JSON object instance MAY use a "describedby" member to correlate this
+ instance to a given JSON Schema.
+
+
+
+ Should such a member be present for correlation purposes:
+
+
+
+ its value MUST be a JSON string;
+ this string MUST be a valid URI;
+ this URI MUST resolve to a valid JSON Schema.
+
+
+
+ Should any of the provisions defined above fail, implementations SHOULD NOT
+ attempt to correlate with the "describedby" member value.
+
+
+
+
+
+
+ It is acknowledged by this specification that the majority of interactive JSON
+ Schema processing will be over HTTP. This section therefore gives
+ recommendations for materializing an instance/schema correlation using
+ mechanisms currently available for this protocol.
+
+
+
+
+ It is RECOMMENDED that a MIME type parameter by the name of "profile" be
+ appended to the "Content-Type" header of the instance being processed. If
+ present, the value of this parameter MUST be a valid URI, and this URI
+ SHOULD resolve to a valid JSON Schema.
+
+
+
+ An example of such a header would be:
+
+
+
+
+
+
+
+
+
+
+
+
+ When using the "Link" header, it is RECOMMENDED that a relationship by the
+ name "describedby" be used, as defined by RFC 2048, section 19.6.2.4 (FIXME:
+ make real link). Note: it should be remembered that relationship values are
+ case insensitive, so "describedBy" is just as valid a relationship as
+ "describedby".
+
+
+
+ The target URI of the "Link" header SHOULD be dereferenceable; the content
+ referenced by this URI MUST be a valid JSON Schema.
+
+
+
+ An example of such a header would be:
+
+
+
+
+; rel="describedby"
+]]>
+
+
+
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is defined as follows:
+
+
+
+ type name: application;
+ subtype name: schema+json;
+ required parameters: profile.
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+ JSON Pointer
+
+ ForgeRock US, Inc.
+
+
+ SitePen (USA)
+
+
+
+
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
+
+
+ TODO
+
+
+
+
From eea18f9fa611ebde1b03e2580fb2e2622e588dd3 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Fri, 14 Sep 2012 14:35:29 +0200
Subject: [PATCH 0092/1659] New version of the spec
v2:
* remove unneeded references;
* define JSON equality;
* introduce "location", "subId";
* discourage schema addressing by the means of "id".
---
proposals/json-schema-core.xml | 348 +++++++++++++++++----------------
1 file changed, 180 insertions(+), 168 deletions(-)
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index cb808aa3..eded37e6 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -1,18 +1,7 @@
-
-
-
-
-
-
-
-
-
-
-
-
+
+
]>
@@ -24,13 +13,35 @@
JSON Schema: core definitions and purposes
-
+ fgaliegue@gmail.com
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
Internet Engineering Task ForceJSON
@@ -65,9 +76,8 @@
- This document also defines inter schema relationships: how a particular JSON Schema
- is identified (in a possibly unique way), how to address a JSON Schema in full, or
- only parts of it.
+ This document also defines the mechanisms used for JSON Schema identification and
+ referencing.
@@ -88,7 +98,7 @@
-
+
@@ -101,7 +111,7 @@
-
+
JSON Schemas can be nested, as in this example:
@@ -109,11 +119,11 @@
In this example, the enclosing schema of both "nested" and "alsonested" is
- "parent". The schema with name "parent" is said to be a parent schema because it
+ "root". The schema with title "root" is said to be a root schema because it
is not enclosed within another schema.
@@ -145,9 +155,40 @@
+
+
+ Two JSON values are said to be equal if and only if:
+
+
+
+ both are nulls; or
+ both are booleans or strings, and have the same value; or
+ both are numbers, and have the same JSON reprensetation; or
+ both are arrays, and:
+
+ have the same number of elements; and
+ elements at the same index are equal according to this definition;
+ or
+
+
+ both are objects, and:
+
+ have the same set of members; and
+ values for a same member are equal according to this definition.
+
+
+
+
+
+
+ Note about numbers: the two JSON number values, 1.0 and 1, for instance, are
+ mathematically equivalent; however they are NOT equal, since their JSON
+ representation differs.
+
+
- An instance is any JSON value which is being processed by a JSON Schema. The
+ An instance is any JSON value being processed by a JSON Schema. The
specification may also refer to an instance as a JSON instance.
@@ -187,11 +228,10 @@
It is acknowledged that JSON values can be of any type defined by the JSON
- specification. As such, JSON Schema does not mandate that the instance being
- processed be of a particular type: JSON Schema can process any JSON value,
- including null. It is the domain of JSON Schema validation to add useful
- constraints to the structure and, optionally, semantics, of the JSON instance
- being processed.
+ specification. As such, JSON Schema does not mandate that an instance be of a
+ particular type: JSON Schema can process any JSON value, including null. It is
+ the domain of JSON Schema validation to add useful constraints to the structure
+ and, optionally, semantics, of the JSON instance being processed.
JSON Schema is agnostic with regards to both protocols and programming
@@ -201,188 +241,171 @@
-
+
- This section describes the following:
+ This section describes the available mechanisms for identifying the schema in a
+ unique way: its location, but also the version of the JSON Schema specification
+ it is written against.
+
-
- available mechanisms for identifying the schema in a unique way: its
- location, but also the version of the JSON Schema specification it is written
- against;
- available mechanisms for addressing a JSON Schema, or a specific subschema in
- a JSON Schema.
-
-
-
-
+
- The three keywords defined for this purpose are "$ref", "id" and "$schema".
+ TODO -- core schema, hyper schema, etc etc...
-
-
-
-
-
- The value for these keywords MUST be JSON strings. These strings MUST be
- valid URIs, as defined in FIXME.
-
-
-
+
+
+ A root schema MAY be uniquely identified by the presence of a "location"
+ keyword. This keyword's value MUST be a string, and this string MUST be a URI;
+ the URI MUST be absolute, and MUST have either no fragment, or an empty
+ fragment.
+
- This keyword serves two purposes:
+ This keyword MUST NOT be used in subschemas.
-
- implementations use this value to determine which version of the draft this
- schema is written against;
- it is also a link to a resource which is itself a JSON Schema, against which
- the schema MUST validate successfully.
-
+
+
- This keyword SHOULD NOT be used in subschemas. In the event that it is
- encountered in a subschema, implementations SHALL ignore it.
+ Within JSON Schemas, a subschema MAY be identified by the presence of a "subId"
+ keyword. This keyword's value MUST be a string.
- If a schema does not have a "$schema" keyword, implementations SHOULD consider
- that the schema is written against the most current published version of the
- JSON Schema specification.
+ This string MUST NOT be empty. It MUST NOT start with a solidus (/). A same
+ string MUST NOT be used more than once in a same root schema.
-
-
-
-
- In addition to being a URI, additional constraints are placed on this keyword
- depending on whether it is being used in a parent schema or a subschema.
+ This keyword MAY also be used in a root schema.
-
-
-
-
- In parent schemas, the value of "id" SHOULD be an absolute URI. This URI
- SHOULD have either no fragment part, or an empty fragment part.
-
-
-
- If the two requirements above are not fulfilled, implementations SHOULD NOT
- consider this URI as being the schema location, as this URI is effectively
- unreferenceable from any other schema.
-
-
-
- In addition, if the JSON Schema has been fetched from a URI which differs
- from this schema's "id" keyword value, implementations SHOULD consider that
- the schema location is the URI having been used to fetch the schema.
-
-
-
-
-
-
- In subschemas, the value of "id" SHOULD be a path component. This path
- component MUST NOT start with a slash. In a same schema, there MUST NOT be
- two identical values for "id" in different subschemas.
-
-
-
- If the two requirements above are not fulfilled, implementations SHOULD fail
- to look up a subschema by this id (see next section).
-
-
-
-
+
- A JSON Schema with a keyword named "$ref" MUST be handled as a JSON Reference,
- as described by --FIXME: link to draft--. Implementations MUST follow the rules
- defined by this specification. Among other rules, it is important to note that
- when processing a JSON Reference, other schema keywords, if any, SHALL be
- ignored.
+ The value for this keyword MUST be a string. This string MUST be a URI.
- In addition, JSON Schema defines the following extensions to JSON Reference:
+ For backwards compatibility, JSON Schemas MAY use the "id" keyword for
+ identification purposes. However, due to numerous ambiguity concerns, this is
+ NOT RECOMMENDED.
+
+ Schema authors willing to use "id" for identification purposes SHOULD follow the
+ following recommendations:
+
+
- when an initial JSON Reference is encountered, implementations MUST resolve
- the reference's URI against the current schema's URI, as described in FIXME;
- if the fragment is not a valid JSON Pointer (FIXME: link to draft),
- implementations SHOULD try and find a subschema with an id by the same value in
- the target schema.
+ in root schemas, "id" SHOULD obey the same constraints as described for
+ "location";
+ if used in subschemas, "id" SHOULD be a fragment-only URI.
- Handling JSON Reference processing failures, for whatever reason (unable to
- dereference URI, inappropriate content at URI, or JSON Reference loop), is out
- of the normative scope of this document.
+ In any event, implementations SHOULD NOT expect peer implementations to support
+ JSON Schema identification by the means of the "id" keyword.
-
-
+
- A JSON instance MAY be correlated to a JSON Schema. This correlation MAY be
- embodied witin existing protocol headers; failing that, a correlation MAY be
- embodied in a JSON instance if this instance is an object, by means of a member
- named "describedby", and provided that this member not be used for any other
- purpose by the instance.
+ JSON Schema referencing is done using JSON Reference (FIXME: link to draft).
- In addition:
+ In addition, JSON Schema extends the specification so as to use a dedicated
+ fragment resolution scheme, by the name "json-schema". This mechanism is
+ explained below. FIXME: RFC for fragment-resolution?
+
-
- if the protocol also carries media type information (by means, for instance,
- of a "Content-Type" header), an instance MUST be one of "application/json" or
- any other subtype;
- implementations SHOULD prefer correlation information carried by the protocol
- in preference to similar information embodied within JSON object instances.
-
+
- Should both scenarios above be inapplicable, due either to the absence of, or
- restrictions on, protocol headers, or to the JSON instance not being an object
- value, such a correlation is out of the normative scope of this specification.
+ Implementations SHOULD determine the URI of a schema as follows:
+
+
+ if the schema was loaded from an absolute URI with no fragment part, or an
+ empty fragment part, then the URI of the schema SHOULD be considered to be the
+ loading URI, regardless of the values of "location" or "id";
+ in any other situations:
+
+ if the "location" keyword is present and conforms to this
+ specification, the value of this keyword SHOULD be considered as the
+ schema URI;
+ if the "id" keyword is present and conforms to FIXME: crosslink, the
+ value of this keyword MAY be considered as the schema URI;
+ otherwise, implementations SHOULD choose an arbitrary URN, or the
+ empty URI.
+
+
+
+
-
+
- Provided that this particular member is not used for other purposes (see
- above), a JSON object instance MAY use a "describedby" member to correlate this
- instance to a given JSON Schema.
+ When encountering a JSON Reference, implementations MUST follow the rules
+ defined by the JSON Reference draft. In addition:
+
+ if resolution of the JSON Reference fails, or the dereferenced content is not
+ a JSON Schema, it is RECOMMENDED that implementations consider this a failure
+ and stop JSON Schema processing;
+ implementations MUST perform fragment resolution as per the mechanism
+ described below.
+
+
+
+
- Should such a member be present for correlation purposes:
+ The "json-schema" fragment resolution scheme is an extension to the
+ "json-pointer" fragment resolution scheme and works as follows:
- its value MUST be a JSON string;
- this string MUST be a valid URI;
- this URI MUST resolve to a valid JSON Schema.
+ implementations first try and treat this fragment as a JSON Pointer; if
+ successful, they try and dereference that pointer against the current JSON
+ Schema;
+ if the fragment is not a JSON Pointer, implementations try and find in the
+ JSON Schema a subschema with a "subId" keyword, which value is strictly equal to
+ the fragment's URI-decoded string value.
+
+
+
+
+
+
+ A JSON instance MAY be correlated to one, or even several, JSON Schemas. This
+ correlation MAY be embodied witin existing protocol headers.
+
+
+
+ In addition, if the protocol also carries media type information (by means, for
+ instance, of a "Content-Type" header), an instance MUST be one of
+ "application/json" or any other subtype.
+
- Should any of the provisions defined above fail, implementations SHOULD NOT
- attempt to correlate with the "describedby" member value.
+ Should the scenario above be inapplicable, due either to the absence of, or
+ restrictions on, protocol headers, such a correlation is out of the normative
+ scope of this specification.
@@ -421,15 +444,14 @@ Content-Type: application/my-media-type+json;
When using the "Link" header, it is RECOMMENDED that a relationship by the
- name "describedby" be used, as defined by RFC 2048, section 19.6.2.4 (FIXME:
+ name "describedBy" be used, as defined by RFC 2048, section 19.6.2.4 (FIXME:
make real link). Note: it should be remembered that relationship values are
case insensitive, so "describedBy" is just as valid a relationship as
- "describedby".
+ "DESCRIBEDBY".
- The target URI of the "Link" header SHOULD be dereferenceable; the content
- referenced by this URI MUST be a valid JSON Schema.
+ The target URI of the "Link" header SHOULD be a valid JSON Schema.
@@ -439,7 +461,7 @@ Content-Type: application/my-media-type+json;
; rel="describedby"
+Link: ; rel="describedBy"
]]>
@@ -458,6 +480,7 @@ Link: ; rel="describedby"
type name: application;subtype name: schema+json;required parameters: profile.
+ FIXME: fragment resolution?
@@ -466,13 +489,9 @@ Link: ; rel="describedby"
- &rfc2045;
- &rfc2119;
- &rfc3339;
- &rfc3986;
- &rfc4287;
+ &RFC2119;
+ target="http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-04">
JSON Pointer
@@ -486,14 +505,7 @@ Link: ; rel="describedby"
- &rfc2616;
- &rfc4627;
- &rfc5226;
- &iddiscovery;
- &uritemplate;
- &linkheader;
- &html401;
- &css21;
+ &RFC4627;
From 9b28bd6513235ed96f66fa98ea0243c3c8331a6d Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 15 Sep 2012 14:05:33 +0200
Subject: [PATCH 0093/1659] JSON Schema core validation spec
---
proposals/json-schema-validation.xml | 1212 ++++++++++++++++++++++++++
1 file changed, 1212 insertions(+)
create mode 100644 proposals/json-schema-validation.xml
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
new file mode 100644
index 00000000..d2b982ab
--- /dev/null
+++ b/proposals/json-schema-validation.xml
@@ -0,0 +1,1212 @@
+
+
+
+]>
+
+
+
+
+
+
+
+
+ JSON Schema: instance validation
+
+
+
+ fgaliegue@gmail.com
+
+
+
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ validation
+
+
+
+ JSON Schema (application/schema+json) has several purposes, one of which is instance
+ validation. This validation can be non interactive. This specification describes
+ schema keywords dedicated to validation purposes, what value these keywords should
+ have and how to validate JSON instances against these keywords.
+
+
+
+
+
+
+
+ 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.
+
+
+
+ Validation is primarily concerned about structural validation of instances.
+ Extensions also exist to perform semantic analysis, but these are part of another
+ 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.
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ 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 as a part of validation mechanics. These regular expressions SHOULD
+ be valid according to the ECMA 262 regular expression dialect.
+
+
+
+ However, regular expression dialects vary, sometimes widely, between programming
+ languages, to the extent that a same regular expression token may behave
+ differently between programming languages. For instance, "\w", which is a common
+ idiom used to match a character which is "part of a word", will only match
+ letters, digits and the underscore in the US-ASCII character set in Java,
+ whereas it matches any Unicode alphanumeric character, plus the underscore, in
+ ECMA 262.
+
+
+
+ For this reason, if regular expressions need to be used in a schema meant to be
+ used by peer implementations, it is RECOMMENDED that schema authors limit
+ themselves to the following regular expression tokens:
+
+
+
+ individual Unicode characters, as defined by the JSON RFC (FIXME_LINK);
+ simple character classes ([abc]), range character classes ([a-z]);
+ quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), "{x}"
+ where "x" is an integer (exactly x occurrences), "{x,y}" where "x" and "y" are
+ integers (at least x, at most y, occurrences);
+ the beginning-of-input ("^") and end-of-input ("$") anchors;
+ grouping ("(...)") and alternation ("|").
+
+
+
+ Schema authors choosing to use other regular expression features in their
+ schemas SHOULD NOT expect peer implementations to support these features.
+
+
+
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+ Additionally, validation of some keywords are influenced by the presence of
+ other keywords. In this case, all these keywords will be grouped in the same
+ section.
+
+
+
+ Finally, some keywords, if absent, MAY be regarded by implementations as having
+ a default value. In this case, the default value will be mentioned.
+
+
+
+
+
+
+ It should be noted that keywords with the possibility to validate container
+ instances only validate this instance's structure. They do not, in and out of
+ them, validate children instances. Some of these keywords do, however,
+ influence the schema, or schemas, which a child instance must validate.
+
+
+
+ The algorithms to determine the schema, or schemas, which a child instance must
+ validate against are explained in separate sections (FIXME_LINK).
+
+
+
+ It is RECOMMENDED that implementations do not validate a container instance's
+ children until the container instance itself has validated successfully against
+ all relevant keywords.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be a JSON number. This number MUST be
+ strictly greater than 0.
+
+
+
+
+
+ A numeric instance is valid against "divisibleBy" if and only if the
+ remainder of the division of the instance by this keyword's value is
+ exactly 0.
+
+
+
+
+
+
+
+
+
+ The value for the "maximum" keyword MUST be a JSON number. The value for
+ the "exclusiveMaximum" keyword MUST be a boolean.
+
+
+
+ If "exclusiveMaximum" is present, "maximum" MUST also be present.
+
+
+
+
+
+ Successful validation depends on the presence and value of
+ "exclusiveMaximum":
+
+
+
+ if "exclusiveMaximum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is greater than, or equal
+ to, the value of "maximum";
+ if "exclusiveMaximum" is present and has boolean value true, the the
+ instance is valid if and only if it is strictly greater than the value
+ of "maximum".
+
+
+
+
+
+ "exclusiveMaximum", if absent, may be considered as being present with
+ boolean value false.
+
+
+
+
+
+
+
+
+ The value for the "minimum" keyword MUST be a JSON number. The value for
+ the "exclusiveMinimum" keyword MUST be a boolean.
+
+
+
+ If "exclusiveMinimum" is present, "minimum" MUST also be present.
+
+
+
+
+
+ Successful validation depends on the presence and value of
+ "exclusiveMinimum":
+
+
+
+ if "exclusiveMinimum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is lower than, or equal
+ to, the value of "minimum";
+ if "exclusiveMinimum" is present and has boolean value true, the the
+ instance is valid if and only if it is strictly lower than the value
+ of "minimum".
+
+
+
+
+
+ "exclusiveMinimum", if absent, may be considered as being present with
+ boolean value false.
+
+
+
+
+
+
+
+
+
+
+
+
+ The value for 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 and only 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 FIXME_LINK.
+
+
+
+
+
+
+
+
+
+ The value for 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 and only 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 FIXME_LINK.
+
+
+
+
+
+ "minLength", if absent, may be considered as being present with integer
+ value 0.
+
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be a string. This string MUST be a valid
+ regular expression, according to the ECMA 262 regular expression
+ dialect, as defined by FIXME_LINK.
+
+
+
+
+
+ A string instance is considered valid if and only if the regular
+ expression matches the instance successfully.
+
+
+
+
+
+
+ Implementations MUST NOT consider that regular expressions are
+ surrounded by either the beginning-of-input ("^") or end-of-input ("$")
+ anchors. This means that, for instance, "x" matches "exercise".
+
+
+ The ECMA 262 regular expression dialect has poor programming language
+ support; the only programming language with native ECMA 262 regular
+ expression support is JavaScript. It is therefore RECOMMENDED that
+ schema authors limit themselves to the regular expression feature set
+ defined in section FIXME_LINK.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 item keyword's value 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,
+ elements 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:
+
+
+
+ if "items" is not present, or its value is an object, validation of
+ the instance always succeeds, regardless of the value of
+ "additionalItems";
+ if the value of "additionalItems" is boolean value true or an object,
+ validation of the instance always succeeds;
+ if the value of additionalItems is boolean value false and the value
+ of items is an array (which is must be at this point), the instance is
+ valid if and only if its number of elements is less than, or equal to,
+ the number of elements in the array value of items.
+
+
+
+
+
+ The following example covers the case where "additionalItems" has
+ boolean value false and "items" has an array value, since this is the
+ only situation under which an instance may fail to validate
+ successfully.
+
+
+
+ This is an example schema:
+
+
+
+
+
+
+ With this schema, the following instances are valid:
+
+
+
+ [] (an empty array),
+ [ [ 1, 2, 3, 4 ], [ 5, 6, 7, 8 ] ],
+ [ 1, 2, 3 ];
+
+
+
+ the following instances are invalid:
+
+
+
+ [ 1, 2, 3, 4 ],
+ [ null, { "a": "b" }, true, 31.000002020013 ]
+
+
+
+
+
+ If either keyword is absent, it may be considered present with an empty
+ schema.
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+
+
+ An array instance is valid against "maxItems" if and only if its number
+ of elements is less than, or equal to, the value of this keyword.
+
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+
+
+ An array instance is valid against "minItems" if and only if its number
+ of elements 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, then the instance validates
+ successfully. If it has boolean value true, then the instance validates
+ successfully if and only if all of its elements are unique. In other
+ words, no two elements of the array instance should be equal as per the
+ definition in FIXME_LINK.
+
+
+
+
+
+ If not present, this keyword may be considered present with boolean
+ false as a value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+
+
+ An object instance is valid against "maxProperties" if and only if its
+ number of members is less than, or equal to, the value of this keyword.
+
+
+
+
+
+
+
+
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+
+
+ An object instance is valid against "minProperties" if and only if its
+ number of members 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 for 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 and only if the set
+ of its member names contains all elements in this keyword's array.
+
+
+
+
+
+
+ Against this schema:
+
+
+
+
+
+
+ the following instances are valid:
+
+
+
+ { "a": 1, "b": 2 };
+ { "a": 1, "b": 2, "c": 3 };
+
+
+
+ the following instances are invalid:
+
+
+
+ {} (the empty object);
+ { "b": 2 } (required member name "a" is missing).
+
+
+
+
+
+
+
+
+
+ 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 member name of
+ this object MUST be a valid regular expression, according to the ECMA
+ 262 regular expression dialect, as defined by FIXME_LINK. Each 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 its value is boolean true or a schema, validation succeeds;
+ if its value is boolean false, the algorithm to determine validation
+ success is described in the next section.
+
+
+
+
+
+ In this case, validation of the instance depends on the member names of
+ "properties" and "patternProperties". In this section, member names of
+ "patternProperties" will be called regexes for convenience.
+
+
+
+ The first step is to collect the following sets:
+
+
+
+ The set of member names of the instance to validate.
+ The set of member names from "properties".
+ The set of regexes from "patternProperties".
+
+
+
+ Having collected these three sets, the process is as follows:
+
+
+
+ remove from "s" all members of "p", if any;
+ for each regex in "pp", remove all members of "s" which this regex
+ matches.
+
+
+
+ Validation of the instance succeeds if and only if, after these two
+ steps, set "s" is empty.
+
+
+
+
+
+
+ This schema will be used as an example:
+
+
+
+
+
+
+
+
+
+ This is the instance to validate:
+
+
+
+
+
+
+
+
+
+ The three sets are:
+
+
+
+ { "p1", "p2", "a32&o", "", "finance", "apple" }
+ { "p1" }
+ { "p", "\\d" }
+
+
+
+ Applying the two steps of the algorithm:
+
+
+
+ after the first step, "p1" is removed from "s";
+ after the second step, "p2", "a32&o" and "apple" are removed from
+ "s".
+
+
+
+ The set still contains two elements, "" and "finance". Validation
+ therefore fails.
+
+
+
+
+
+
+
+
+
+ This keyword's value MUST be an object. Values for this object MUST be
+ either of a string, an array or an object. If the value is an object,
+ it MUST be a valid JSON Schema.
+
+
+
+ If the value is an array:
+
+
+
+ this array MUST have at least one element;
+ elements of this array MUST be strings;
+ elements of this array MUST be unique.
+
+
+
+
+
+ For each member name in the object instance with an equivalent member
+ name in "dependencies":
+
+
+
+ if the value in "dependencies" is an object, therefore a schema, then
+ the object instance is considered valid if and only if it also validates
+ successfully against this schema (note: the object instance itself, not
+ the value of that particular member);
+ if the value in "dependencies" is a string or an array of strings,
+ this (these) strings should be considered as member name(s), and the
+ object instance is required to have members by the same name(s) in order
+ to validate successfully.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 and only if
+ its value is exactly equal to one of the elements in this keyword's
+ array value, according to the definition in FIXME_LINK.
+
+
+
+
+
+
+
+
+
+ The value of this keyword MUST be a string or an array. If the value is
+ an array, elements of this array MUST be unique. This keyword's string
+ value, or array element values, MUST be either of:
+
+
+
+ one of the seven primitive types defined by FIXME_LINK; or
+ "any", which is equivalent to all seven primitive types.
+
+
+
+
+
+ An instance matches successfully if and only if its primitive type, as
+ defined in FIXME_LINK, is one of the primitive types allowed by this
+ keyword's value. 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 and only 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 and only if
+ it validates successfully against at least one 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 and only 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 and only if it fails to
+ validate successfully against the schema defined by this keyword.
+
+
+
+
+
+
+
+
+
+
+
+
+ Calculating the schema, or schemas, a child instance must validate against is
+ influenced by the following, in addition to the container instance type:
+
+
+
+ the container instance type;
+ the child instance's defining characteristic in the container instance;
+ the value of keywords implied in the calculation.
+
+
+
+ In addition, it is important that if one or more keyword(s) implied in the
+ calculation are not defined, it be considered present with its default value,
+ which will be recalled in this section.
+
+
+
+
+
+
+
+ The defining characteristic of the child instance is this instance's index
+ in the array instance. 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.
+
+
+
+
+
+
+
+ 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 of the child
+ instance:
+
+
+
+ if the index is less than, or equal to, the maximum index in the
+ "items" array, then the child instance must be valid against the
+ corresponding schema in the "items" array;
+ otherwise, it must be valid against the schema defined by
+ "additionalItems".
+
+
+
+
+
+
+
+
+
+
+ The defining characteristic of the child instance of an object is the member
+ name this child is associated to.
+
+
+
+
+
+ The three keywords implied in this calculation are "properties",
+ "patternProperties" and "additionalProperties".
+
+
+
+ If "properties" of "patternProperties" are absent, they are considered
+ present with an empty object as a value (note, an empty object, NOT an empty
+ schema).
+
+
+
+ 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:
+
+
+
+ The member name the child instance is associated to.
+ The set of member names from "properties", if any.
+ The set of member names from "patternProperties", if
+ any. Member names from this set will be called regexes for convenience.
+ The set of schemas the child instance must validate
+ against.
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ This specification does not have any influence with regards to IANA.
+
+
+
+
+
+
+
+
+ &RFC2119;
+
+
+ &RFC4627;
+
+
+
+ TODO
+
+
+
+
From bfc89e57c73d0c91719d408946015b0de41ff8d2 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 15 Sep 2012 14:07:34 +0200
Subject: [PATCH 0094/1659] Add text versions of XML source files
---
proposals/json-schema-core.txt | 560 ++++++++++++
proposals/json-schema-validation.txt | 1176 ++++++++++++++++++++++++++
2 files changed, 1736 insertions(+)
create mode 100644 proposals/json-schema-core.txt
create mode 100644 proposals/json-schema-validation.txt
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
new file mode 100644
index 00000000..63991144
--- /dev/null
+++ b/proposals/json-schema-core.txt
@@ -0,0 +1,560 @@
+
+
+
+Internet Engineering Task Force fge. Galiegue
+Internet-Draft
+Intended status: Informational K. Zyp, Ed.
+Expires: March 19, 2013 SitePen (USA)
+ G. Court
+ September 15, 2012
+
+
+ JSON Schema: core definitions and purposes
+ json-schema-core
+
+Abstract
+
+ JSON Schema defines the media type "application/schema+json", a JSON
+ based format for defining the structure of JSON data. JSON Schema
+ provides a contract for what JSON data is required for a given
+ application and how to interact with it. JSON Schema is intended to
+ define validation, documentation, hyperlink navigation, and
+ interaction control of JSON data.
+
+Status of This Memo
+
+ 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 March 19, 2013.
+
+Copyright Notice
+
+ Copyright (c) 2012 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
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 1]
+
+Internet-Draft JSON Schema September 2012
+
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
+ 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
+ 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
+ 3.2. Enclosing schema, root schema . . . . . . . . . . . . . . 3
+ 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
+ 5. JSON Schema identification . . . . . . . . . . . . . . . . . . 6
+ 5.1. Purpose of this section . . . . . . . . . . . . . . . . . 6
+ 5.2. Meta-schema identification using $schema . . . . . . . . . 6
+ 5.3. Root schema identification . . . . . . . . . . . . . . . . 6
+ 5.4. Subschema identification . . . . . . . . . . . . . . . . . 6
+ 5.5. Identification using \\"id\\" . . . . . . . . . . . . . . 6
+ 6. JSON Schema referencing . . . . . . . . . . . . . . . . . . . 7
+ 6.1. Purpose of this section . . . . . . . . . . . . . . . . . 7
+ 6.2. Determining the URI of a schema . . . . . . . . . . . . . 7
+ 6.3. Loading schemas using JSON Reference . . . . . . . . . . . 8
+ 6.4. The "json-schema" fragment resolution scheme . . . . . . . 8
+ 7. Schema/Instance Association . . . . . . . . . . . . . . . . . 8
+ 7.1. Purpose of this section . . . . . . . . . . . . . . . . . 8
+ 7.2. Recommended correlation mechanisms for use with the
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 8
+ 7.2.1. Correlation by means of the "Content-Type" header . . 9
+ 7.2.2. Correlation by means of the "Link" header . . . . . . 9
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 2]
+
+Internet-Draft JSON Schema September 2012
+
+
+1. Introduction
+
+ JSON Schema is a JSON media type for defining the structure of JSON
+ data. JSON Schema provides a contract for what JSON data is required
+ for a given application and how to interact with it. JSON Schema is
+ intended to define validation, documentation, hyperlink navigation,
+ and interaction control of JSON data.
+
+ This document defines the core terminology used by JSON Schema.
+ Other linked specifications, which expand on a particular role of
+ JSON Schema, will use that terminology.
+
+ This document also defines the mechanisms used for JSON Schema
+ identification and referencing.
+
+2. Conventions and Terminology
+
+ 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].
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element",
+ "object", "array", "number", "string", "boolean", "true", "false",
+ and "null" in this document are to be interpreted as defined in RFC
+ 4627 [RFC4627].
+
+3. Core terminology of JSON Schema
+
+3.1. JSON Schema, keywords
+
+ A JSON Schema is a JSON document, and that document MUST be an
+ object. Object members of a JSON Schema are called keywords, or
+ schema keywords.
+
+ A JSON Schema MAY be empty.
+
+3.2. Enclosing schema, root schema
+
+ JSON Schemas can be nested, as in this example:
+
+
+ {
+ "title": "root",
+ "otherschema": {
+ "title": "nested",
+ "anotherschema": {
+ "title": "alsonested"
+ }
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 3]
+
+Internet-Draft JSON Schema September 2012
+
+
+ }
+ }
+
+
+ In this example, the enclosing schema of both "nested" and
+ "alsonested" is "root". The schema with title "root" is said to be a
+ root schema because it is not enclosed within another schema.
+
+3.3. JSON Schema primitive types
+
+ JSON Schema defines seven primitive types for JSON values:
+
+ array A JSON array.
+
+ boolean A JSON boolean (true or false).
+
+ integer A JSON number without a decimal part.
+
+ number Any JSON number. Number includes integer.
+
+ null The JSON null value.
+
+ object A JSON object.
+
+ string A JSON string.
+
+3.4. JSON value equality
+
+ Two JSON values are said to be equal if and only if:
+
+ both are nulls; or
+
+ both are booleans or strings, and have the same value; or
+
+ both are numbers, and have the same JSON reprensetation; or
+
+ both are arrays, and:
+
+ have the same number of elements; and
+
+ elements at the same index are equal according to this
+ definition; or
+
+ both are objects, and:
+
+ have the same set of members; and
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 4]
+
+Internet-Draft JSON Schema September 2012
+
+
+ values for a same member are equal according to this
+ definition.
+
+ Note about numbers: the two JSON number values, 1.0 and 1, for
+ instance, are mathematically equivalent; however they are NOT equal,
+ since their JSON representation differs.
+
+3.5. Instance
+
+ An instance is any JSON value being processed by a JSON Schema. The
+ specification may also refer to an instance as a JSON instance.
+
+4. Overview
+
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of JSON instances. JSON Schemas are
+ themselves written in JSON and include facilities for describing the
+ structure of JSON in terms of allowable values, descriptions, and
+ interpreting relations with other resources.
+
+ JSON Schema serves different purposes, which are summarized below.
+ Each purpose has a defined set of keywords which is described in its
+ own specification.
+
+ Documentation JSON Schema can be used to decorate either itself, or
+ instances, with descriptive text highlighting the schema's, or
+ instance's, purposes.
+
+ Hyperlinking JSON Schema can be used to associate an instance to a
+ Link Description Object, as defined by FIXME.
+
+ Validation JSON Schema can be used to validate the structure of an
+ instance. Keywords also exist for semantic analysis, although
+ implementations are not required to implement them.
+
+4.1. Design Considerations
+
+ JSON Schema provides a separate format for flexibly communicating how
+ a JSON value should be interpreted and/or validated, such that
+ clients can properly understand acceptable structures for, and/or
+ extract the needed information from, the JSON instance being
+ processed.
+
+ It is acknowledged that JSON values can be of any type defined by the
+ JSON specification. As such, JSON Schema does not mandate that an
+ instance be of a particular type: JSON Schema can process any JSON
+ value, including null. It is the domain of JSON Schema validation to
+ add useful constraints to the structure and, optionally, semantics,
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 5]
+
+Internet-Draft JSON Schema September 2012
+
+
+ of the JSON instance being processed.
+
+ JSON Schema is agnostic with regards to both protocols and
+ programming languages. In particular, this means that defining the
+ semantics of the client-server interface is dependent on the protocol
+ being used.
+
+5. JSON Schema identification
+
+5.1. Purpose of this section
+
+ This section describes the available mechanisms for identifying the
+ schema in a unique way: its location, but also the version of the
+ JSON Schema specification it is written against.
+
+5.2. Meta-schema identification using $schema
+
+ TODO -- core schema, hyper schema, etc etc...
+
+5.3. Root schema identification
+
+ A root schema MAY be uniquely identified by the presence of a
+ "location" keyword. This keyword's value MUST be a string, and this
+ string MUST be a URI; the URI MUST be absolute, and MUST have either
+ no fragment, or an empty fragment.
+
+ This keyword MUST NOT be used in subschemas.
+
+5.4. Subschema identification
+
+ Within JSON Schemas, a subschema MAY be identified by the presence of
+ a "subId" keyword. This keyword's value MUST be a string.
+
+ This string MUST NOT be empty. It MUST NOT start with a solidus (/).
+ A same string MUST NOT be used more than once in a same root schema.
+
+ This keyword MAY also be used in a root schema.
+
+5.5. Identification using \\"id\\"
+
+ The value for this keyword MUST be a string. This string MUST be a
+ URI.
+
+ For backwards compatibility, JSON Schemas MAY use the "id" keyword
+ for identification purposes. However, due to numerous ambiguity
+ concerns, this is NOT RECOMMENDED.
+
+ Schema authors willing to use "id" for identification purposes SHOULD
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+
+
+ follow the following recommendations:
+
+ in root schemas, "id" SHOULD obey the same constraints as
+ described for "location";
+
+ if used in subschemas, "id" SHOULD be a fragment-only URI.
+
+ In any event, implementations SHOULD NOT expect peer implementations
+ to support JSON Schema identification by the means of the "id"
+ keyword.
+
+6. JSON Schema referencing
+
+6.1. Purpose of this section
+
+ JSON Schema referencing is done using JSON Reference (FIXME: link to
+ draft).
+
+ In addition, JSON Schema extends the specification so as to use a
+ dedicated fragment resolution scheme, by the name "json-schema".
+ This mechanism is explained below. FIXME: RFC for fragment-
+ resolution?
+
+6.2. Determining the URI of a schema
+
+ Implementations SHOULD determine the URI of a schema as follows:
+
+ if the schema was loaded from an absolute URI with no fragment
+ part, or an empty fragment part, then the URI of the schema SHOULD
+ be considered to be the loading URI, regardless of the values of
+ "location" or "id";
+
+ in any other situations:
+
+ if the "location" keyword is present and conforms to this
+ specification, the value of this keyword SHOULD be considered
+ as the schema URI;
+
+ if the "id" keyword is present and conforms to FIXME:
+ crosslink, the value of this keyword MAY be considered as the
+ schema URI;
+
+ otherwise, implementations SHOULD choose an arbitrary URN, or
+ the empty URI.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+
+
+6.3. Loading schemas using JSON Reference
+
+ When encountering a JSON Reference, implementations MUST follow the
+ rules defined by the JSON Reference draft. In addition:
+
+ if resolution of the JSON Reference fails, or the dereferenced
+ content is not a JSON Schema, it is RECOMMENDED that
+ implementations consider this a failure and stop JSON Schema
+ processing;
+
+ implementations MUST perform fragment resolution as per the
+ mechanism described below.
+
+6.4. The "json-schema" fragment resolution scheme
+
+ The "json-schema" fragment resolution scheme is an extension to the
+ "json-pointer" fragment resolution scheme and works as follows:
+
+ implementations first try and treat this fragment as a JSON
+ Pointer; if successful, they try and dereference that pointer
+ against the current JSON Schema;
+
+ if the fragment is not a JSON Pointer, implementations try and
+ find in the JSON Schema a subschema with a "subId" keyword, which
+ value is strictly equal to the fragment's URI-decoded string
+ value.
+
+7. Schema/Instance Association
+
+7.1. Purpose of this section
+
+ A JSON instance MAY be correlated to one, or even several, JSON
+ Schemas. This correlation MAY be embodied witin existing protocol
+ headers.
+
+ In addition, if the protocol also carries media type information (by
+ means, for instance, of a "Content-Type" header), an instance MUST be
+ one of "application/json" or any other subtype.
+
+ Should the scenario above be inapplicable, due either to the absence
+ of, or restrictions on, protocol headers, such a correlation is out
+ of the normative scope of this specification.
+
+7.2. Recommended correlation mechanisms for use with the HTTP protocol
+
+ It is acknowledged by this specification that the majority of
+ interactive JSON Schema processing will be over HTTP. This section
+ therefore gives recommendations for materializing an instance/schema
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
+ correlation using mechanisms currently available for this protocol.
+
+7.2.1. Correlation by means of the "Content-Type" header
+
+ It is RECOMMENDED that a MIME type parameter by the name of "profile"
+ be appended to the "Content-Type" header of the instance being
+ processed. If present, the value of this parameter MUST be a valid
+ URI, and this URI SHOULD resolve to a valid JSON Schema.
+
+ An example of such a header would be:
+
+
+ Content-Type: application/my-media-type+json;
+ profile=http://example.com/my-hyper-schema
+
+
+7.2.2. Correlation by means of the "Link" header
+
+ When using the "Link" header, it is RECOMMENDED that a relationship
+ by the name "describedBy" be used, as defined by RFC 2048, section
+ 19.6.2.4 (FIXME: make real link). Note: it should be remembered that
+ relationship values are case insensitive, so "describedBy" is just as
+ valid a relationship as "DESCRIBEDBY".
+
+ The target URI of the "Link" header SHOULD be a valid JSON Schema.
+
+ An example of such a header would be:
+
+
+ Link: ; rel="describedBy"
+
+
+8. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is defined as follows:
+
+ type name: application;
+
+ subtype name: schema+json;
+
+ required parameters: profile.
+
+ FIXME: fragment resolution?
+
+9. References
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer", October 2011, <
+ http://tools.ietf.org/html/
+ draft-ietf-appsawg-json-pointer-04>.
+
+9.2. Informative References
+
+ [RFC4627] Crockford, D., "The application/json Media Type for
+ JavaScript Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+Appendix A. ChangeLog
+
+ TODO
+
+Authors' Addresses
+
+ Francis Galiegue
+
+ EMail: fgaliegue@gmail.com
+
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+ Gary Court
+ Calgary, AB
+ Canada
+
+ EMail: gary.court@gmail.com
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 10]
+
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
new file mode 100644
index 00000000..6b2d6583
--- /dev/null
+++ b/proposals/json-schema-validation.txt
@@ -0,0 +1,1176 @@
+
+
+
+Internet Engineering Task Force fge. Galiegue
+Internet-Draft
+Intended status: Informational K. Zyp, Ed.
+Expires: March 19, 2013 SitePen (USA)
+ G. Court
+ September 15, 2012
+
+
+ JSON Schema: instance validation
+ json-schema-validation
+
+Abstract
+
+ JSON Schema (application/schema+json) has several purposes, one of
+ which is instance validation. This validation can be non
+ interactive. This specification describes schema keywords dedicated
+ to validation purposes, what value these keywords should have and how
+ to validate JSON instances against these keywords.
+
+Status of This Memo
+
+ 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 March 19, 2013.
+
+Copyright Notice
+
+ Copyright (c) 2012 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
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 1]
+
+Internet-Draft JSON Schema September 2012
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
+ 3. Interoperability considerations . . . . . . . . . . . . . . . 4
+ 3.1. Validation of numeric instances . . . . . . . . . . . . . 4
+ 3.2. Regular expressions . . . . . . . . . . . . . . . . . . . 4
+ 4. General validation considerations . . . . . . . . . . . . . . 5
+ 4.1. Keywords and instance primitive types . . . . . . . . . . 5
+ 4.2. Validation of container instances . . . . . . . . . . . . 6
+ 5. Validation keywords sorted by instance types . . . . . . . . . 6
+ 5.1. Validation keywords for numeric instances (number and
+ integer) . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1.1. divisibleBy . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1.2. maximum and exclusiveMaximum . . . . . . . . . . . . . 6
+ 5.1.3. minimum and exclusiveMinimum . . . . . . . . . . . . . 7
+ 5.2. Validation keywords for strings . . . . . . . . . . . . . 7
+ 5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.3. Validation keywords for arrays . . . . . . . . . . . . . . 9
+ 5.3.1. additionalItems and items . . . . . . . . . . . . . . 9
+ 5.3.2. maxItems . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3.4. uniqueItems . . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. Validation keywords for objects . . . . . . . . . . . . . 11
+ 5.4.1. maxProperties . . . . . . . . . . . . . . . . . . . . 11
+ 5.4.2. minProperties . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.3. required . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.4. additionalProperties, properties and
+ patternProperties . . . . . . . . . . . . . . . . . . 13
+ 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 15
+ 5.5. Validation keywords for any instance type . . . . . . . . 16
+ 5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6. Calculating schemas which children instances must validate
+ against . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.1. Defining characteristic . . . . . . . . . . . . . . . 18
+ 6.2.2. Implied keywords and default values. . . . . . . . . . 18
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 2]
+
+Internet-Draft JSON Schema September 2012
+
+
+ 6.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 18
+ 6.3. Object values . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.3.1. Defining characteristic . . . . . . . . . . . . . . . 19
+ 6.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 19
+ 6.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 19
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 3]
+
+Internet-Draft JSON Schema September 2012
+
+
+1. Introduction
+
+ 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.
+
+ Validation is primarily concerned about structural validation of
+ instances. Extensions also exist to perform semantic analysis, but
+ these are part of another 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.
+
+2. Conventions and Terminology
+
+ 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.
+
+3. Interoperability considerations
+
+3.1. Validation of numeric instances
+
+ 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.
+
+3.2. Regular expressions
+
+ Two validation keywords, "pattern" and "patternProperties", use
+ regular expressions as a part of validation mechanics. These regular
+ expressions SHOULD be valid according to the ECMA 262 regular
+ expression dialect.
+
+ However, regular expression dialects vary, sometimes widely, between
+ programming languages, to the extent that a same regular expression
+ token may behave differently between programming languages. For
+ instance, "\w", which is a common idiom used to match a character
+ which is "part of a word", will only match letters, digits and the
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 4]
+
+Internet-Draft JSON Schema September 2012
+
+
+ underscore in the US-ASCII character set in Java, whereas it matches
+ any Unicode alphanumeric character, plus the underscore, in ECMA 262.
+
+ For this reason, if regular expressions need to be used in a schema
+ meant to be used by peer implementations, it is RECOMMENDED that
+ schema authors limit themselves to the following regular expression
+ tokens:
+
+ individual Unicode characters, as defined by the JSON RFC
+ (FIXME_LINK);
+
+ simple character classes ([abc]), range character classes ([a-z]);
+
+ quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or
+ one), "{x}" where "x" is an integer (exactly x occurrences),
+ "{x,y}" where "x" and "y" are integers (at least x, at most y,
+ occurrences);
+
+ the beginning-of-input ("^") and end-of-input ("$") anchors;
+
+ grouping ("(...)") and alternation ("|").
+
+ Schema authors choosing to use other regular expression features in
+ their schemas SHOULD NOT expect peer implementations to support these
+ features.
+
+4. General validation considerations
+
+4.1. Keywords and instance primitive types
+
+ 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.
+
+ Additionally, validation of some keywords are influenced by the
+ presence of other keywords. In this case, all these keywords will be
+ grouped in the same section.
+
+ Finally, some keywords, if absent, MAY be regarded by implementations
+ as having a default value. In this case, the default value will be
+ mentioned.
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 5]
+
+Internet-Draft JSON Schema September 2012
+
+
+4.2. Validation of container instances
+
+ It should be noted that keywords with the possibility to validate
+ container instances only validate this instance's structure. They do
+ not, in and out of them, validate children instances. Some of these
+ keywords do, however, influence the schema, or schemas, which a child
+ instance must validate.
+
+ The algorithms to determine the schema, or schemas, which a child
+ instance must validate against are explained in separate sections
+ (FIXME_LINK).
+
+ It is RECOMMENDED that implementations do not validate a container
+ instance's children until the container instance itself has validated
+ successfully against all relevant keywords.
+
+5. Validation keywords sorted by instance types
+
+5.1. Validation keywords for numeric instances (number and integer)
+
+5.1.1. divisibleBy
+
+5.1.1.1. Valid values
+
+ The value for this keyword MUST be a JSON number. This number MUST
+ be strictly greater than 0.
+
+5.1.1.2. Conditions for successful validation
+
+ A numeric instance is valid against "divisibleBy" if and only if the
+ remainder of the division of the instance by this keyword's value is
+ exactly 0.
+
+5.1.2. maximum and exclusiveMaximum
+
+5.1.2.1. Valid values
+
+ The value for the "maximum" keyword MUST be a JSON number. The value
+ for the "exclusiveMaximum" keyword MUST be a boolean.
+
+ If "exclusiveMaximum" is present, "maximum" MUST also be present.
+
+5.1.2.2. Conditions for successful validation
+
+ Successful validation depends on the presence and value of
+ "exclusiveMaximum":
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+
+
+ if "exclusiveMaximum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is greater than, or
+ equal to, the value of "maximum";
+
+ if "exclusiveMaximum" is present and has boolean value true, the
+ the instance is valid if and only if it is strictly greater than
+ the value of "maximum".
+
+5.1.2.3. Default values
+
+ "exclusiveMaximum", if absent, may be considered as being present
+ with boolean value false.
+
+5.1.3. minimum and exclusiveMinimum
+
+5.1.3.1. Valid values
+
+ The value for the "minimum" keyword MUST be a JSON number. The value
+ for the "exclusiveMinimum" keyword MUST be a boolean.
+
+ If "exclusiveMinimum" is present, "minimum" MUST also be present.
+
+5.1.3.2. Conditions for successful validation
+
+ Successful validation depends on the presence and value of
+ "exclusiveMinimum":
+
+ if "exclusiveMinimum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is lower than, or
+ equal to, the value of "minimum";
+
+ if "exclusiveMinimum" is present and has boolean value true, the
+ the instance is valid if and only if it is strictly lower than the
+ value of "minimum".
+
+5.1.3.3. Default value
+
+ "exclusiveMinimum", if absent, may be considered as being present
+ with boolean value false.
+
+5.2. Validation keywords for strings
+
+5.2.1. maxLength
+
+5.2.1.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.2.1.2. Conditions for successful validation
+
+ A string instance is valid against this keyword if and only 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 FIXME_LINK.
+
+5.2.2. minLength
+
+5.2.2.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+5.2.2.2. Conditions for successful validation
+
+ A string instance is valid against this keyword if and only 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 FIXME_LINK.
+
+5.2.2.3. Default value
+
+ "minLength", if absent, may be considered as being present with
+ integer value 0.
+
+5.2.3. pattern
+
+5.2.3.1. Valid values
+
+ The value for this keyword MUST be a string. This string MUST be a
+ valid regular expression, according to the ECMA 262 regular
+ expression dialect, as defined by FIXME_LINK.
+
+5.2.3.2. Conditions for successful validation
+
+ A string instance is considered valid if and only if the regular
+ expression matches the instance successfully.
+
+5.2.3.3. Notes about regular expressions
+
+ Implementations MUST NOT consider that regular expressions are
+ surrounded by either the beginning-of-input ("^") or end-of-input
+ ("$") anchors. This means that, for instance, "x" matches
+ "exercise".
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
+ The ECMA 262 regular expression dialect has poor programming language
+ support; the only programming language with native ECMA 262 regular
+ expression support is JavaScript. It is therefore RECOMMENDED that
+ schema authors limit themselves to the regular expression feature set
+ defined in section FIXME_LINK.
+
+5.3. Validation keywords for arrays
+
+5.3.1. additionalItems and items
+
+5.3.1.1. Valid values
+
+ 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 item keyword's value 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, elements of this array MUST be objects, and each of these
+ objects MUST be a valid JSON Schema.
+
+5.3.1.2. Conditions for successful validation
+
+ Successful validation of an array instance with regards to these two
+ keywords is determined as follows:
+
+ if "items" is not present, or its value is an object, validation
+ of the instance always succeeds, regardless of the value of
+ "additionalItems";
+
+ if the value of "additionalItems" is boolean value true or an
+ object, validation of the instance always succeeds;
+
+ if the value of additionalItems is boolean value false and the
+ value of items is an array (which is must be at this point), the
+ instance is valid if and only if its number of elements is less
+ than, or equal to, the number of elements in the array value of
+ items.
+
+5.3.1.3. Example
+
+ The following example covers the case where "additionalItems" has
+ boolean value false and "items" has an array value, since this is the
+ only situation under which an instance may fail to validate
+ successfully.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
+ This is an example schema:
+
+
+ {
+ "items": [ {}, {}, {} ],
+ "additionalItems": false
+ }
+
+
+ With this schema, the following instances are valid:
+
+ [] (an empty array),
+
+ [ [ 1, 2, 3, 4 ], [ 5, 6, 7, 8 ] ],
+
+ [ 1, 2, 3 ];
+
+ the following instances are invalid:
+
+ [ 1, 2, 3, 4 ],
+
+ [ null, { "a": "b" }, true, 31.000002020013 ]
+
+5.3.1.4. Default values
+
+ If either keyword is absent, it may be considered present with an
+ empty schema.
+
+5.3.2. maxItems
+
+5.3.2.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+5.3.2.2. Conditions for successful validation
+
+ An array instance is valid against "maxItems" if and only if its
+ number of elements is less than, or equal to, the value of this
+ keyword.
+
+5.3.3. minItems
+
+5.3.3.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 10]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.3.3.2. Conditions for successful validation
+
+ An array instance is valid against "minItems" if and only if its
+ number of elements is greater than, or equal to, the value of this
+ keyword.
+
+5.3.3.3. Default value
+
+ If this keyword is not present, it may be considered present with a
+ value of 0.
+
+5.3.4. uniqueItems
+
+5.3.4.1. Valid values
+
+ The value of this keyword MUST be a boolean.
+
+5.3.4.2. Conditions for successful validation
+
+ If this keyword has boolean value false, then the instance validates
+ successfully. If it has boolean value true, then the instance
+ validates successfully if and only if all of its elements are unique.
+ In other words, no two elements of the array instance should be equal
+ as per the definition in FIXME_LINK.
+
+5.3.4.3. Default value
+
+ If not present, this keyword may be considered present with boolean
+ false as a value.
+
+5.4. Validation keywords for objects
+
+5.4.1. maxProperties
+
+5.4.1.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+5.4.1.2. Conditions for successful validation
+
+ An object instance is valid against "maxProperties" if and only if
+ its number of members is less than, or equal to, the value of this
+ keyword.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 11]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.4.2. minProperties
+
+5.4.2.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
+5.4.2.2. Conditions for successful validation
+
+ An object instance is valid against "minProperties" if and only if
+ its number of members is greater than, or equal to, the value of this
+ keyword.
+
+5.4.2.3. Default value
+
+ If this keyword is not present, it may be considered present with a
+ value of 0.
+
+5.4.3. required
+
+5.4.3.1. Valid values
+
+ The value for 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.
+
+5.4.3.2. Conditions for successful validation
+
+ An object instance is valid against this keyword if and only if the
+ set of its member names contains all elements in this keyword's
+ array.
+
+5.4.3.3. Example
+
+ Against this schema:
+
+
+ {
+ "required": [ "a", "b" ]
+ }
+
+
+ the following instances are valid:
+
+ { "a": 1, "b": 2 };
+
+ { "a": 1, "b": 2, "c": 3 };
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 12]
+
+Internet-Draft JSON Schema September 2012
+
+
+ the following instances are invalid:
+
+ {} (the empty object);
+
+ { "b": 2 } (required member name "a" is missing).
+
+5.4.4. additionalProperties, properties and patternProperties
+
+5.4.4.1. Valid values
+
+ 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 member name
+ of this object MUST be a valid regular expression, according to the
+ ECMA 262 regular expression dialect, as defined by FIXME_LINK. Each
+ value of this object MUST be an object, and each object MUST be a
+ valid JSON Schema.
+
+5.4.4.2. Conditions for successful validation
+
+ Successful validation of an object instance against these three
+ keywords depends on the value of "additionalProperties":
+
+ if its value is boolean true or a schema, validation succeeds;
+
+ if its value is boolean false, the algorithm to determine
+ validation success is described in the next section.
+
+5.4.4.3. If "additionalProperties" has boolean value false
+
+ In this case, validation of the instance depends on the member names
+ of "properties" and "patternProperties". In this section, member
+ names of "patternProperties" will be called regexes for convenience.
+
+ The first step is to collect the following sets:
+
+ s The set of member names of the instance to validate.
+
+ p The set of member names from "properties".
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 13]
+
+Internet-Draft JSON Schema September 2012
+
+
+ The set of regexes from "patternProperties".
+
+ Having collected these three sets, the process is as follows:
+
+ remove from "s" all members of "p", if any;
+
+ for each regex in "pp", remove all members of "s" which this regex
+ matches.
+
+ Validation of the instance succeeds if and only if, after these two
+ steps, set "s" is empty.
+
+5.4.4.4. Example
+
+ This schema will be used as an example:
+
+
+ {
+ "properties": {
+ "p1": {}
+ },
+ "patternProperties": {
+ "p": {},
+ "\\d": {}
+ }
+ }
+
+
+ This is the instance to validate:
+
+
+ {
+ "p1": true,
+ "p2": null,
+ "a32&o": "foobar",
+ "": [],
+ "finance": "ruins",
+ "apple": "pie"
+ }
+
+
+ The three sets are:
+
+ s { "p1", "p2", "a32&o", "", "finance", "apple" }
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 14]
+
+Internet-Draft JSON Schema September 2012
+
+
+ p { "p1" }
+
+ pp { "p", "\\d" }
+
+ Applying the two steps of the algorithm:
+
+ after the first step, "p1" is removed from "s";
+
+ after the second step, "p2", "a32&o" and "apple" are removed from
+ "s".
+
+ The set still contains two elements, "" and "finance". Validation
+ therefore fails.
+
+5.4.5. dependencies
+
+5.4.5.1. Valid values
+
+ This keyword's value MUST be an object. Values for this object MUST
+ be either of a string, an array or an object. If the value is an
+ object, it MUST be a valid JSON Schema.
+
+ If the value is an array:
+
+ this array MUST have at least one element;
+
+ elements of this array MUST be strings;
+
+ elements of this array MUST be unique.
+
+5.4.5.2. Conditions for successful validation
+
+ For each member name in the object instance with an equivalent member
+ name in "dependencies":
+
+ if the value in "dependencies" is an object, therefore a schema,
+ then the object instance is considered valid if and only if it
+ also validates successfully against this schema (note: the object
+ instance itself, not the value of that particular member);
+
+ if the value in "dependencies" is a string or an array of strings,
+ this (these) strings should be considered as member name(s), and
+ the object instance is required to have members by the same
+ name(s) in order to validate successfully.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 15]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.5. Validation keywords for any instance type
+
+5.5.1. enum
+
+5.5.1.1. Valid values
+
+ 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.
+
+5.5.1.2. Conditions for successful validation
+
+ An instance validates successfully against this keyword if and only
+ if its value is exactly equal to one of the elements in this
+ keyword's array value, according to the definition in FIXME_LINK.
+
+5.5.2. type
+
+5.5.2.1. Valid values
+
+ The value of this keyword MUST be a string or an array. If the value
+ is an array, elements of this array MUST be unique. This keyword's
+ string value, or array element values, MUST be either of:
+
+ one of the seven primitive types defined by FIXME_LINK; or
+
+ "any", which is equivalent to all seven primitive types.
+
+5.5.2.2. Conditions for successful validation
+
+ An instance matches successfully if and only if its primitive type,
+ as defined in FIXME_LINK, is one of the primitive types allowed by
+ this keyword's value. Recall: "number" includes "integer".
+
+5.5.3. allOf
+
+5.5.3.1. Valid values
+
+ 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.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 16]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.5.3.2. Conditions for successful validation
+
+ An instance validates successfully against this keyword if and only
+ if it validates successfully against all schemas defined by this
+ keyword's value.
+
+5.5.4. anyOf
+
+5.5.4.1. Valid values
+
+ 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.
+
+5.5.4.2. Conditions for successful validation
+
+ An instance validates successfully against this keyword if and only
+ if it validates successfully against at least one defined by this
+ keyword's value.
+
+5.5.5. oneOf
+
+5.5.5.1. Valid values
+
+ 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.
+
+5.5.5.2. Conditions for successful validation
+
+ An instance validates successfully against this keyword if and only
+ if it validates successfully against exactly one schema defined by
+ this keyword's value.
+
+5.5.6. not
+
+5.5.6.1. Valid values
+
+ This keyword's value MUST be an object. This object MUST be a valid
+ JSON Schema.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 17]
+
+Internet-Draft JSON Schema September 2012
+
+
+5.5.6.2. Conditions for successful validation
+
+ An instance is valid against this keyword if and only if it fails to
+ validate successfully against the schema defined by this keyword.
+
+6. Calculating schemas which children instances must validate against
+
+6.1. Foreword
+
+ Calculating the schema, or schemas, a child instance must validate
+ against is influenced by the following, in addition to the container
+ instance type:
+
+ the container instance type;
+
+ the child instance's defining characteristic in the container
+ instance;
+
+ the value of keywords implied in the calculation.
+
+ In addition, it is important that if one or more keyword(s) implied
+ in the calculation are not defined, it be considered present with its
+ default value, which will be recalled in this section.
+
+6.2. Array elements
+
+6.2.1. Defining characteristic
+
+ The defining characteristic of the child instance is this instance's
+ index in the array instance. Recall: array indices start at 0.
+
+6.2.2. Implied keywords and default values.
+
+ 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.
+
+6.2.3. Calculation
+
+6.2.3.1. If "items" is a 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".
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 18]
+
+Internet-Draft JSON Schema September 2012
+
+
+6.2.3.2. If "items" is an array
+
+ In this situation, the schema depends on the index of the child
+ instance:
+
+ if the index is less than, or equal to, the maximum index in the
+ "items" array, then the child instance must be valid against the
+ corresponding schema in the "items" array;
+
+ otherwise, it must be valid against the schema defined by
+ "additionalItems".
+
+6.3. Object values
+
+6.3.1. Defining characteristic
+
+ The defining characteristic of the child instance of an object is the
+ member name this child is associated to.
+
+6.3.2. Implied keywords
+
+ The three keywords implied in this calculation are "properties",
+ "patternProperties" and "additionalProperties".
+
+ If "properties" of "patternProperties" are absent, they are
+ considered present with an empty object as a value (note, an empty
+ object, NOT an empty schema).
+
+ 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.
+
+6.3.3. Calculation
+
+6.3.3.1. Names used in this calculation
+
+ The calculation below uses the following names:
+
+ m The member name the child instance is associated to.
+
+ p The set of member names from "properties", if any.
+
+ pp The set of member names from "patternProperties", if any. Member
+ names from this set will be called regexes for convenience.
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 19]
+
+Internet-Draft JSON Schema September 2012
+
+
+ s The set of schemas the child instance must validate against.
+
+6.3.3.2. First step: schemas in "properties"
+
+ If set "p" contains value "m", then the corresponding schema in
+ "properties" is added to "s".
+
+6.3.3.3. Second step: schemas in "patternProperties"
+
+ For each regex in "pp", if it matches "m" successfully, the
+ corresponding schema in "patternProperties" is added to "s".
+
+6.3.3.4. Third step: "additionalProperties"
+
+ The schema defined by "additionalProperties" is added to "s" if and
+ only if, at this stage, "s" is empty.
+
+7. IANA Considerations
+
+ This specification does not have any influence with regards to IANA.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.2. Informative References
+
+ [RFC4627] Crockford, D., "The application/json Media Type for
+ JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+
+Appendix A. ChangeLog
+
+ TODO
+
+Authors' Addresses
+
+ Francis Galiegue
+
+ EMail: fgaliegue@gmail.com
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 20]
+
+Internet-Draft JSON Schema September 2012
+
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+ Gary Court
+ Calgary, AB
+ Canada
+
+ EMail: gary.court@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 19, 2013 [Page 21]
+
From 75d138629900561182bb61179bdf1852d738fc39 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 15 Sep 2012 15:07:35 +0200
Subject: [PATCH 0095/1659] README.md updates
---
README.md | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/README.md b/README.md
index 01f397e1..a8a47eb3 100644
--- a/README.md
+++ b/README.md
@@ -4,11 +4,25 @@ This repository contains the current, and historical, JSON Schema
specifications, along wit a CommonJS implementation (authored by Kris Zyp, one
of the initiators of JSON Schema).
+## Call for reviews
+
+Specifications are starting to get written. Reviews, comments and suggestions
+are of paramount importance to JSON Schema. It is humbly asked to you, dear
+reader, that you bring your contribution.
+
+Proposed specifications are here:
+
+https://github.com/json-schema/json-schema/tree/next/proposals
+
+## The wiki
+
The wiki contains
a detailed description of JSON Schema, and discussion about the next version of
the specification.
-See also the JSON Schema web site: http://json-schema.org
+## The website
+
+The JSON Schema web site is at http://json-schema.org
Note that the content of the aforementioned web site is available from this
repository (branch gh-pages). Pull requests to improve the content of
From f82ca1b19ccde360262b496b7707972597b934f9 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 16 Sep 2012 17:48:21 +0200
Subject: [PATCH 0096/1659] json-schema-core.xml: rework the "id" stuff
That's a bitch to get right, really.
Not done yet.
---
proposals/json-schema-core.txt | 250 +++++++++++++--------------------
proposals/json-schema-core.xml | 178 ++++++++---------------
2 files changed, 159 insertions(+), 269 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 63991144..f4370a6b 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 19, 2013 SitePen (USA)
+Expires: March 20, 2013 SitePen (USA)
G. Court
- September 15, 2012
+ September 16, 2012
JSON Schema: core definitions and purposes
@@ -36,7 +36,7 @@ Status of This Memo
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 March 19, 2013.
+ This Internet-Draft will expire on March 20, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 19, 2013 [Page 1]
+Galiegue, et al. Expires March 20, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -63,38 +63,31 @@ Internet-Draft JSON Schema September 2012
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
- 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
- 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
- 3.2. Enclosing schema, root schema . . . . . . . . . . . . . . 3
- 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
- 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
- 5. JSON Schema identification . . . . . . . . . . . . . . . . . . 6
- 5.1. Purpose of this section . . . . . . . . . . . . . . . . . 6
- 5.2. Meta-schema identification using $schema . . . . . . . . . 6
- 5.3. Root schema identification . . . . . . . . . . . . . . . . 6
- 5.4. Subschema identification . . . . . . . . . . . . . . . . . 6
- 5.5. Identification using \\"id\\" . . . . . . . . . . . . . . 6
- 6. JSON Schema referencing . . . . . . . . . . . . . . . . . . . 7
- 6.1. Purpose of this section . . . . . . . . . . . . . . . . . 7
- 6.2. Determining the URI of a schema . . . . . . . . . . . . . 7
- 6.3. Loading schemas using JSON Reference . . . . . . . . . . . 8
- 6.4. The "json-schema" fragment resolution scheme . . . . . . . 8
- 7. Schema/Instance Association . . . . . . . . . . . . . . . . . 8
- 7.1. Purpose of this section . . . . . . . . . . . . . . . . . 8
- 7.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 8
- 7.2.1. Correlation by means of the "Content-Type" header . . 9
- 7.2.2. Correlation by means of the "Link" header . . . . . . 9
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
+ 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . . 3
+ 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . . 3
+ 3.2. Enclosing schema, root schema . . . . . . . . . . . . . . . 3
+ 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Design Considerations . . . . . . . . . . . . . . . . . . . 5
+ 5. Schema identification: the "id" keyword . . . . . . . . . . . . 6
+ 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2. Inner schema addressing . . . . . . . . . . . . . . . . . . 6
+ 5.3. Security considerations . . . . . . . . . . . . . . . . . . 7
+ 6. Schema/Instance Association . . . . . . . . . . . . . . . . . . 7
+ 6.1. Purpose of this section . . . . . . . . . . . . . . . . . . 7
+ 6.2. Recommended correlation mechanisms for use with the
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6.2.1. Correlation by means of the "Content-Type" header . . . 8
+ 6.2.2. Correlation by means of the "Link" header . . . . . . . 8
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 9
@@ -108,7 +101,14 @@ Table of Contents
-Galiegue, et al. Expires March 19, 2013 [Page 2]
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 20, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 19, 2013 [Page 3]
+Galiegue, et al. Expires March 20, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -175,7 +175,8 @@ Internet-Draft JSON Schema September 2012
In this example, the enclosing schema of both "nested" and
"alsonested" is "root". The schema with title "root" is said to be a
- root schema because it is not enclosed within another schema.
+ root schema because it is not enclosed within another schema. The
+ enclosing schema of a root schema is itself.
3.3. JSON Schema primitive types
@@ -219,8 +220,7 @@ Internet-Draft JSON Schema September 2012
-
-Galiegue, et al. Expires March 19, 2013 [Page 4]
+Galiegue, et al. Expires March 20, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -266,21 +266,22 @@ Internet-Draft JSON Schema September 2012
a JSON value should be interpreted and/or validated, such that
clients can properly understand acceptable structures for, and/or
extract the needed information from, the JSON instance being
- processed.
+ processed. This information ranges from documentation to external
+ resource links, and processing of these links.
It is acknowledged that JSON values can be of any type defined by the
JSON specification. As such, JSON Schema does not mandate that an
instance be of a particular type: JSON Schema can process any JSON
value, including null. It is the domain of JSON Schema validation to
- add useful constraints to the structure and, optionally, semantics,
-Galiegue, et al. Expires March 19, 2013 [Page 5]
+Galiegue, et al. Expires March 20, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+ add useful constraints to the structure and, optionally, semantics,
of the JSON instance being processed.
JSON Schema is agnostic with regards to both protocols and
@@ -288,141 +289,85 @@ Internet-Draft JSON Schema September 2012
semantics of the client-server interface is dependent on the protocol
being used.
-5. JSON Schema identification
-
-5.1. Purpose of this section
-
- This section describes the available mechanisms for identifying the
- schema in a unique way: its location, but also the version of the
- JSON Schema specification it is written against.
+5. Schema identification: the "id" keyword
-5.2. Meta-schema identification using $schema
+5.1. Usage
- TODO -- core schema, hyper schema, etc etc...
+ Schema authors MAY choose to use the "id" keyword to add
+ identification information to a JSON Schema. The value of this
+ keyword MUST be a string, and this string MUST be a valid URI. The
+ URI MUST be normalized.
-5.3. Root schema identification
+ When used in a root schema, the URI SHOULD be absolute and have no,
+ or an empty, fragment part. Failing that, an implementation MAY
+ choose to ignore the "id" value. It is RECOMMENDED that when used in
+ subschemas, the URI be relative. In subschemas, "id" MUST NOT be the
+ empty fragment ("#").
- A root schema MAY be uniquely identified by the presence of a
- "location" keyword. This keyword's value MUST be a string, and this
- string MUST be a URI; the URI MUST be absolute, and MUST have either
- no fragment, or an empty fragment.
+ In a same schema, there SHOULD NOT be two equivalent "id" values.
+ Failing that, as JSON objects do not define an order for members, URI
+ resolution is undefined.
- This keyword MUST NOT be used in subschemas.
+ Implementations MUST consider that a URI with no fragment part is
+ equivalent to this same URI with an empty fragment part.
-5.4. Subschema identification
+5.2. Inner schema addressing
- Within JSON Schemas, a subschema MAY be identified by the presence of
- a "subId" keyword. This keyword's value MUST be a string.
+ When "id" is encountered in a subschema, implementations MAY resolve
+ this URI against the root schema's URI, and consider that the
+ canonical URI of this subschema is the calculated URI. This is
+ called inner schema addressing.
- This string MUST NOT be empty. It MUST NOT start with a solidus (/).
- A same string MUST NOT be used more than once in a same root schema.
- This keyword MAY also be used in a root schema.
-5.5. Identification using \\"id\\"
- The value for this keyword MUST be a string. This string MUST be a
- URI.
- For backwards compatibility, JSON Schemas MAY use the "id" keyword
- for identification purposes. However, due to numerous ambiguity
- concerns, this is NOT RECOMMENDED.
- Schema authors willing to use "id" for identification purposes SHOULD
-Galiegue, et al. Expires March 19, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
- follow the following recommendations:
- in root schemas, "id" SHOULD obey the same constraints as
- described for "location";
- if used in subschemas, "id" SHOULD be a fragment-only URI.
-
- In any event, implementations SHOULD NOT expect peer implementations
- to support JSON Schema identification by the means of the "id"
- keyword.
-
-6. JSON Schema referencing
-
-6.1. Purpose of this section
-
- JSON Schema referencing is done using JSON Reference (FIXME: link to
- draft).
-
- In addition, JSON Schema extends the specification so as to use a
- dedicated fragment resolution scheme, by the name "json-schema".
- This mechanism is explained below. FIXME: RFC for fragment-
- resolution?
-
-6.2. Determining the URI of a schema
-
- Implementations SHOULD determine the URI of a schema as follows:
-
- if the schema was loaded from an absolute URI with no fragment
- part, or an empty fragment part, then the URI of the schema SHOULD
- be considered to be the loading URI, regardless of the values of
- "location" or "id";
-
- in any other situations:
-
- if the "location" keyword is present and conforms to this
- specification, the value of this keyword SHOULD be considered
- as the schema URI;
-
- if the "id" keyword is present and conforms to FIXME:
- crosslink, the value of this keyword MAY be considered as the
- schema URI;
-
- otherwise, implementations SHOULD choose an arbitrary URN, or
- the empty URI.
+Galiegue, et al. Expires March 20, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+ This schema will be taken as an example:
-Galiegue, et al. Expires March 19, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
+ Subschemas at the following URI-encoded JSON Pointers (starting from
+ the root of the schema) have the following URIs:
-6.3. Loading schemas using JSON Reference
+ http://x.y.z/rootschema.json#
- When encountering a JSON Reference, implementations MUST follow the
- rules defined by the JSON Reference draft. In addition:
+ http://x.y.z/rootschema.json#foo
- if resolution of the JSON Reference fails, or the dereferenced
- content is not a JSON Schema, it is RECOMMENDED that
- implementations consider this a failure and stop JSON Schema
- processing;
+ http://x.y.z/otherschema.json#
- implementations MUST perform fragment resolution as per the
- mechanism described below.
+ http://x.y.z/rootschema.json#bar
-6.4. The "json-schema" fragment resolution scheme
+ http://x.y.z/t/inner.json#a
- The "json-schema" fragment resolution scheme is an extension to the
- "json-pointer" fragment resolution scheme and works as follows:
+5.3. Security considerations
- implementations first try and treat this fragment as a JSON
- Pointer; if successful, they try and dereference that pointer
- against the current JSON Schema;
+ Inner schema addressing can produce canonical URIs which differ from
+ the canonical URI of the root schema. Implementations therefore MAY
+ choose, for security reasons, to ignore inner schema addressing, and
+ always dereference canonical URIs.
- if the fragment is not a JSON Pointer, implementations try and
- find in the JSON Schema a subschema with a "subId" keyword, which
- value is strictly equal to the fragment's URI-decoded string
- value.
+ As such, schema authors SHALL NOT expect that inner schema addressing
+ be used by an implementation.
-7. Schema/Instance Association
+6. Schema/Instance Association
-7.1. Purpose of this section
+6.1. Purpose of this section
A JSON instance MAY be correlated to one, or even several, JSON
Schemas. This correlation MAY be embodied witin existing protocol
@@ -436,22 +381,22 @@ Internet-Draft JSON Schema September 2012
of, or restrictions on, protocol headers, such a correlation is out
of the normative scope of this specification.
-7.2. Recommended correlation mechanisms for use with the HTTP protocol
+6.2. Recommended correlation mechanisms for use with the HTTP protocol
It is acknowledged by this specification that the majority of
interactive JSON Schema processing will be over HTTP. This section
- therefore gives recommendations for materializing an instance/schema
-Galiegue, et al. Expires March 19, 2013 [Page 8]
+Galiegue, et al. Expires March 20, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+ therefore gives recommendations for materializing an instance/schema
correlation using mechanisms currently available for this protocol.
-7.2.1. Correlation by means of the "Content-Type" header
+6.2.1. Correlation by means of the "Content-Type" header
It is RECOMMENDED that a MIME type parameter by the name of "profile"
be appended to the "Content-Type" header of the instance being
@@ -465,7 +410,7 @@ Internet-Draft JSON Schema September 2012
profile=http://example.com/my-hyper-schema
-7.2.2. Correlation by means of the "Link" header
+6.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
by the name "describedBy" be used, as defined by RFC 2048, section
@@ -481,7 +426,7 @@ Internet-Draft JSON Schema September 2012
Link: ; rel="describedBy"
-8. IANA Considerations
+7. IANA Considerations
The proposed MIME media type for JSON Schema is defined as follows:
@@ -493,19 +438,18 @@ Internet-Draft JSON Schema September 2012
FIXME: fragment resolution?
-9. References
-
+8. References
-Galiegue, et al. Expires March 19, 2013 [Page 9]
+Galiegue, et al. Expires March 20, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
-9.1. Normative References
+8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
@@ -514,7 +458,7 @@ Internet-Draft JSON Schema September 2012
http://tools.ietf.org/html/
draft-ietf-appsawg-json-pointer-04>.
-9.2. Informative References
+8.2. Informative References
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
@@ -556,5 +500,5 @@ Authors' Addresses
-Galiegue, et al. Expires March 19, 2013 [Page 10]
+Galiegue, et al. Expires March 20, 2013 [Page 9]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index eded37e6..461375d9 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -134,7 +134,8 @@
In this example, the enclosing schema of both "nested" and "alsonested" is
"root". The schema with title "root" is said to be a root schema because it
- is not enclosed within another schema.
+ is not enclosed within another schema. The enclosing schema of a root schema is
+ itself.
@@ -212,6 +213,7 @@
JSON Schema can be used to decorate either itself, or
instances, with descriptive text highlighting the schema's, or instance's,
purposes.
+
JSON Schema can be used to associate an instance to a
Link Description Object, as defined by FIXME.JSON Schema can be used to validate the structure of an
@@ -224,7 +226,8 @@
JSON Schema provides a separate format for flexibly communicating how a JSON
value should be interpreted and/or validated, such that clients can properly
understand acceptable structures for, and/or extract the needed information
- from, the JSON instance being processed.
+ from, the JSON instance being processed. This information ranges from
+ documentation to external resource links, and processing of these links.
It is acknowledged that JSON values can be of any type defined by the JSON
@@ -241,153 +244,96 @@
-
+
-
-
- This section describes the available mechanisms for identifying the schema in a
- unique way: its location, but also the version of the JSON Schema specification
- it is written against.
-
-
-
-
-
- TODO -- core schema, hyper schema, etc etc...
-
-
-
-
+
- A root schema MAY be uniquely identified by the presence of a "location"
- keyword. This keyword's value MUST be a string, and this string MUST be a URI;
- the URI MUST be absolute, and MUST have either no fragment, or an empty
- fragment.
+ Schema authors MAY choose to use the "id" keyword to add identification
+ information to a JSON Schema. The value of this keyword MUST be a string, and
+ this string MUST be a valid URI. The URI MUST be normalized.
- This keyword MUST NOT be used in subschemas.
+ When used in a root schema, the URI SHOULD be absolute and have no, or an empty,
+ fragment part. Failing that, an implementation MAY choose to ignore the "id"
+ value. It is RECOMMENDED that when used in subschemas, the URI be relative. In
+ subschemas, "id" MUST NOT be the empty fragment ("#").
-
-
-
- Within JSON Schemas, a subschema MAY be identified by the presence of a "subId"
- keyword. This keyword's value MUST be a string.
+ In a same schema, there SHOULD NOT be two equivalent "id" values. Failing that,
+ as JSON objects do not define an order for members, URI resolution is undefined.
- This string MUST NOT be empty. It MUST NOT start with a solidus (/). A same
- string MUST NOT be used more than once in a same root schema.
+ Implementations MUST consider that a URI with no fragment part is equivalent to
+ this same URI with an empty fragment part.
-
- This keyword MAY also be used in a root schema.
-
-
-
+
- The value for this keyword MUST be a string. This string MUST be a URI.
+ When "id" is encountered in a subschema, implementations MAY resolve this URI
+ against the root schema's URI, and consider that the canonical URI of this
+ subschema is the calculated URI. This is called inner schema addressing.
-
- For backwards compatibility, JSON Schemas MAY use the "id" keyword for
- identification purposes. However, due to numerous ambiguity concerns, this is
- NOT RECOMMENDED.
-
-
-
- Schema authors willing to use "id" for identification purposes SHOULD follow the
- following recommendations:
-
+
+ This schema will be taken as an example:
+
+
+
+
+
-
- in root schemas, "id" SHOULD obey the same constraints as described for
- "location";
- if used in subschemas, "id" SHOULD be a fragment-only URI.
-
-
-
- In any event, implementations SHOULD NOT expect peer implementations to support
- JSON Schema identification by the means of the "id" keyword.
-
-
-
-
-
-
-
-
-
- JSON Schema referencing is done using JSON Reference (FIXME: link to draft).
-
-
-
- In addition, JSON Schema extends the specification so as to use a dedicated
- fragment resolution scheme, by the name "json-schema". This mechanism is
- explained below. FIXME: RFC for fragment-resolution?
-
-
-
-
-
- Implementations SHOULD determine the URI of a schema as follows:
+ Subschemas at the following URI-encoded JSON Pointers (starting from the root of
+ the schema) have the following URIs:
-
- if the schema was loaded from an absolute URI with no fragment part, or an
- empty fragment part, then the URI of the schema SHOULD be considered to be the
- loading URI, regardless of the values of "location" or "id";
- in any other situations:
-
- if the "location" keyword is present and conforms to this
- specification, the value of this keyword SHOULD be considered as the
- schema URI;
- if the "id" keyword is present and conforms to FIXME: crosslink, the
- value of this keyword MAY be considered as the schema URI;
- otherwise, implementations SHOULD choose an arbitrary URN, or the
- empty URI.
-
-
+
+ http://x.y.z/rootschema.json#
+ http://x.y.z/rootschema.json#foo
+ http://x.y.z/otherschema.json#
+ http://x.y.z/rootschema.json#bar
+ http://x.y.z/t/inner.json#a
-
+
- When encountering a JSON Reference, implementations MUST follow the rules
- defined by the JSON Reference draft. In addition:
+ Inner schema addressing can produce canonical URIs which differ from the
+ canonical URI of the root schema. Implementations therefore MAY choose, for
+ security reasons, to ignore inner schema addressing, and always dereference
+ canonical URIs.
-
- if resolution of the JSON Reference fails, or the dereferenced content is not
- a JSON Schema, it is RECOMMENDED that implementations consider this a failure
- and stop JSON Schema processing;
- implementations MUST perform fragment resolution as per the mechanism
- described below.
-
-
-
-
- The "json-schema" fragment resolution scheme is an extension to the
- "json-pointer" fragment resolution scheme and works as follows:
+ As such, schema authors SHALL NOT expect that inner schema addressing be used by
+ an implementation.
-
-
- implementations first try and treat this fragment as a JSON Pointer; if
- successful, they try and dereference that pointer against the current JSON
- Schema;
- if the fragment is not a JSON Pointer, implementations try and find in the
- JSON Schema a subschema with a "subId" keyword, which value is strictly equal to
- the fragment's URI-decoded string value.
-
+
From d5fb472fab365506f0d37d4ecbbb4bd86ba4431b Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 16 Sep 2012 17:55:11 +0200
Subject: [PATCH 0097/1659] Fix stupid stuff
Comments in a tag causes the figure not to appear at all!
I hate XML.
---
proposals/json-schema-core.txt | 114 ++++++++++++++++++++++++---------
proposals/json-schema-core.xml | 19 +++---
2 files changed, 96 insertions(+), 37 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index f4370a6b..2072bc69 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -80,10 +80,10 @@ Table of Contents
6. Schema/Instance Association . . . . . . . . . . . . . . . . . . 7
6.1. Purpose of this section . . . . . . . . . . . . . . . . . . 7
6.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 7
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 8
6.2.1. Correlation by means of the "Content-Type" header . . . 8
6.2.2. Correlation by means of the "Link" header . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
@@ -318,7 +318,7 @@ Internet-Draft JSON Schema September 2012
canonical URI of this subschema is the calculated URI. This is
called inner schema addressing.
-
+ This schema will be taken as an example:
@@ -337,23 +337,35 @@ Galiegue, et al. Expires March 20, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
- This schema will be taken as an example:
-
-
+ {
+ "id": "http://x.y.z/rootschema.json#",
+ "schema1": {
+ "id": "#foo"
+ },
+ "schema2": {
+ "id": "otherschema.json",
+ "nested": {
+ "id": "#bar"
+ },
+ "alsonested": {
+ "id": t/inner.json#a"
+ }
+ }
+ }
Subschemas at the following URI-encoded JSON Pointers (starting from
the root of the schema) have the following URIs:
- http://x.y.z/rootschema.json#
+ # (document root) http://x.y.z/rootschema.json#
- http://x.y.z/rootschema.json#foo
+ #/schema1 http://x.y.z/rootschema.json#foo
- http://x.y.z/otherschema.json#
+ #/schema2 http://x.y.z/otherschema.json#
- http://x.y.z/rootschema.json#bar
+ #/schema2/nested http://x.y.z/rootschema.json#bar
- http://x.y.z/t/inner.json#a
+ #/schema2/alsonested http://x.y.z/t/inner.json#a
5.3. Security considerations
@@ -373,6 +385,14 @@ Internet-Draft JSON Schema September 2012
Schemas. This correlation MAY be embodied witin existing protocol
headers.
+
+
+
+Galiegue, et al. Expires March 20, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+
+
In addition, if the protocol also carries media type information (by
means, for instance, of a "Content-Type" header), an instance MUST be
one of "application/json" or any other subtype.
@@ -385,14 +405,6 @@ Internet-Draft JSON Schema September 2012
It is acknowledged by this specification that the majority of
interactive JSON Schema processing will be over HTTP. This section
-
-
-
-Galiegue, et al. Expires March 20, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
-
-
therefore gives recommendations for materializing an instance/schema
correlation using mechanisms currently available for this protocol.
@@ -426,6 +438,17 @@ Internet-Draft JSON Schema September 2012
Link: ; rel="describedBy"
+
+
+
+
+
+
+Galiegue, et al. Expires March 20, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
7. IANA Considerations
The proposed MIME media type for JSON Schema is defined as follows:
@@ -440,15 +463,6 @@ Internet-Draft JSON Schema September 2012
8. References
-
-
-
-
-Galiegue, et al. Expires March 20, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
-
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
@@ -475,6 +489,22 @@ Authors' Addresses
EMail: fgaliegue@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 20, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
Kris Zyp (editor)
SitePen (USA)
530 Lytton Avenue
@@ -500,5 +530,31 @@ Authors' Addresses
-Galiegue, et al. Expires March 20, 2013 [Page 9]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 20, 2013 [Page 10]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 461375d9..3bc5ad9b 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -279,11 +279,14 @@
subschema is the calculated URI. This is called inner schema addressing.
+
+ This schema will be taken as an example:
+
+
+
- This schema will be taken as an example:
-
- http://x.y.z/rootschema.json#
- http://x.y.z/rootschema.json#foo
- http://x.y.z/otherschema.json#
- http://x.y.z/rootschema.json#bar
- http://x.y.z/t/inner.json#a
+ http://x.y.z/rootschema.json#
+ http://x.y.z/rootschema.json#foo
+ http://x.y.z/otherschema.json#
+ http://x.y.z/rootschema.json#bar
+ http://x.y.z/t/inner.json#a
From e9ef0bc1b5f02b66a70143668e2ac232e529e6e7 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 16 Sep 2012 23:26:26 +0200
Subject: [PATCH 0098/1659] Core meta-schema
The URI is not definitive yet. But it sounds appropriate.
---
proposals/schema-core.json | 170 +++++++++++++++++++++++++++++++++++++
1 file changed, 170 insertions(+)
create mode 100644 proposals/schema-core.json
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
new file mode 100644
index 00000000..9ab186ed
--- /dev/null
+++ b/proposals/schema-core.json
@@ -0,0 +1,170 @@
+{
+ "id": "http://json-schema.org/current/schema-core.json#",
+ "$schema": "http://json-schema.org/current/schema-core.json#",
+ "description": "Core schema meta-schema",
+ "primitive-types": {
+ "enum": [ "array", "boolean", "integer", "null", "number", "object", "string", "any" ]
+ },
+ "type": "object",
+ "properties": {
+ "id": {
+ "type": "string",
+ "format": "uri"
+ },
+ "$schema": {
+ "type": "string",
+ "format": "uri"
+ },
+ "title": {
+ "type": "string"
+ },
+ "description": {
+ "type": "string"
+ },
+ "default": {},
+ "divisibleBy": {
+ "type": "number",
+ "minimum": 0,
+ "exclusiveMinimum": true
+ },
+ "maximum": {
+ "type": "number"
+ },
+ "exclusiveMaximum": {
+ "type": "number",
+ "default": false
+ },
+ "minimum": {
+ "type": "number"
+ },
+ "exclusiveMinimum": {
+ "type": "number",
+ "default": false
+ },
+ "maxLength": {
+ "type": "integer",
+ "minimum": 0
+ },
+ "minLength": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+ "pattern": {
+ "type": "string",
+ "format": "regex"
+ },
+ "additionalItems": {
+ "anyOf": [
+ { "type": "boolean" },
+ { "$ref": "#" }
+ ],
+ "default": {}
+ },
+ "items": {
+ "anyOf": [
+ { "$ref": "#" },
+ {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#" }
+ }
+ ],
+ "default": {}
+ },
+ "maxItems": {
+ "type": "integer",
+ "minimum": 0
+ },
+ "minItems": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+ "uniqueItems": {
+ "type": "boolean",
+ "default": false
+ },
+ "maxProperties": {
+ "type": "integer",
+ "minimum": 0
+ },
+ "minProperties": {
+ "type": "integer",
+ "minimum": 0,
+ "default": 0
+ },
+ "required": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "type": "string" },
+ "uniqueItems": true
+ },
+ "additionalProperties": {
+ "anyOf": [
+ { "type": "boolean" },
+ { "$ref": "#" }
+ ],
+ "default": {}
+ },
+ "patternProperties": {
+ "type": "object",
+ "additionalProperties": { "$ref": "#" },
+ "default": {}
+ },
+ "properties": {
+ "type": "object",
+ "additionalProperties": { "$ref": "#" },
+ "default": {}
+ },
+ "dependencies": {
+ "type": "object",
+ "additionalProperties": {
+ "anyOf": [
+ { "type": "string" },
+ {
+ "type": "array",
+ "minItems": 1,
+ "items": { "type": "string" },
+ "uniqueItems": true
+ },
+ { "$ref": "#" }
+ ]
+ }
+ },
+ "enum": {
+ "type": "array",
+ "minItems": 1,
+ "uniqueItems": true
+ },
+ "type": {
+ "anyOf": [
+ { "$ref": "#/primitive-types" },
+ {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#/primitive-types" }
+ }
+ ],
+ "default": "any"
+ },
+ "allOf": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#" }
+ },
+ "anyOf": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#" }
+ },
+ "oneOf": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#" }
+ },
+ "not": { "$ref": "#" }
+ },
+ "default": {}
+}
+
From c57ef87d757fef94320251df5904f8f79d89873b Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 16 Sep 2012 23:28:24 +0200
Subject: [PATCH 0099/1659] schema-core.json: fix obvious mistake
exclusiveM{in,ax}imum are booleans, not numbers...
---
proposals/schema-core.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 9ab186ed..1e4ef613 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -31,14 +31,14 @@
"type": "number"
},
"exclusiveMaximum": {
- "type": "number",
+ "type": "boolean",
"default": false
},
"minimum": {
"type": "number"
},
"exclusiveMinimum": {
- "type": "number",
+ "type": "boolean",
"default": false
},
"maxLength": {
From 51f6e58b52ce969108176bf1fce211df31c615fe Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Sep 2012 10:31:16 +0200
Subject: [PATCH 0100/1659] Specification updates
---
proposals/json-schema-core.txt | 244 ++++++++---------
proposals/json-schema-core.xml | 75 ++++--
proposals/json-schema-validation.txt | 378 ++++++++++++---------------
proposals/json-schema-validation.xml | 93 +++----
4 files changed, 368 insertions(+), 422 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 2072bc69..4905b2a6 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 20, 2013 SitePen (USA)
+Expires: March 21, 2013 SitePen (USA)
G. Court
- September 16, 2012
+ September 17, 2012
JSON Schema: core definitions and purposes
@@ -36,7 +36,7 @@ Status of This Memo
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 March 20, 2013.
+ This Internet-Draft will expire on March 21, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 20, 2013 [Page 1]
+Galiegue, et al. Expires March 21, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -63,31 +63,33 @@ Internet-Draft JSON Schema September 2012
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
- 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . . 3
- 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . . 3
- 3.2. Enclosing schema, root schema . . . . . . . . . . . . . . . 3
- 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . . 4
- 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Design Considerations . . . . . . . . . . . . . . . . . . . 5
- 5. Schema identification: the "id" keyword . . . . . . . . . . . . 6
- 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.2. Inner schema addressing . . . . . . . . . . . . . . . . . . 6
- 5.3. Security considerations . . . . . . . . . . . . . . . . . . 7
- 6. Schema/Instance Association . . . . . . . . . . . . . . . . . . 7
- 6.1. Purpose of this section . . . . . . . . . . . . . . . . . . 7
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
+ 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
+ 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
+ 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
+ 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
+ 5. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Addressing mechanisms and general considerations . . . . . 6
+ 5.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 6
+ 5.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 6
+ 5.4. Inner schema addressing . . . . . . . . . . . . . . . . . 6
+ 5.5. Security considerations . . . . . . . . . . . . . . . . . 8
+ 6. Schema/Instance Association . . . . . . . . . . . . . . . . . 8
+ 6.1. Purpose of this section . . . . . . . . . . . . . . . . . 8
6.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 8
- 6.2.1. Correlation by means of the "Content-Type" header . . . 8
- 6.2.2. Correlation by means of the "Link" header . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 9
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 8
+ 6.2.1. Correlation by means of the "Content-Type" header . . 8
+ 6.2.2. Correlation by means of the "Link" header . . . . . . 9
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
@@ -106,9 +108,7 @@ Table of Contents
-
-
-Galiegue, et al. Expires March 20, 2013 [Page 2]
+Galiegue, et al. Expires March 21, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -149,7 +149,7 @@ Internet-Draft JSON Schema September 2012
A JSON Schema MAY be empty.
-3.2. Enclosing schema, root schema
+3.2. Root schema, subschema
JSON Schemas can be nested, as in this example:
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 20, 2013 [Page 3]
+Galiegue, et al. Expires March 21, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -173,10 +173,8 @@ Internet-Draft JSON Schema September 2012
}
- In this example, the enclosing schema of both "nested" and
- "alsonested" is "root". The schema with title "root" is said to be a
- root schema because it is not enclosed within another schema. The
- enclosing schema of a root schema is itself.
+ In this example, "nested" and "alsonested" are subschemas, and "root"
+ is a root schema.
3.3. JSON Schema primitive types
@@ -217,17 +215,16 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
+ values for a same member are equal according to this
+ definition.
-Galiegue, et al. Expires March 20, 2013 [Page 4]
+Galiegue, et al. Expires March 21, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
- values for a same member are equal according to this
- definition.
-
Note about numbers: the two JSON number values, 1.0 and 1, for
instance, are mathematically equivalent; however they are NOT equal,
since their JSON representation differs.
@@ -273,68 +270,80 @@ Internet-Draft JSON Schema September 2012
JSON specification. As such, JSON Schema does not mandate that an
instance be of a particular type: JSON Schema can process any JSON
value, including null. It is the domain of JSON Schema validation to
+ add useful constraints to the structure and, optionally, semantics,
+ of the JSON instance being processed.
-Galiegue, et al. Expires March 20, 2013 [Page 5]
+
+Galiegue, et al. Expires March 21, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
- add useful constraints to the structure and, optionally, semantics,
- of the JSON instance being processed.
-
JSON Schema is agnostic with regards to both protocols and
programming languages. In particular, this means that defining the
semantics of the client-server interface is dependent on the protocol
being used.
-5. Schema identification: the "id" keyword
-
-5.1. Usage
-
- Schema authors MAY choose to use the "id" keyword to add
- identification information to a JSON Schema. The value of this
- keyword MUST be a string, and this string MUST be a valid URI. The
- URI MUST be normalized.
+5. Schema addressing
- When used in a root schema, the URI SHOULD be absolute and have no,
- or an empty, fragment part. Failing that, an implementation MAY
- choose to ignore the "id" value. It is RECOMMENDED that when used in
- subschemas, the URI be relative. In subschemas, "id" MUST NOT be the
- empty fragment ("#").
+5.1. Addressing mechanisms and general considerations
- In a same schema, there SHOULD NOT be two equivalent "id" values.
- Failing that, as JSON objects do not define an order for members, URI
- resolution is undefined.
+ JSON Schema defines two addressing mechanisms: canonical addressing,
+ and inner schema addressing. Implementations MUST support canonical
+ addressing, and MAY support inner schema addressing.
- Implementations MUST consider that a URI with no fragment part is
- equivalent to this same URI with an empty fragment part.
+ Inner schema addressing is done by the means of the "id" keyword.
+ The value of this keyword MUST be a string, and this string MUST be a
+ valid URI, and MUST be normalized. When used in a root schema, the
+ value of this keyword SHOULD be an absolute URI, and MUST have no
+ fragment, or an empty fragment.
-5.2. Inner schema addressing
+5.2. URI of a root schema
- When "id" is encountered in a subschema, implementations MAY resolve
- this URI against the root schema's URI, and consider that the
- canonical URI of this subschema is the calculated URI. This is
- called inner schema addressing.
+ When a schema is loaded via a URI, the loading URI SHALL be
+ considered to be the URI for this schema. If a schema is loaded
+ without a URI:
- This schema will be taken as an example:
+ if "id" is present in the root schema, and obeys the provisions in
+ the previous paragraph, the value of "id" MAY be considered to be
+ the schema URI;
+ otherwise, it is RECOMMENDED that implementations consider that
+ the URI of the schema is either the empty URI, or a URN.
+ In addition, implementations MUST consider, for root schema URIs,
+ that the URI with no fragment, or an empty fragment, are strictly
+ equivalent.
+5.3. Canonical addressing
+ Canonical addressing in JSON Schema is done using JSON Reference
+ (FIXME_LINK). As defined by the JSON Reference specification, when
+ encountering a JSON Reference, other schema keywords SHALL be
+ ignored.
+5.4. Inner schema addressing
+ When "id" is encountered in a subschema, implementations MAY resolve
+ this URI against the root schema's URI, and consider that the
+ canonical URI of this subschema is the calculated URI. This is
+Galiegue, et al. Expires March 21, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+ called inner schema addressing.
+ There SHOULD NOT be two identical "id" values in the same schema.
+ Failing that, subschema lookup using inner schema addressing is
+ undefined.
-Galiegue, et al. Expires March 20, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
+ This schema will be taken as an example:
{
@@ -350,6 +359,9 @@ Internet-Draft JSON Schema September 2012
"alsonested": {
"id": t/inner.json#a"
}
+ },
+ "schema3": {
+ "id": "some://where.else/completely#"
}
}
@@ -367,32 +379,41 @@ Internet-Draft JSON Schema September 2012
#/schema2/alsonested http://x.y.z/t/inner.json#a
-5.3. Security considerations
+ #/schema3 some://where.else/completely#
- Inner schema addressing can produce canonical URIs which differ from
- the canonical URI of the root schema. Implementations therefore MAY
- choose, for security reasons, to ignore inner schema addressing, and
- always dereference canonical URIs.
- As such, schema authors SHALL NOT expect that inner schema addressing
- be used by an implementation.
-6. Schema/Instance Association
-6.1. Purpose of this section
- A JSON instance MAY be correlated to one, or even several, JSON
- Schemas. This correlation MAY be embodied witin existing protocol
- headers.
-
-Galiegue, et al. Expires March 20, 2013 [Page 7]
+Galiegue, et al. Expires March 21, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+5.5. Security considerations
+
+ Inner schema addressing can produce canonical URIs which differ from
+ the canonical URI of the root schema. Implementations MAY choose,
+ for security reasons, to ignore inner schema addressing, and always
+ dereference canonical URIs. Schema authors SHALL NOT expect that
+ inner schema addressing be used by an implementation.
+
+ Dereferencing canonical URIs MAY fail to complete, or MAY lead to
+ content which is not a JSON Schema (another type of JSON value, or
+ not a JSON value). It is RECOMMENDED that JSON Schema processing be
+ stopped in such a situation.
+
+6. Schema/Instance Association
+
+6.1. Purpose of this section
+
+ A JSON instance MAY be correlated to one, or even several, JSON
+ Schemas. This correlation MAY be embodied witin existing protocol
+ headers.
+
In addition, if the protocol also carries media type information (by
means, for instance, of a "Content-Type" header), an instance MUST be
one of "application/json" or any other subtype.
@@ -422,6 +443,12 @@ Internet-Draft JSON Schema September 2012
profile=http://example.com/my-hyper-schema
+
+Galiegue, et al. Expires March 21, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
6.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
@@ -438,17 +465,6 @@ Internet-Draft JSON Schema September 2012
Link: ; rel="describedBy"
-
-
-
-
-
-
-Galiegue, et al. Expires March 20, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
-
7. IANA Considerations
The proposed MIME media type for JSON Schema is defined as follows:
@@ -478,31 +494,26 @@ Internet-Draft JSON Schema September 2012
JavaScript Object Notation (JSON)", RFC 4627,
July 2006.
-Appendix A. ChangeLog
-
- TODO
-
-Authors' Addresses
-
- Francis Galiegue
-
- EMail: fgaliegue@gmail.com
-
+Galiegue, et al. Expires March 21, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+Appendix A. ChangeLog
+ TODO
+Authors' Addresses
+ Francis Galiegue
-Galiegue, et al. Expires March 20, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
+ EMail: fgaliegue@gmail.com
Kris Zyp (editor)
@@ -545,16 +556,5 @@ Internet-Draft JSON Schema September 2012
-
-
-
-
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 20, 2013 [Page 10]
+Galiegue, et al. Expires March 21, 2013 [Page 10]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 3bc5ad9b..17abb13c 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -111,7 +111,7 @@
-
+
JSON Schemas can be nested, as in this example:
@@ -132,10 +132,8 @@
- In this example, the enclosing schema of both "nested" and "alsonested" is
- "root". The schema with title "root" is said to be a root schema because it
- is not enclosed within another schema. The enclosing schema of a root schema is
- itself.
+ In this example, "nested" and "alsonested" are subschemas, and "root" is a root
+ schema.
@@ -229,6 +227,7 @@
from, the JSON instance being processed. This information ranges from
documentation to external resource links, and processing of these links.
+
It is acknowledged that JSON values can be of any type defined by the JSON
specification. As such, JSON Schema does not mandate that an instance be of a
@@ -236,6 +235,7 @@
the domain of JSON Schema validation to add useful constraints to the structure
and, optionally, semantics, of the JSON instance being processed.
+
JSON Schema is agnostic with regards to both protocols and programming
languages. In particular, this means that defining the semantics of the
@@ -244,34 +244,52 @@
-
+
-
+
- Schema authors MAY choose to use the "id" keyword to add identification
- information to a JSON Schema. The value of this keyword MUST be a string, and
- this string MUST be a valid URI. The URI MUST be normalized.
+ JSON Schema defines two addressing mechanisms: canonical addressing, and inner
+ schema addressing. Implementations MUST support canonical addressing, and MAY
+ support inner schema addressing.
- When used in a root schema, the URI SHOULD be absolute and have no, or an empty,
- fragment part. Failing that, an implementation MAY choose to ignore the "id"
- value. It is RECOMMENDED that when used in subschemas, the URI be relative. In
- subschemas, "id" MUST NOT be the empty fragment ("#").
+ Inner schema addressing is done by the means of the "id" keyword. The value of
+ this keyword MUST be a string, and this string MUST be a valid URI, and MUST be
+ normalized. When used in a root schema, the value of this keyword SHOULD be an
+ absolute URI, and MUST have no fragment, or an empty fragment.
+
+
- In a same schema, there SHOULD NOT be two equivalent "id" values. Failing that,
- as JSON objects do not define an order for members, URI resolution is undefined.
+ When a schema is loaded via a URI, the loading URI SHALL be considered to be the
+ URI for this schema. If a schema is loaded without a URI:
+
+ if "id" is present in the root schema, and obeys the provisions in the
+ previous paragraph, the value of "id" MAY be considered to be the schema
+ URI;
+ otherwise, it is RECOMMENDED that implementations consider that the URI of
+ the schema is either the empty URI, or a URN.
+
+
- Implementations MUST consider that a URI with no fragment part is equivalent to
- this same URI with an empty fragment part.
+ In addition, implementations MUST consider, for root schema URIs, that the URI
+ with no fragment, or an empty fragment, are strictly equivalent.
+
+
+ Canonical addressing in JSON Schema is done using JSON Reference (FIXME_LINK).
+ As defined by the JSON Reference specification, when encountering a JSON
+ Reference, other schema keywords SHALL be ignored.
+
+
+
When "id" is encountered in a subschema, implementations MAY resolve this URI
@@ -279,6 +297,11 @@
subschema is the calculated URI. This is called inner schema addressing.
+
+ There SHOULD NOT be two identical "id" values in the same schema. Failing that,
+ subschema lookup using inner schema addressing is undefined.
+
+
This schema will be taken as an example:
@@ -301,6 +324,9 @@
"alsonested": {
"id": t/inner.json#a"
}
+ },
+ "schema3": {
+ "id": "some://where.else/completely#"
}
}
]]>
@@ -318,6 +344,7 @@
http://x.y.z/otherschema.json#http://x.y.z/rootschema.json#barhttp://x.y.z/t/inner.json#a
+ some://where.else/completely#
@@ -325,14 +352,16 @@
Inner schema addressing can produce canonical URIs which differ from the
- canonical URI of the root schema. Implementations therefore MAY choose, for
- security reasons, to ignore inner schema addressing, and always dereference
- canonical URIs.
+ canonical URI of the root schema. Implementations MAY choose, for security
+ reasons, to ignore inner schema addressing, and always dereference canonical
+ URIs. Schema authors SHALL NOT expect that inner schema addressing be used by
+ an implementation.
- As such, schema authors SHALL NOT expect that inner schema addressing be used by
- an implementation.
+ Dereferencing canonical URIs MAY fail to complete, or MAY lead to content which
+ is not a JSON Schema (another type of JSON value, or not a JSON value). It is
+ RECOMMENDED that JSON Schema processing be stopped in such a situation.
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 6b2d6583..3e92ad84 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 19, 2013 SitePen (USA)
+Expires: March 21, 2013 SitePen (USA)
G. Court
- September 15, 2012
+ September 17, 2012
JSON Schema: instance validation
@@ -35,7 +35,7 @@ Status of This Memo
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 March 19, 2013.
+ This Internet-Draft will expire on March 21, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 19, 2013 [Page 1]
+Galiegue, et al. Expires March 21, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -76,8 +76,8 @@ Table of Contents
5.1.1. divisibleBy . . . . . . . . . . . . . . . . . . . . . 6
5.1.2. maximum and exclusiveMaximum . . . . . . . . . . . . . 6
5.1.3. minimum and exclusiveMinimum . . . . . . . . . . . . . 7
- 5.2. Validation keywords for strings . . . . . . . . . . . . . 7
- 5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. Validation keywords for strings . . . . . . . . . . . . . 8
+ 5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8
5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Validation keywords for arrays . . . . . . . . . . . . . . 9
@@ -90,37 +90,37 @@ Table of Contents
5.4.2. minProperties . . . . . . . . . . . . . . . . . . . . 12
5.4.3. required . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. additionalProperties, properties and
- patternProperties . . . . . . . . . . . . . . . . . . 13
- 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 15
- 5.5. Validation keywords for any instance type . . . . . . . . 16
- 5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ patternProperties . . . . . . . . . . . . . . . . . . 12
+ 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 14
+ 5.5. Validation keywords for any instance type . . . . . . . . 15
+ 5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 17
- 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Calculating schemas which children instances must validate
- against . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ against . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Defining characteristic . . . . . . . . . . . . . . . 18
6.2.2. Implied keywords and default values. . . . . . . . . . 18
-Galiegue, et al. Expires March 19, 2013 [Page 2]
+Galiegue, et al. Expires March 21, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
6.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 18
- 6.3. Object values . . . . . . . . . . . . . . . . . . . . . . 19
- 6.3.1. Defining characteristic . . . . . . . . . . . . . . . 19
- 6.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 19
+ 6.3. Object values . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.3.1. Defining characteristic . . . . . . . . . . . . . . . 18
+ 6.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 18
6.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 19
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 20
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 19, 2013 [Page 3]
+Galiegue, et al. Expires March 21, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -212,32 +212,37 @@ Internet-Draft JSON Schema September 2012
expressions SHOULD be valid according to the ECMA 262 regular
expression dialect.
- However, regular expression dialects vary, sometimes widely, between
- programming languages, to the extent that a same regular expression
- token may behave differently between programming languages. For
- instance, "\w", which is a common idiom used to match a character
- which is "part of a word", will only match letters, digits and the
+ Implementations MUST NOT consider that regular expressions are
+ anchored, neither at the beginning or at the end. This means, for
+ instance, that "es" matches "expression".
+
+ Regular expression dialects vary, sometimes widely, between
-Galiegue, et al. Expires March 19, 2013 [Page 4]
+Galiegue, et al. Expires March 21, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
+ programming languages, to the extent that a same regular expression
+ token may behave differently between programming languages. For
+ instance, "\w", which is a common idiom used to match a character
+ which is "part of a word", will only match letters, digits and the
underscore in the US-ASCII character set in Java, whereas it matches
any Unicode alphanumeric character, plus the underscore, in ECMA 262.
- For this reason, if regular expressions need to be used in a schema
- meant to be used by peer implementations, it is RECOMMENDED that
- schema authors limit themselves to the following regular expression
- tokens:
+ For this reason, if regular expressions are used in a schema meant to
+ be processed by peer implementations, it is RECOMMENDED that schema
+ authors limit themselves to the following regular expression tokens:
individual Unicode characters, as defined by the JSON RFC
(FIXME_LINK);
simple character classes ([abc]), range character classes ([a-z]);
+ complemented character classes ([^abc], [^a-z]);
+
quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or
one), "{x}" where "x" is an integer (exactly x occurrences),
"{x,y}" where "x" and "y" are integers (at least x, at most y,
@@ -268,19 +273,18 @@ Internet-Draft JSON Schema September 2012
presence of other keywords. In this case, all these keywords will be
grouped in the same section.
- Finally, some keywords, if absent, MAY be regarded by implementations
- as having a default value. In this case, the default value will be
- mentioned.
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 5]
+Galiegue, et al. Expires March 21, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+ Finally, some keywords, if absent, MAY be regarded by implementations
+ as having a default value. In this case, the default value will be
+ mentioned.
+
4.2. Validation of container instances
It should be noted that keywords with the possibility to validate
@@ -323,29 +327,30 @@ Internet-Draft JSON Schema September 2012
If "exclusiveMaximum" is present, "maximum" MUST also be present.
-5.1.2.2. Conditions for successful validation
-
- Successful validation depends on the presence and value of
- "exclusiveMaximum":
-Galiegue, et al. Expires March 19, 2013 [Page 6]
+Galiegue, et al. Expires March 21, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+5.1.2.2. Conditions for successful validation
+
+ Successful validation depends on the presence and value of
+ "exclusiveMaximum":
+
if "exclusiveMaximum" is not present, or has boolean value false,
- then the instance is valid if and only if it is greater than, or
+ then the instance is valid if and only if it is lower than, or
equal to, the value of "maximum";
if "exclusiveMaximum" is present and has boolean value true, the
- the instance is valid if and only if it is strictly greater than
- the value of "maximum".
+ the instance is valid if and only if it is strictly lower than the
+ value of "maximum".
-5.1.2.3. Default values
+5.1.2.3. Default value
"exclusiveMaximum", if absent, may be considered as being present
with boolean value false.
@@ -365,34 +370,38 @@ Internet-Draft JSON Schema September 2012
"exclusiveMinimum":
if "exclusiveMinimum" is not present, or has boolean value false,
- then the instance is valid if and only if it is lower than, or
+ then the instance is valid if and only if it is greater than, or
equal to, the value of "minimum";
if "exclusiveMinimum" is present and has boolean value true, the
- the instance is valid if and only if it is strictly lower than the
- value of "minimum".
+ the instance is valid if and only if it is strictly greater than
+ the value of "minimum".
5.1.3.3. Default value
"exclusiveMinimum", if absent, may be considered as being present
with boolean value false.
-5.2. Validation keywords for strings
-5.2.1. maxLength
-5.2.1.1. Valid values
- The value for this keyword MUST be an integer. This integer MUST be
- greater than, or equal to, 0.
-Galiegue, et al. Expires March 19, 2013 [Page 7]
+Galiegue, et al. Expires March 21, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+5.2. Validation keywords for strings
+
+5.2.1. maxLength
+
+5.2.1.1. Valid values
+
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
+
5.2.1.2. Conditions for successful validation
A string instance is valid against this keyword if and only if its
@@ -429,31 +438,21 @@ Internet-Draft JSON Schema September 2012
valid regular expression, according to the ECMA 262 regular
expression dialect, as defined by FIXME_LINK.
-5.2.3.2. Conditions for successful validation
- A string instance is considered valid if and only if the regular
- expression matches the instance successfully.
-5.2.3.3. Notes about regular expressions
-
- Implementations MUST NOT consider that regular expressions are
- surrounded by either the beginning-of-input ("^") or end-of-input
- ("$") anchors. This means that, for instance, "x" matches
- "exercise".
-Galiegue, et al. Expires March 19, 2013 [Page 8]
+Galiegue, et al. Expires March 21, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
- The ECMA 262 regular expression dialect has poor programming language
- support; the only programming language with native ECMA 262 regular
- expression support is JavaScript. It is therefore RECOMMENDED that
- schema authors limit themselves to the regular expression feature set
- defined in section FIXME_LINK.
+5.2.3.2. Conditions for successful validation
+
+ A string instance is considered valid if and only if the regular
+ expression matches the instance successfully.
5.3. Validation keywords for arrays
@@ -500,7 +499,8 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 19, 2013 [Page 9]
+
+Galiegue, et al. Expires March 21, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
@@ -556,7 +556,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 19, 2013 [Page 10]
+Galiegue, et al. Expires March 21, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
@@ -580,11 +580,11 @@ Internet-Draft JSON Schema September 2012
5.3.4.2. Conditions for successful validation
- If this keyword has boolean value false, then the instance validates
- successfully. If it has boolean value true, then the instance
- validates successfully if and only if all of its elements are unique.
- In other words, no two elements of the array instance should be equal
- as per the definition in FIXME_LINK.
+ If this keyword has boolean value false, the instance validates
+ successfully. If it has boolean value true, the instance validates
+ successfully if and only if all of its elements are unique. In other
+ words, no two elements of the array instance should be equal as per
+ the definition in FIXME_LINK.
5.3.4.3. Default value
@@ -612,7 +612,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 19, 2013 [Page 11]
+Galiegue, et al. Expires March 21, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
@@ -649,36 +649,6 @@ Internet-Draft JSON Schema September 2012
set of its member names contains all elements in this keyword's
array.
-5.4.3.3. Example
-
- Against this schema:
-
-
- {
- "required": [ "a", "b" ]
- }
-
-
- the following instances are valid:
-
- { "a": 1, "b": 2 };
-
- { "a": 1, "b": 2, "c": 3 };
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 12]
-
-Internet-Draft JSON Schema September 2012
-
-
- the following instances are invalid:
-
- {} (the empty object);
-
- { "b": 2 } (required member name "a" is missing).
-
5.4.4. additionalProperties, properties and patternProperties
5.4.4.1. Valid values
@@ -696,6 +666,13 @@ Internet-Draft JSON Schema September 2012
value of this object MUST be an object, and each object MUST be a
valid JSON Schema.
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 12]
+
+Internet-Draft JSON Schema September 2012
+
+
5.4.4.2. Conditions for successful validation
Successful validation of an object instance against these three
@@ -704,9 +681,18 @@ Internet-Draft JSON Schema September 2012
if its value is boolean true or a schema, validation succeeds;
if its value is boolean false, the algorithm to determine
- validation success is described in the next section.
+ validation success is described below.
+
+5.4.4.3. Default values
+
+ If either "properties" or "patternProperties" are absent, they can be
+ considered present with an empty object as a value (NOTE: an empty
+ object, NOT an empty schema).
-5.4.4.3. If "additionalProperties" has boolean value false
+ If "additionalProperties" is absent, it may be considered present
+ with an empty schema as a value.
+
+5.4.4.4. If "additionalProperties" has boolean value false
In this case, validation of the instance depends on the member names
of "properties" and "patternProperties". In this section, member
@@ -718,17 +704,6 @@ Internet-Draft JSON Schema September 2012
p The set of member names from "properties".
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 13]
-
-Internet-Draft JSON Schema September 2012
-
-
The set of regexes from "patternProperties".
Having collected these three sets, the process is as follows:
@@ -741,11 +716,19 @@ Internet-Draft JSON Schema September 2012
Validation of the instance succeeds if and only if, after these two
steps, set "s" is empty.
-5.4.4.4. Example
+5.4.4.5. Example
This schema will be used as an example:
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 13]
+
+Internet-Draft JSON Schema September 2012
+
+
{
"properties": {
"p1": {}
@@ -774,17 +757,6 @@ Internet-Draft JSON Schema September 2012
s { "p1", "p2", "a32&o", "", "finance", "apple" }
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 14]
-
-Internet-Draft JSON Schema September 2012
-
-
p { "p1" }
pp { "p", "\\d" }
@@ -805,6 +777,14 @@ Internet-Draft JSON Schema September 2012
This keyword's value MUST be an object. Values for this object MUST
be either of a string, an array or an object. If the value is an
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 14]
+
+Internet-Draft JSON Schema September 2012
+
+
object, it MUST be a valid JSON Schema.
If the value is an array:
@@ -830,17 +810,6 @@ Internet-Draft JSON Schema September 2012
the object instance is required to have members by the same
name(s) in order to validate successfully.
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 15]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5. Validation keywords for any instance type
5.5.1. enum
@@ -864,6 +833,14 @@ Internet-Draft JSON Schema September 2012
The value of this keyword MUST be a string or an array. If the value
is an array, elements of this array MUST be unique. This keyword's
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 15]
+
+Internet-Draft JSON Schema September 2012
+
+
string value, or array element values, MUST be either of:
one of the seven primitive types defined by FIXME_LINK; or
@@ -886,17 +863,6 @@ Internet-Draft JSON Schema September 2012
Elements of the array MUST be objects. Each object MUST be a valid
JSON Schema.
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 16]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5.3.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
@@ -921,6 +887,16 @@ Internet-Draft JSON Schema September 2012
5.5.5. oneOf
+
+
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 16]
+
+Internet-Draft JSON Schema September 2012
+
+
5.5.5.1. Valid values
This keyword's value MUST be an array. This array MUST have at least
@@ -942,17 +918,6 @@ Internet-Draft JSON Schema September 2012
This keyword's value MUST be an object. This object MUST be a valid
JSON Schema.
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 17]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5.6.2. Conditions for successful validation
An instance is valid against this keyword if and only if it fails to
@@ -977,6 +942,17 @@ Internet-Draft JSON Schema September 2012
in the calculation are not defined, it be considered present with its
default value, which will be recalled in this section.
+
+
+
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 17]
+
+Internet-Draft JSON Schema September 2012
+
+
6.2. Array elements
6.2.1. Defining characteristic
@@ -1000,15 +976,6 @@ Internet-Draft JSON Schema September 2012
this schema, regardless of its index, and regardless of the value of
"additionalItems".
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 18]
-
-Internet-Draft JSON Schema September 2012
-
-
6.2.3.2. If "items" is an array
In this situation, the schema depends on the index of the child
@@ -1034,6 +1001,14 @@ Internet-Draft JSON Schema September 2012
"patternProperties" and "additionalProperties".
If "properties" of "patternProperties" are absent, they are
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 18]
+
+Internet-Draft JSON Schema September 2012
+
+
considered present with an empty object as a value (note, an empty
object, NOT an empty schema).
@@ -1054,17 +1029,6 @@ Internet-Draft JSON Schema September 2012
pp The set of member names from "patternProperties", if any. Member
names from this set will be called regexes for convenience.
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 19]
-
-Internet-Draft JSON Schema September 2012
-
-
s The set of schemas the child instance must validate against.
6.3.3.2. First step: schemas in "properties"
@@ -1093,6 +1057,14 @@ Internet-Draft JSON Schema September 2012
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Galiegue, et al. Expires March 21, 2013 [Page 19]
+
+Internet-Draft JSON Schema September 2012
+
+
8.2. Informative References
[RFC4627] Crockford, D., "The application/json Media Type for
@@ -1109,18 +1081,6 @@ Authors' Addresses
EMail: fgaliegue@gmail.com
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 20]
-
-Internet-Draft JSON Schema September 2012
-
-
Kris Zyp (editor)
SitePen (USA)
530 Lytton Avenue
@@ -1156,21 +1116,5 @@ Internet-Draft JSON Schema September 2012
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 19, 2013 [Page 21]
+Galiegue, et al. Expires March 21, 2013 [Page 20]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index d2b982ab..3d579449 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -119,7 +119,13 @@
- However, regular expression dialects vary, sometimes widely, between programming
+ Implementations MUST NOT consider that regular expressions are anchored, neither
+ at the beginning or at the end. This means, for instance, that "es" matches
+ "expression".
+
+
+
+ Regular expression dialects vary, sometimes widely, between programming
languages, to the extent that a same regular expression token may behave
differently between programming languages. For instance, "\w", which is a common
idiom used to match a character which is "part of a word", will only match
@@ -129,14 +135,15 @@
- For this reason, if regular expressions need to be used in a schema meant to be
- used by peer implementations, it is RECOMMENDED that schema authors limit
+ For this reason, if regular expressions are used in a schema meant to be
+ processed by peer implementations, it is RECOMMENDED that schema authors limit
themselves to the following regular expression tokens:
individual Unicode characters, as defined by the JSON RFC (FIXME_LINK);simple character classes ([abc]), range character classes ([a-z]);
+ complemented character classes ([^abc], [^a-z]);quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), "{x}"
where "x" is an integer (exactly x occurrences), "{x,y}" where "x" and "y" are
integers (at least x, at most y, occurrences);
@@ -249,15 +256,15 @@
if "exclusiveMaximum" is not present, or has boolean value false,
- then the instance is valid if and only if it is greater than, or equal
- to, the value of "maximum";
+ then the instance is valid if and only if it is lower than, or equal to,
+ the value of "maximum";
if "exclusiveMaximum" is present and has boolean value true, the the
- instance is valid if and only if it is strictly greater than the value
- of "maximum".
+ instance is valid if and only if it is strictly lower than the value of
+ "maximum".
-
+
"exclusiveMaximum", if absent, may be considered as being present with
boolean value false.
@@ -286,10 +293,10 @@
if "exclusiveMinimum" is not present, or has boolean value false,
- then the instance is valid if and only if it is lower than, or equal
+ then the instance is valid if and only if it is greater than, or equal
to, the value of "minimum";if "exclusiveMinimum" is present and has boolean value true, the the
- instance is valid if and only if it is strictly lower than the value
+ instance is valid if and only if it is strictly greater than the value
of "minimum".
@@ -377,21 +384,6 @@
-
-
- Implementations MUST NOT consider that regular expressions are
- surrounded by either the beginning-of-input ("^") or end-of-input ("$")
- anchors. This means that, for instance, "x" matches "exercise".
-
-
- The ECMA 262 regular expression dialect has poor programming language
- support; the only programming language with native ECMA 262 regular
- expression support is JavaScript. It is therefore RECOMMENDED that
- schema authors limit themselves to the regular expression feature set
- defined in section FIXME_LINK.
-
-
-
@@ -534,8 +526,8 @@
- If this keyword has boolean value false, then the instance validates
- successfully. If it has boolean value true, then the instance validates
+ If this keyword has boolean value false, the instance validates
+ successfully. If it has boolean value true, the instance validates
successfully if and only if all of its elements are unique. In other
words, no two elements of the array instance should be equal as per the
definition in FIXME_LINK.
@@ -617,38 +609,6 @@
-
-
-
- Against this schema:
-
-
-
-
-
-
- the following instances are valid:
-
-
-
- { "a": 1, "b": 2 };
- { "a": 1, "b": 2, "c": 3 };
-
-
-
- the following instances are invalid:
-
-
-
- {} (the empty object);
- { "b": 2 } (required member name "a" is missing).
-
-
-
@@ -682,10 +642,23 @@
if its value is boolean true or a schema, validation succeeds;if its value is boolean false, the algorithm to determine validation
- success is described in the next section.
+ success is described below.
+
+
+ If either "properties" or "patternProperties" are absent, they can be
+ considered present with an empty object as a value (NOTE: an empty
+ object, NOT an empty schema).
+
+
+
+ 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 member names of
From c36f5187e6b4fd5e319ea909ea5ce7356e55da05 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Sep 2012 10:48:49 +0200
Subject: [PATCH 0101/1659] schema-core.json: add exclusiveM{in,ax}imum
property dependencies
---
proposals/schema-core.json | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 1e4ef613..3889f091 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -165,6 +165,10 @@
},
"not": { "$ref": "#" }
},
+ "dependencies": {
+ "exclusiveMaximum": "maximum",
+ "exclusiveMinimum": "minimum"
+ },
"default": {}
}
From 64f233486c5e30268f7a1ba0e5f845cb315ba770 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Sep 2012 11:51:48 +0200
Subject: [PATCH 0102/1659] schema-core.json: factorize common subschemas
This will clearly show, too, that JSON Reference support is required ;)
---
proposals/schema-core.json | 101 ++++++++++++++-----------------------
1 file changed, 37 insertions(+), 64 deletions(-)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 3889f091..bfa8a838 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -2,9 +2,29 @@
"id": "http://json-schema.org/current/schema-core.json#",
"$schema": "http://json-schema.org/current/schema-core.json#",
"description": "Core schema meta-schema",
- "primitive-types": {
- "enum": [ "array", "boolean", "integer", "null", "number", "object", "string", "any" ]
- },
+ "common": {
+ "primitiveTypes": {
+ "enum": [ "array", "boolean", "integer", "null", "number", "object", "string", "any" ]
+ },
+ "schemaArray": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "$ref": "#" }
+ },
+ "positiveInteger": {
+ "type": "integer",
+ "minimum": 0
+ },
+ "positiveIntegerDefault0": {
+ "allOf": [ { "$ref": "#/common/positiveInteger" }, { "default": 0 } ]
+ },
+ "stringArray": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "type": "string" },
+ "uniqueItems": true
+ }
+ }
"type": "object",
"properties": {
"id": {
@@ -41,15 +61,8 @@
"type": "boolean",
"default": false
},
- "maxLength": {
- "type": "integer",
- "minimum": 0
- },
- "minLength": {
- "type": "integer",
- "minimum": 0,
- "default": 0
- },
+ "maxLength": { "$ref": "#/common/positiveInteger" },
+ "minLength": { "$ref": "#/common/positiveIntegerDefault0" },
"pattern": {
"type": "string",
"format": "regex"
@@ -64,42 +77,19 @@
"items": {
"anyOf": [
{ "$ref": "#" },
- {
- "type": "array",
- "minItems": 1,
- "items": { "$ref": "#" }
- }
+ { "$ref": "#/common/schemaArray" }
],
"default": {}
},
- "maxItems": {
- "type": "integer",
- "minimum": 0
- },
- "minItems": {
- "type": "integer",
- "minimum": 0,
- "default": 0
- },
+ "maxItems": { "$ref": "#/common/positiveInteger" },
+ "minItems": { "$ref": "#/common/positiveIntegerDefault0" },
"uniqueItems": {
"type": "boolean",
"default": false
},
- "maxProperties": {
- "type": "integer",
- "minimum": 0
- },
- "minProperties": {
- "type": "integer",
- "minimum": 0,
- "default": 0
- },
- "required": {
- "type": "array",
- "minItems": 1,
- "items": { "type": "string" },
- "uniqueItems": true
- },
+ "maxProperties": { "$ref": "#/common/positiveInteger" },
+ "minProperties": { "$ref": "#/common/positiveIntegerDefault0" },
+ "required": { "$ref": "#/common/stringArray" },
"additionalProperties": {
"anyOf": [
{ "type": "boolean" },
@@ -122,12 +112,7 @@
"additionalProperties": {
"anyOf": [
{ "type": "string" },
- {
- "type": "array",
- "minItems": 1,
- "items": { "type": "string" },
- "uniqueItems": true
- },
+ { "$ref": "#/common/stringArray" },
{ "$ref": "#" }
]
}
@@ -139,30 +124,18 @@
},
"type": {
"anyOf": [
- { "$ref": "#/primitive-types" },
+ { "$ref": "#/common/primitiveTypes" },
{
"type": "array",
"minItems": 1,
- "items": { "$ref": "#/primitive-types" }
+ "items": { "$ref": "#/common/primitiveTypes" }
}
],
"default": "any"
},
- "allOf": {
- "type": "array",
- "minItems": 1,
- "items": { "$ref": "#" }
- },
- "anyOf": {
- "type": "array",
- "minItems": 1,
- "items": { "$ref": "#" }
- },
- "oneOf": {
- "type": "array",
- "minItems": 1,
- "items": { "$ref": "#" }
- },
+ "allOf": { "$ref": "#/common/schemaArray" },
+ "anyOf": { "$ref": "#/common/schemaArray" },
+ "oneOf": { "$ref": "#/common/schemaArray" },
"not": { "$ref": "#" }
},
"dependencies": {
From 6f1a09d83b3544ca4a6f0befe4b9f5be609f2608 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 18 Sep 2012 00:13:48 +0200
Subject: [PATCH 0103/1659] README.md update
---
README.md | 2 ++
1 file changed, 2 insertions(+)
diff --git a/README.md b/README.md
index a8a47eb3..9bdd88d7 100644
--- a/README.md
+++ b/README.md
@@ -14,6 +14,8 @@ Proposed specifications are here:
https://github.com/json-schema/json-schema/tree/next/proposals
+Pull requests _will_ be considered.
+
## The wiki
The wiki contains
From 58689f94cc0af2535fe4b8b1d0d09f87d0e6391f Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 18 Sep 2012 00:48:05 +0200
Subject: [PATCH 0104/1659] proposals/schema-core.json: add missing comma :/
---
proposals/schema-core.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index bfa8a838..53b58d97 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -24,7 +24,7 @@
"items": { "type": "string" },
"uniqueItems": true
}
- }
+ },
"type": "object",
"properties": {
"id": {
From 03230d4bb504c78f72e8867c6171651e6840fbc8 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 18 Sep 2012 22:27:38 +0200
Subject: [PATCH 0105/1659] Fix unseen typo
---
proposals/json-schema-core.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 17abb13c..c9e30727 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -162,7 +162,7 @@
both are nulls; orboth are booleans or strings, and have the same value; or
- both are numbers, and have the same JSON reprensetation; or
+ both are numbers, and have the same JSON representation; orboth are arrays, and:
have the same number of elements; and
From c4702a27278d06828d4cfe2a8465cbcfbbb66381 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 22 Sep 2012 18:16:17 +0200
Subject: [PATCH 0106/1659] Core specification updates
---
proposals/json-schema-core.txt | 274 ++++++++++++++++-----------------
proposals/json-schema-core.xml | 206 ++++++++++++-------------
2 files changed, 238 insertions(+), 242 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 4905b2a6..782e0287 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 21, 2013 SitePen (USA)
+Expires: March 26, 2013 SitePen (USA)
G. Court
- September 17, 2012
+ September 22, 2012
JSON Schema: core definitions and purposes
@@ -36,7 +36,7 @@ Status of This Memo
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 March 21, 2013.
+ This Internet-Draft will expire on March 26, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 21, 2013 [Page 1]
+Galiegue, et al. Expires March 26, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -63,33 +63,35 @@ Internet-Draft JSON Schema September 2012
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
- 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
- 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
- 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
- 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
- 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
- 5. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 6
- 5.1. Addressing mechanisms and general considerations . . . . . 6
- 5.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 6
- 5.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 6
- 5.4. Inner schema addressing . . . . . . . . . . . . . . . . . 6
- 5.5. Security considerations . . . . . . . . . . . . . . . . . 8
- 6. Schema/Instance Association . . . . . . . . . . . . . . . . . 8
- 6.1. Purpose of this section . . . . . . . . . . . . . . . . . 8
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
+ 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . . 3
+ 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . . 3
+ 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
+ 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Instance validation . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Hyperlinking . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.3. Design Considerations . . . . . . . . . . . . . . . . . . . 5
+ 5. Schema addressing . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Addressing mechanisms and general considerations . . . . . 6
+ 5.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 6
+ 5.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 6
+ 5.4. Inner schema addressing . . . . . . . . . . . . . . . . . . 6
+ 5.5. Security considerations . . . . . . . . . . . . . . . . . . 7
+ 6. Schema/Instance Association . . . . . . . . . . . . . . . . . . 8
+ 6.1. Purpose of this section . . . . . . . . . . . . . . . . . . 8
6.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 8
- 6.2.1. Correlation by means of the "Content-Type" header . . 8
- 6.2.2. Correlation by means of the "Link" header . . . . . . 9
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6.2.1. Correlation by means of the "Content-Type" header . . . 8
+ 6.2.2. Correlation by means of the "Link" header . . . . . . . 8
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 9
@@ -106,9 +108,7 @@ Table of Contents
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 2]
+Galiegue, et al. Expires March 26, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 21, 2013 [Page 3]
+Galiegue, et al. Expires March 26, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -200,9 +200,11 @@ Internet-Draft JSON Schema September 2012
both are nulls; or
- both are booleans or strings, and have the same value; or
+ both are booleans, and have the same value; or
+
+ both are strings, and have the same value; or
- both are numbers, and have the same JSON reprensetation; or
+ both are numbers, and evaluate to the same numeric value; or
both are arrays, and:
@@ -215,19 +217,16 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
- values for a same member are equal according to this
- definition.
-Galiegue, et al. Expires March 21, 2013 [Page 4]
+Galiegue, et al. Expires March 26, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
- Note about numbers: the two JSON number values, 1.0 and 1, for
- instance, are mathematically equivalent; however they are NOT equal,
- since their JSON representation differs.
+ values for a same member are equal according to this
+ definition.
3.5. Instance
@@ -246,25 +245,22 @@ Internet-Draft JSON Schema September 2012
Each purpose has a defined set of keywords which is described in its
own specification.
- Documentation JSON Schema can be used to decorate either itself, or
- instances, with descriptive text highlighting the schema's, or
- instance's, purposes.
+4.1. Instance validation
- Hyperlinking JSON Schema can be used to associate an instance to a
- Link Description Object, as defined by FIXME.
+ JSON Schema allows applications to validate any JSON instance, either
+ noninteractively or interactively. For instance, an application may
+ use an external service to collect JSON instances and check that
+ these collected instances match its requirements against a given
+ schema; another application may use a schema to build an interactve
+ interface in order to collect user input, and check the correctness
+ of said input.
- Validation JSON Schema can be used to validate the structure of an
- instance. Keywords also exist for semantic analysis, although
- implementations are not required to implement them.
+4.2. Hyperlinking
-4.1. Design Considerations
+ JSON Schema defines a mechanism to build links to a variety of
+ resources. FIXME: describe it better.
- JSON Schema provides a separate format for flexibly communicating how
- a JSON value should be interpreted and/or validated, such that
- clients can properly understand acceptable structures for, and/or
- extract the needed information from, the JSON instance being
- processed. This information ranges from documentation to external
- resource links, and processing of these links.
+4.3. Design Considerations
It is acknowledged that JSON values can be of any type defined by the
JSON specification. As such, JSON Schema does not mandate that an
@@ -273,32 +269,30 @@ Internet-Draft JSON Schema September 2012
add useful constraints to the structure and, optionally, semantics,
of the JSON instance being processed.
+ JSON Schema is agnostic with regards to both protocols and
+ programming languages. In particular, this means that defining the
+ semantics of the client-server interface is dependent on the protocol
+ being used.
-Galiegue, et al. Expires March 21, 2013 [Page 5]
+Galiegue, et al. Expires March 26, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
- JSON Schema is agnostic with regards to both protocols and
- programming languages. In particular, this means that defining the
- semantics of the client-server interface is dependent on the protocol
- being used.
-
5. Schema addressing
5.1. Addressing mechanisms and general considerations
- JSON Schema defines two addressing mechanisms: canonical addressing,
- and inner schema addressing. Implementations MUST support canonical
- addressing, and MAY support inner schema addressing.
+ JSON Schema addressing is done using URIs [RFC3986]. Two addressing
+ mechanisms are defined: canonical addressing and inner schema
+ addressing. Implementations MUST support canonical addressing, and
+ MAY support inner schema addressing.
Inner schema addressing is done by the means of the "id" keyword.
- The value of this keyword MUST be a string, and this string MUST be a
- valid URI, and MUST be normalized. When used in a root schema, the
- value of this keyword SHOULD be an absolute URI, and MUST have no
- fragment, or an empty fragment.
+ The value of this keyword MUST be a string; this string MUST be a
+ valid URI, and SHOULD be normalized.
5.2. URI of a root schema
@@ -306,44 +300,41 @@ Internet-Draft JSON Schema September 2012
considered to be the URI for this schema. If a schema is loaded
without a URI:
- if "id" is present in the root schema, and obeys the provisions in
- the previous paragraph, the value of "id" MAY be considered to be
- the schema URI;
+ if "id" is present in the root schema, its value MAY be considered
+ to be the schema URI;
otherwise, it is RECOMMENDED that implementations consider that
the URI of the schema is either the empty URI, or a URN.
- In addition, implementations MUST consider, for root schema URIs,
- that the URI with no fragment, or an empty fragment, are strictly
- equivalent.
-
5.3. Canonical addressing
Canonical addressing in JSON Schema is done using JSON Reference
- (FIXME_LINK). As defined by the JSON Reference specification, when
- encountering a JSON Reference, other schema keywords SHALL be
- ignored.
+ [json-reference]. JSON References, when encountered, MUST be
+ resolved against the root schema URI before being processed.
5.4. Inner schema addressing
When "id" is encountered in a subschema, implementations MAY resolve
this URI against the root schema's URI, and consider that the
canonical URI of this subschema is the calculated URI. This is
+ called inner schema addressing.
+ There SHOULD NOT be two identical "id" values in the same schema
+ which resolve to the same URI. If this is the case, subschema lookup
+ using inner schema addressing is undefined.
+ This schema will be taken as an example:
-Galiegue, et al. Expires March 21, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
- called inner schema addressing.
- There SHOULD NOT be two identical "id" values in the same schema.
- Failing that, subschema lookup using inner schema addressing is
- undefined.
- This schema will be taken as an example:
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
{
@@ -366,8 +357,8 @@ Internet-Draft JSON Schema September 2012
}
- Subschemas at the following URI-encoded JSON Pointers (starting from
- the root of the schema) have the following URIs:
+ Subschemas at the following URI-encoded JSON Pointer [json-pointer]s
+ (starting from the root schema) have the following URIs:
# (document root) http://x.y.z/rootschema.json#
@@ -381,37 +372,33 @@ Internet-Draft JSON Schema September 2012
#/schema3 some://where.else/completely#
+5.5. Security considerations
+ Inner schema addressing can produce canonical URIs which differ from
+ the canonical URI of the root schema. Implementations MAY choose,
+ for security reasons, to ignore inner schema addressing, and always
+ dereference canonical URIs. Schema authors SHALL NOT expect that
+ inner schema addressing be used by an implementation.
+ Dereferencing URIs may fail to complete, or may lead to content which
+ is not a JSON Schema (another type of JSON value, or not a JSON
+ value). It is RECOMMENDED that JSON Schema processing be stopped in
+ such a situation.
-
-Galiegue, et al. Expires March 21, 2013 [Page 7]
+Galiegue, et al. Expires March 26, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
-5.5. Security considerations
-
- Inner schema addressing can produce canonical URIs which differ from
- the canonical URI of the root schema. Implementations MAY choose,
- for security reasons, to ignore inner schema addressing, and always
- dereference canonical URIs. Schema authors SHALL NOT expect that
- inner schema addressing be used by an implementation.
-
- Dereferencing canonical URIs MAY fail to complete, or MAY lead to
- content which is not a JSON Schema (another type of JSON value, or
- not a JSON value). It is RECOMMENDED that JSON Schema processing be
- stopped in such a situation.
-
6. Schema/Instance Association
6.1. Purpose of this section
A JSON instance MAY be correlated to one, or even several, JSON
- Schemas. This correlation MAY be embodied witin existing protocol
+ Schemas. This correlation MAY be embodied within existing protocol
headers.
In addition, if the protocol also carries media type information (by
@@ -443,12 +430,6 @@ Internet-Draft JSON Schema September 2012
profile=http://example.com/my-hyper-schema
-
-Galiegue, et al. Expires March 21, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
-
6.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
@@ -462,6 +443,12 @@ Internet-Draft JSON Schema September 2012
An example of such a header would be:
+
+Galiegue, et al. Expires March 26, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
Link: ; rel="describedBy"
@@ -471,49 +458,51 @@ Internet-Draft JSON Schema September 2012
type name: application;
- subtype name: schema+json;
-
- required parameters: profile.
-
- FIXME: fragment resolution?
+ subtype name: schema+json.
8. References
8.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
- [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer", October 2011, <
- http://tools.ietf.org/html/
- draft-ietf-appsawg-json-pointer-04>.
+ [json-reference] Bryan, P. and K. Zyp, "JSON Reference",
+ September 2012, .
-8.2. Informative References
+ [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer",
+ September 2012, .
- [RFC4627] Crockford, D., "The application/json Media Type for
- JavaScript Object Notation (JSON)", RFC 4627,
- July 2006.
+8.2. Informative References
+ [RFC4627] Crockford, D., "The application/json Media Type for
+ JavaScript Object Notation (JSON)", RFC 4627,
+ July 2006.
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic
+ Syntax", STD 66, RFC 3986, January 2005.
+Appendix A. ChangeLog
+ TODO
+Authors' Addresses
+ Francis Galiegue
-Galiegue, et al. Expires March 21, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
+ EMail: fgaliegue@gmail.com
-Appendix A. ChangeLog
- TODO
-Authors' Addresses
- Francis Galiegue
- EMail: fgaliegue@gmail.com
+Galiegue, et al. Expires March 26, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
Kris Zyp (editor)
@@ -527,8 +516,6 @@ Authors' Addresses
Gary Court
- Calgary, AB
- Canada
EMail: gary.court@gmail.com
@@ -556,5 +543,18 @@ Authors' Addresses
-Galiegue, et al. Expires March 21, 2013 [Page 10]
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 10]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index c9e30727..b50bce70 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -1,7 +1,8 @@
+
+
]>
@@ -34,10 +35,6 @@
-
- Calgary, AB
- Canada
- gary.court@gmail.com
@@ -140,51 +137,45 @@
JSON Schema defines seven primitive types for JSON values:
+
+ A JSON array.
+ A JSON boolean (true or false).
+ A JSON number without a decimal part.
+ Any JSON number. Number includes integer.
+ The JSON null value.
+ A JSON object.
+ A JSON string.
+
-
-
- A JSON array.
- A JSON boolean (true or false).
- A JSON number without a decimal part.
- Any JSON number. Number includes integer.
- The JSON null value.
- A JSON object.
- A JSON string.
-
-
Two JSON values are said to be equal if and only if:
-
-
- both are nulls; or
- both are booleans or strings, and have the same value; or
- both are numbers, and have the same JSON representation; or
- both are arrays, and:
-
- have the same number of elements; and
- elements at the same index are equal according to this definition;
- or
-
-
- both are objects, and:
-
- have the same set of members; and
- values for a same member are equal according to this definition.
-
-
-
+
+ both are nulls; or
+ both are booleans, and have the same value; or
+ both are strings, and have the same value; or
+ both are numbers, and evaluate to the same numeric value; or
+ both are arrays, and:
+
+ have the same number of elements; and
+ elements at the same index are equal according to this
+ definition; or
+
+
+ both are objects, and:
+
+ have the same set of members; and
+ values for a same member are equal according to this
+ definition.
+
+
+
+
-
- Note about numbers: the two JSON number values, 1.0 and 1, for instance, are
- mathematically equivalent; however they are NOT equal, since their JSON
- representation differs.
-
-
An instance is any JSON value being processed by a JSON Schema. The
@@ -207,27 +198,25 @@
a defined set of keywords which is described in its own specification.
-
- JSON Schema can be used to decorate either itself, or
- instances, with descriptive text highlighting the schema's, or instance's,
- purposes.
-
- JSON Schema can be used to associate an instance to a
- Link Description Object, as defined by FIXME.
- JSON Schema can be used to validate the structure of an
- instance. Keywords also exist for semantic analysis, although implementations are
- not required to implement them.
-
+
+
+ JSON Schema allows applications to validate any JSON instance, either
+ noninteractively or interactively. For instance, an application may use an
+ external service to collect JSON instances and check that these collected
+ instances match its requirements against a given schema; another application may
+ use a schema to build an interactve interface in order to collect user input,
+ and check the correctness of said input.
+
+
-
+
- JSON Schema provides a separate format for flexibly communicating how a JSON
- value should be interpreted and/or validated, such that clients can properly
- understand acceptable structures for, and/or extract the needed information
- from, the JSON instance being processed. This information ranges from
- documentation to external resource links, and processing of these links.
+ JSON Schema defines a mechanism to build links to a variety of resources. FIXME:
+ describe it better.
+
+
It is acknowledged that JSON values can be of any type defined by the JSON
specification. As such, JSON Schema does not mandate that an instance be of a
@@ -248,16 +237,16 @@
- JSON Schema defines two addressing mechanisms: canonical addressing, and inner
- schema addressing. Implementations MUST support canonical addressing, and MAY
- support inner schema addressing.
+ JSON Schema addressing is done using URIs. Two
+ addressing mechanisms are defined: canonical addressing and inner schema
+ addressing. Implementations MUST support canonical addressing, and MAY support
+ inner schema addressing.
Inner schema addressing is done by the means of the "id" keyword. The value of
- this keyword MUST be a string, and this string MUST be a valid URI, and MUST be
- normalized. When used in a root schema, the value of this keyword SHOULD be an
- absolute URI, and MUST have no fragment, or an empty fragment.
+ this keyword MUST be a string; this string MUST be a valid URI, and SHOULD be
+ normalized.
@@ -265,28 +254,22 @@
When a schema is loaded via a URI, the loading URI SHALL be considered to be the
URI for this schema. If a schema is loaded without a URI:
-
-
-
- if "id" is present in the root schema, and obeys the provisions in the
- previous paragraph, the value of "id" MAY be considered to be the schema
- URI;
- otherwise, it is RECOMMENDED that implementations consider that the URI of
- the schema is either the empty URI, or a URN.
-
-
- In addition, implementations MUST consider, for root schema URIs, that the URI
- with no fragment, or an empty fragment, are strictly equivalent.
+
+ if "id" is present in the root schema, its value MAY be considered to be
+ the schema URI;
+ otherwise, it is RECOMMENDED that implementations consider that the URI
+ of the schema is either the empty URI, or a URN.
+
-
- Canonical addressing in JSON Schema is done using JSON Reference (FIXME_LINK).
- As defined by the JSON Reference specification, when encountering a JSON
- Reference, other schema keywords SHALL be ignored.
+ Canonical addressing in JSON Schema is done using JSON Reference. JSON References, when
+ encountered, MUST be resolved against the root schema URI before being
+ processed.
@@ -298,8 +281,9 @@
- There SHOULD NOT be two identical "id" values in the same schema. Failing that,
- subschema lookup using inner schema addressing is undefined.
+ There SHOULD NOT be two identical "id" values in the same schema which resolve
+ to the same URI. If this is the case, subschema lookup using inner schema
+ addressing is undefined.
@@ -334,19 +318,19 @@
- Subschemas at the following URI-encoded JSON Pointers (starting from the root of
- the schema) have the following URIs:
+ Subschemas at the following URI-encoded JSON
+ Pointers (starting from the root schema) have the following URIs:
+
+
+ http://x.y.z/rootschema.json#
+ http://x.y.z/rootschema.json#foo
+ http://x.y.z/otherschema.json#
+ http://x.y.z/rootschema.json#bar
+ http://x.y.z/t/inner.json#a
+ some://where.else/completely#
+
-
- http://x.y.z/rootschema.json#
- http://x.y.z/rootschema.json#foo
- http://x.y.z/otherschema.json#
- http://x.y.z/rootschema.json#bar
- http://x.y.z/t/inner.json#a
- some://where.else/completely#
-
-
@@ -359,9 +343,9 @@
- Dereferencing canonical URIs MAY fail to complete, or MAY lead to content which
- is not a JSON Schema (another type of JSON value, or not a JSON value). It is
- RECOMMENDED that JSON Schema processing be stopped in such a situation.
+ Dereferencing URIs may fail to complete, or may lead to content which is not a
+ JSON Schema (another type of JSON value, or not a JSON value). It is RECOMMENDED
+ that JSON Schema processing be stopped in such a situation.
@@ -371,7 +355,7 @@
A JSON instance MAY be correlated to one, or even several, JSON Schemas. This
- correlation MAY be embodied witin existing protocol headers.
+ correlation MAY be embodied within existing protocol headers.
@@ -452,14 +436,12 @@ Link: ; rel="describedBy"
The proposed MIME media type for JSON Schema is defined as follows:
-
-
- type name: application;
- subtype name: schema+json;
- required parameters: profile.
- FIXME: fragment resolution?
-
+
+ type name: application;
+ subtype name: schema+json.
+
+
@@ -468,6 +450,19 @@ Link: ; rel="describedBy"
&RFC2119;
+
+
+ JSON Reference
+
+ ForgeRock US, Inc.
+
+
+ SitePen (USA)
+
+
+
+
@@ -478,12 +473,13 @@ Link: ; rel="describedBy"
SitePen (USA)
-
+
&RFC4627;
+ &RFC3986;
From c12ed4bbcbeb904f440bf8face86c59c52a881a5 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 22 Sep 2012 19:20:50 +0200
Subject: [PATCH 0107/1659] Validation spec updates
* "divisibleBy" -> "multipleOf";
* add/fix links (but not all);
* property dependencies have disappeared;
* "type" can only have one string argument;
* add interactive/non interactive validation considerations.
---
proposals/json-schema-validation.txt | 498 +++++++++++++--------------
proposals/json-schema-validation.xml | 415 +++++++++++-----------
proposals/schema-core.json | 37 +-
3 files changed, 467 insertions(+), 483 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 3e92ad84..790c9061 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -4,21 +4,23 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 21, 2013 SitePen (USA)
+Expires: March 26, 2013 SitePen (USA)
G. Court
- September 17, 2012
+ September 22, 2012
- JSON Schema: instance validation
+ JSON Schema: interactive and non interactive validation
json-schema-validation
Abstract
JSON Schema (application/schema+json) has several purposes, one of
- which is instance validation. This validation can be non
- interactive. This specification describes schema keywords dedicated
- to validation purposes, what value these keywords should have and how
- to validate JSON instances against these keywords.
+ 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.
Status of This Memo
@@ -35,7 +37,7 @@ Status of This Memo
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 March 21, 2013.
+ This Internet-Draft will expire on March 26, 2013.
Copyright Notice
@@ -47,16 +49,16 @@ Copyright Notice
(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
-Galiegue, et al. Expires March 21, 2013 [Page 1]
+Galiegue, et al. Expires March 26, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
+ 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.
@@ -65,54 +67,56 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Interoperability considerations . . . . . . . . . . . . . . . 4
- 3.1. Validation of numeric instances . . . . . . . . . . . . . 4
- 3.2. Regular expressions . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Validation of string instances . . . . . . . . . . . . . . 4
+ 3.2. Validation of numeric instances . . . . . . . . . . . . . 4
+ 3.3. Regular expressions . . . . . . . . . . . . . . . . . . . 5
4. General validation considerations . . . . . . . . . . . . . . 5
- 4.1. Keywords and instance primitive types . . . . . . . . . . 5
- 4.2. Validation of container instances . . . . . . . . . . . . 6
+ 4.1. Keywords and instance primitive types . . . . . . . . . . 6
+ 4.2. Inter-dependent keywords . . . . . . . . . . . . . . . . . 6
+ 4.3. Default values for missing keywords . . . . . . . . . . . 6
+ 4.4. Validation of container instances . . . . . . . . . . . . 6
5. Validation keywords sorted by instance types . . . . . . . . . 6
5.1. Validation keywords for numeric instances (number and
integer) . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.1.1. divisibleBy . . . . . . . . . . . . . . . . . . . . . 6
- 5.1.2. maximum and exclusiveMaximum . . . . . . . . . . . . . 6
+ 5.1.1. multipleOf . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.1.2. maximum and exclusiveMaximum . . . . . . . . . . . . . 7
5.1.3. minimum and exclusiveMinimum . . . . . . . . . . . . . 7
5.2. Validation keywords for strings . . . . . . . . . . . . . 8
5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8
- 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Validation keywords for arrays . . . . . . . . . . . . . . 9
5.3.1. additionalItems and items . . . . . . . . . . . . . . 9
5.3.2. maxItems . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.4. uniqueItems . . . . . . . . . . . . . . . . . . . . . 11
5.4. Validation keywords for objects . . . . . . . . . . . . . 11
- 5.4.1. maxProperties . . . . . . . . . . . . . . . . . . . . 11
+ 5.4.1. maxProperties . . . . . . . . . . . . . . . . . . . . 12
5.4.2. minProperties . . . . . . . . . . . . . . . . . . . . 12
5.4.3. required . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. additionalProperties, properties and
patternProperties . . . . . . . . . . . . . . . . . . 12
- 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 14
+ 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 15
5.5. Validation keywords for any instance type . . . . . . . . 15
5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6. Calculating schemas which children instances must validate
- against . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.1. Defining characteristic . . . . . . . . . . . . . . . 18
- 6.2.2. Implied keywords and default values. . . . . . . . . . 18
+ 6. Calculatin child instances' schema(s) . . . . . . . . . . . . 17
-Galiegue, et al. Expires March 21, 2013 [Page 2]
+Galiegue, et al. Expires March 26, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
+ 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.1. Defining characteristic . . . . . . . . . . . . . . . 18
+ 6.2.2. Implied keywords and default values. . . . . . . . . . 18
6.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 18
6.3. Object values . . . . . . . . . . . . . . . . . . . . . . 18
6.3.1. Defining characteristic . . . . . . . . . . . . . . . 18
@@ -160,11 +164,7 @@ Internet-Draft JSON Schema September 2012
-
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 3]
+Galiegue, et al. Expires March 26, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -174,11 +174,13 @@ Internet-Draft JSON Schema September 2012
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.
Validation is primarily concerned about structural validation of
- instances. Extensions also exist to perform semantic analysis, but
- these are part of another specification.
+ instances. Keywords also exist to perform semantic analysis;
+ however, support for these keywords is optional.
This specification will use the terminology defined by the JSON
Schema core specification. It is advised that readers have a copy of
@@ -194,18 +196,39 @@ Internet-Draft JSON Schema September 2012
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 "member set" for an object instance
+ as the set of its member names; for instance, the member set of
+ object value { "a": 1, "b": 2 } is [ "a", "b" ]
+
3. Interoperability considerations
-3.1. Validation of numeric instances
+3.1. Validation of string instances
+
+ It should be noted that the null character (\x00) is valid in JSON
+ string values. JSON Schema does not define any further constraints
+ than RFC 4627 [RFC4627] on validated instances, and as such, an
+ instance to validate MAY be and/or contain such a string value,
+ regardless of the ability of the underlying programming language to
+ deal with such data.
+
+3.2. Validation of numeric instances
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
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 4]
+
+Internet-Draft JSON Schema September 2012
+
+
decimal part, regardless of the ability of the underlying programming
language to deal with such data.
-3.2. Regular expressions
+3.3. Regular expressions
Two validation keywords, "pattern" and "patternProperties", use
regular expressions as a part of validation mechanics. These regular
@@ -213,31 +236,19 @@ Internet-Draft JSON Schema September 2012
expression dialect.
Implementations MUST NOT consider that regular expressions are
- anchored, neither at the beginning or at the end. This means, for
+ anchored, neither at the beginning nor at the end. This means, for
instance, that "es" matches "expression".
Regular expression dialects vary, sometimes widely, between
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 4]
-
-Internet-Draft JSON Schema September 2012
-
-
- programming languages, to the extent that a same regular expression
- token may behave differently between programming languages. For
- instance, "\w", which is a common idiom used to match a character
- which is "part of a word", will only match letters, digits and the
- underscore in the US-ASCII character set in Java, whereas it matches
- any Unicode alphanumeric character, plus the underscore, in ECMA 262.
-
- For this reason, if regular expressions are used in a schema meant to
- be processed by peer implementations, it is RECOMMENDED that schema
- authors limit themselves to the following regular expression tokens:
+ programming languages, to the extent that a same commonly used
+ regular expression token may behave differently between programming
+ languages. For this reason, if regular expressions are used in a
+ schema meant to be processed by peer implementations, it is
+ RECOMMENDED that schema authors limit themselves to the following
+ regular expression tokens:
individual Unicode characters, as defined by the JSON RFC
- (FIXME_LINK);
+ [RFC4627];
simple character classes ([abc]), range character classes ([a-z]);
@@ -254,10 +265,22 @@ Internet-Draft JSON Schema September 2012
Schema authors choosing to use other regular expression features in
their schemas SHOULD NOT expect peer implementations to support these
- features.
+ features. Should an implementation fail to correctly interpret a
+ regular expression, it is RECOMMENDED that JSON Schema processing be
+ considered a failure.
4. General validation considerations
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 5]
+
+Internet-Draft JSON Schema September 2012
+
+
4.1. Keywords and instance primitive types
Some validation keywords only apply to one or more primitive types.
@@ -269,43 +292,50 @@ Internet-Draft JSON Schema September 2012
to the primitive type, or types, these keywords validate. Note that
some keywords validate all instance types.
- Additionally, validation of some keywords are influenced by the
- presence of other keywords. In this case, all these keywords will be
- grouped in the same section.
+4.2. Inter-dependent keywords
+ 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.
+4.3. Default values for missing keywords
+ Some keywords, if absent, MAY be regarded by implementations as
+ having a default value. In this case, the default value will be
+ mentioned.
-Galiegue, et al. Expires March 21, 2013 [Page 5]
-
-Internet-Draft JSON Schema September 2012
+4.4. Validation of container instances
+ Keywords with the possibility to validate container instances only
+ validate this instance's structure, not this instance's children.
+ Some of these keywords do, however, contain information which is
+ necessary for calculating which schema(s) a child instance must be
+ valid against. 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.
- Finally, some keywords, if absent, MAY be regarded by implementations
- as having a default value. In this case, the default value will be
- mentioned.
+ The algorithms to calculate a child instance's relevant schema(s) are
+ explained in a separate section. While such calculation may be done
+ in real time for applications performing interactive validation, it
+ is RECOMMENDED that applications performing non interactive
+ validation do not attempt to validate children until the container
+ instance itself has been validated succesfully.
-4.2. Validation of container instances
+5. Validation keywords sorted by instance types
- It should be noted that keywords with the possibility to validate
- container instances only validate this instance's structure. They do
- not, in and out of them, validate children instances. Some of these
- keywords do, however, influence the schema, or schemas, which a child
- instance must validate.
+5.1. Validation keywords for numeric instances (number and integer)
- The algorithms to determine the schema, or schemas, which a child
- instance must validate against are explained in separate sections
- (FIXME_LINK).
+5.1.1. multipleOf
- It is RECOMMENDED that implementations do not validate a container
- instance's children until the container instance itself has validated
- successfully against all relevant keywords.
-5. Validation keywords sorted by instance types
-5.1. Validation keywords for numeric instances (number and integer)
-5.1.1. divisibleBy
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+
5.1.1.1. Valid values
@@ -314,9 +344,9 @@ Internet-Draft JSON Schema September 2012
5.1.1.2. Conditions for successful validation
- A numeric instance is valid against "divisibleBy" if and only if the
- remainder of the division of the instance by this keyword's value is
- exactly 0.
+ A numeric instance is valid against "multipleOf" if and only if the
+ result of the division of the instance by this keyword's value is an
+ integer.
5.1.2. maximum and exclusiveMaximum
@@ -327,16 +357,6 @@ Internet-Draft JSON Schema September 2012
If "exclusiveMaximum" is present, "maximum" MUST also be present.
-
-
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
-
-
5.1.2.2. Conditions for successful validation
Successful validation depends on the presence and value of
@@ -364,6 +384,15 @@ Internet-Draft JSON Schema September 2012
If "exclusiveMinimum" is present, "minimum" MUST also be present.
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+
+
5.1.3.2. Conditions for successful validation
Successful validation depends on the presence and value of
@@ -382,17 +411,6 @@ Internet-Draft JSON Schema September 2012
"exclusiveMinimum", if absent, may be considered as being present
with boolean value false.
-
-
-
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
-
-
5.2. Validation keywords for strings
5.2.1. maxLength
@@ -408,7 +426,7 @@ Internet-Draft JSON Schema September 2012
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 FIXME_LINK.
+ characters as defined by RFC 4627 [RFC4627].
5.2.2. minLength
@@ -423,7 +441,15 @@ Internet-Draft JSON Schema September 2012
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 FIXME_LINK.
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
+ characters as defined by RFC 4627 [RFC4627].
5.2.2.3. Default value
@@ -434,20 +460,9 @@ Internet-Draft JSON Schema September 2012
5.2.3.1. Valid values
- The value for this keyword MUST be a string. This string MUST be a
+ The value for this keyword MUST be a string. This string SHOULD be a
valid regular expression, according to the ECMA 262 regular
- expression dialect, as defined by FIXME_LINK.
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
+ expression dialect.
5.2.3.2. Conditions for successful validation
@@ -482,6 +497,14 @@ Internet-Draft JSON Schema September 2012
if the value of additionalItems is boolean value false and the
value of items is an array (which is must be at this point), the
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
instance is valid if and only if its number of elements is less
than, or equal to, the number of elements in the array value of
items.
@@ -493,18 +516,6 @@ Internet-Draft JSON Schema September 2012
only situation under which an instance may fail to validate
successfully.
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
This is an example schema:
@@ -540,6 +551,16 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be an integer. This integer MUST be
greater than, or equal to, 0.
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 10]
+
+Internet-Draft JSON Schema September 2012
+
+
5.3.2.2. Conditions for successful validation
An array instance is valid against "maxItems" if and only if its
@@ -553,14 +574,6 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be an integer. This integer MUST be
greater than, or equal to, 0.
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
-
-
5.3.3.2. Conditions for successful validation
An array instance is valid against "minItems" if and only if its
@@ -593,29 +606,29 @@ Internet-Draft JSON Schema September 2012
5.4. Validation keywords for objects
-5.4.1. maxProperties
-5.4.1.1. Valid values
- The value for this keyword MUST be an integer. This integer MUST be
- greater than, or equal to, 0.
-5.4.1.2. Conditions for successful validation
- An object instance is valid against "maxProperties" if and only if
- its number of members is less than, or equal to, the value of this
- keyword.
+Galiegue, et al. Expires March 26, 2013 [Page 11]
+
+Internet-Draft JSON Schema September 2012
+5.4.1. maxProperties
+5.4.1.1. Valid values
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
-Galiegue, et al. Expires March 21, 2013 [Page 11]
-
-Internet-Draft JSON Schema September 2012
+5.4.1.2. Conditions for successful validation
+ An object instance is valid against "maxProperties" if and only if
+ its number of members is less than, or equal to, the value of this
+ keyword.
5.4.2. minProperties
@@ -645,12 +658,21 @@ Internet-Draft JSON Schema September 2012
5.4.3.2. Conditions for successful validation
- An object instance is valid against this keyword if and only if the
- set of its member names contains all elements in this keyword's
- array.
+ An object instance is valid against this keyword if and only if its
+ member set contains all elements in this keyword's array.
5.4.4. additionalProperties, properties and patternProperties
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 12]
+
+Internet-Draft JSON Schema September 2012
+
+
5.4.4.1. Valid values
The value of "additionalProperties" MUST be a boolean or an object.
@@ -661,17 +683,9 @@ Internet-Draft JSON Schema September 2012
Schema.
The value of "patternProperties" MUST be an object. Each member name
- of this object MUST be a valid regular expression, according to the
- ECMA 262 regular expression dialect, as defined by FIXME_LINK. Each
- value of this object MUST be an object, and each object MUST be a
- valid JSON Schema.
-
-
-
-Galiegue, et al. Expires March 21, 2013 [Page 12]
-
-Internet-Draft JSON Schema September 2012
-
+ of this object SHOULD be a valid regular expression, according to the
+ ECMA 262 regular expression dialect. Each value of this object MUST
+ be an object, and each object MUST be a valid JSON Schema.
5.4.4.2. Conditions for successful validation
@@ -694,39 +708,42 @@ Internet-Draft JSON Schema September 2012
5.4.4.4. If "additionalProperties" has boolean value false
- In this case, validation of the instance depends on the member names
- of "properties" and "patternProperties". In this section, member
- names of "patternProperties" will be called regexes for convenience.
+ In this case, validation of the instance depends on the member set of
+ "properties" and "patternProperties". In this section, the elements
+ of "patternProperties"' member set will be called regexes for
+ convenience.
The first step is to collect the following sets:
- s The set of member names of the instance to validate.
+ s The member set of the instance to validate.
- p The set of member names from "properties".
+ p The member set from "properties".
- The set of regexes from "patternProperties".
- Having collected these three sets, the process is as follows:
- remove from "s" all members of "p", if any;
- for each regex in "pp", remove all members of "s" which this regex
- matches.
- Validation of the instance succeeds if and only if, after these two
- steps, set "s" is empty.
-5.4.4.5. Example
+Galiegue, et al. Expires March 26, 2013 [Page 13]
+
+Internet-Draft JSON Schema September 2012
- This schema will be used as an example:
+ pp The member set from "patternProperties".
+ Having collected these three sets, the process is as follows:
+ remove from "s" all elements of "p", if any;
+ for each regex in "pp", remove all elements of "s" which this
+ regex matches.
-Galiegue, et al. Expires March 21, 2013 [Page 13]
-
-Internet-Draft JSON Schema September 2012
+ Validation of the instance succeeds if and only if, after these two
+ steps, set "s" is empty.
+
+5.4.4.5. Example
+
+ This schema will be used as an example:
{
@@ -735,7 +752,7 @@ Internet-Draft JSON Schema September 2012
},
"patternProperties": {
"p": {},
- "\\d": {}
+ "[0-9]": {}
}
}
@@ -757,58 +774,47 @@ Internet-Draft JSON Schema September 2012
s { "p1", "p2", "a32&o", "", "finance", "apple" }
- p { "p1" }
- pp { "p", "\\d" }
- Applying the two steps of the algorithm:
- after the first step, "p1" is removed from "s";
- after the second step, "p2", "a32&o" and "apple" are removed from
- "s".
- The set still contains two elements, "" and "finance". Validation
- therefore fails.
-
-5.4.5. dependencies
-5.4.5.1. Valid values
+Galiegue, et al. Expires March 26, 2013 [Page 14]
+
+Internet-Draft JSON Schema September 2012
- This keyword's value MUST be an object. Values for this object MUST
- be either of a string, an array or an object. If the value is an
+ p { "p1" }
+ pp { "p", "[0-9]" }
-Galiegue, et al. Expires March 21, 2013 [Page 14]
-
-Internet-Draft JSON Schema September 2012
+ Applying the two steps of the algorithm:
+ after the first step, "p1" is removed from "s";
- object, it MUST be a valid JSON Schema.
+ after the second step, "p2" (matched by "p"), "a32&o" (matched by
+ "[0-9]) and "apple" (matched by "p") are removed from "s".
- If the value is an array:
+ The set still contains two elements, "" and "finance". Validation
+ therefore fails.
- this array MUST have at least one element;
+5.4.5. dependencies
- elements of this array MUST be strings;
+5.4.5.1. Valid values
- elements of this array MUST be unique.
+ This keyword's value MUST be an object. This object MUST be a valid
+ JSON Schema.
5.4.5.2. Conditions for successful validation
- For each member name in the object instance with an equivalent member
- name in "dependencies":
+ For each element in the object instance's member set, if
+ "dependencies" contains a member by the same name, the object
+ instance must validate successfully against the matching schema in
+ "dependencies".
- if the value in "dependencies" is an object, therefore a schema,
- then the object instance is considered valid if and only if it
- also validates successfully against this schema (note: the object
- instance itself, not the value of that particular member);
-
- if the value in "dependencies" is a string or an array of strings,
- this (these) strings should be considered as member name(s), and
- the object instance is required to have members by the same
- name(s) in order to validate successfully.
+ Note that this is the object instance itself which must validate
+ successfully, not the value associated with that member.
5.5. Validation keywords for any instance type
@@ -824,34 +830,29 @@ Internet-Draft JSON Schema September 2012
5.5.1.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
- if its value is exactly equal to one of the elements in this
- keyword's array value, according to the definition in FIXME_LINK.
-
-5.5.2. type
+ if its value is equal to one of the elements in this keyword's array
+ value.
-5.5.2.1. Valid values
- The value of this keyword MUST be a string or an array. If the value
- is an array, elements of this array MUST be unique. This keyword's
-
-Galiegue, et al. Expires March 21, 2013 [Page 15]
+Galiegue, et al. Expires March 26, 2013 [Page 15]
Internet-Draft JSON Schema September 2012
- string value, or array element values, MUST be either of:
+5.5.2. type
- one of the seven primitive types defined by FIXME_LINK; or
+5.5.2.1. Valid values
- "any", which is equivalent to all seven primitive types.
+ The value of this keyword MUST be a string. The value of this string
+ MUST be one of the seven primitive types defined by FIXME_LINK.
5.5.2.2. Conditions for successful validation
- An instance matches successfully if and only if its primitive type,
- as defined in FIXME_LINK, is one of the primitive types allowed by
- this keyword's value. Recall: "number" includes "integer".
+ An instance matches successfully if and only if its primitive type is
+ the one defined by the value of this keyword. Recall: "number"
+ includes "integer".
5.5.3. allOf
@@ -885,18 +886,19 @@ Internet-Draft JSON Schema September 2012
if it validates successfully against at least one defined by this
keyword's value.
-5.5.5. oneOf
-Galiegue, et al. Expires March 21, 2013 [Page 16]
+Galiegue, et al. Expires March 26, 2013 [Page 16]
Internet-Draft JSON Schema September 2012
+5.5.5. oneOf
+
5.5.5.1. Valid values
This keyword's value MUST be an array. This array MUST have at least
@@ -923,13 +925,12 @@ Internet-Draft JSON Schema September 2012
An instance is valid against this keyword if and only if it fails to
validate successfully against the schema defined by this keyword.
-6. Calculating schemas which children instances must validate against
+6. Calculatin child instances' schema(s)
6.1. Foreword
Calculating the schema, or schemas, a child instance must validate
- against is influenced by the following, in addition to the container
- instance type:
+ against is influenced by the following:
the container instance type;
@@ -947,8 +948,7 @@ Internet-Draft JSON Schema September 2012
-
-Galiegue, et al. Expires March 21, 2013 [Page 17]
+Galiegue, et al. Expires March 26, 2013 [Page 17]
Internet-Draft JSON Schema September 2012
@@ -1004,7 +1004,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 21, 2013 [Page 18]
+Galiegue, et al. Expires March 26, 2013 [Page 18]
Internet-Draft JSON Schema September 2012
@@ -1024,12 +1024,12 @@ Internet-Draft JSON Schema September 2012
m The member name the child instance is associated to.
- p The set of member names from "properties", if any.
+ p The member set from "properties".
- pp The set of member names from "patternProperties", if any. Member
- names from this set will be called regexes for convenience.
+ pp The member set from "patternProperties". Elements of this set
+ will be called regexes for convenience.
- s The set of schemas the child instance must validate against.
+ s The set of schemas for the child instance.
6.3.3.2. First step: schemas in "properties"
@@ -1060,7 +1060,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 21, 2013 [Page 19]
+Galiegue, et al. Expires March 26, 2013 [Page 19]
Internet-Draft JSON Schema September 2012
@@ -1092,8 +1092,6 @@ Authors' Addresses
Gary Court
- Calgary, AB
- Canada
EMail: gary.court@gmail.com
@@ -1116,5 +1114,7 @@ Authors' Addresses
-Galiegue, et al. Expires March 21, 2013 [Page 20]
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 20]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index 3d579449..a506c0a3 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -11,7 +11,7 @@
- JSON Schema: instance validation
+ JSON Schema: interactive and non interactive validation
@@ -34,10 +34,6 @@
-
- Calgary, AB
- Canada
- gary.court@gmail.com
@@ -51,9 +47,11 @@
JSON Schema (application/schema+json) has several purposes, one of which is instance
- validation. This validation can be non interactive. This specification describes
- schema keywords dedicated to validation purposes, what value these keywords should
- have and how to validate JSON instances against these keywords.
+ 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.
@@ -63,13 +61,15 @@
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.
+ 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.
Validation is primarily concerned about structural validation of instances.
- Extensions also exist to perform semantic analysis, but these are part of another
- specification.
+ Keywords also exist to perform semantic analysis; however, support for these
+ keywords is optional.
@@ -94,10 +94,29 @@
object instances. It uses the term "children instances" to refer to array elements
or object member values.
+
+
+ This specification uses the term "member set" for an object instance as the set of
+ its member names; for instance, the member set of object value { "a": 1, "b": 2 } is
+ [ "a", "b" ]
+
+
+
+
+
+ It should be noted that the null character (\x00) is valid in JSON string
+ values. JSON Schema does not define any further constraints than RFC 4627 on validated instances, and as such, an
+ instance to validate MAY be and/or contain such a string value, regardless of
+ the ability of the underlying programming language to deal with such data.
+
+
+
+
@@ -120,40 +139,36 @@
Implementations MUST NOT consider that regular expressions are anchored, neither
- at the beginning or at the end. This means, for instance, that "es" matches
+ at the beginning nor at the end. This means, for instance, that "es" matches
"expression".
Regular expression dialects vary, sometimes widely, between programming
- languages, to the extent that a same regular expression token may behave
- differently between programming languages. For instance, "\w", which is a common
- idiom used to match a character which is "part of a word", will only match
- letters, digits and the underscore in the US-ASCII character set in Java,
- whereas it matches any Unicode alphanumeric character, plus the underscore, in
- ECMA 262.
+ languages, to the extent that a same commonly used regular expression token may
+ behave differently between programming languages. For this reason, if regular
+ expressions are used in a schema meant to be processed by peer implementations,
+ it is RECOMMENDED that schema authors limit themselves to the following regular
+ expression tokens:
+
+
+ individual Unicode characters, as defined by the JSON RFC;
+ simple character classes ([abc]), range character classes ([a-z]);
+ complemented character classes ([^abc], [^a-z]);
+ quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one),
+ "{x}" where "x" is an integer (exactly x occurrences), "{x,y}" where "x" and
+ "y" are integers (at least x, at most y, occurrences);
+ the beginning-of-input ("^") and end-of-input ("$") anchors;
+ grouping ("(...)") and alternation ("|").
+
-
- For this reason, if regular expressions are used in a schema meant to be
- processed by peer implementations, it is RECOMMENDED that schema authors limit
- themselves to the following regular expression tokens:
-
-
-
- individual Unicode characters, as defined by the JSON RFC (FIXME_LINK);
- simple character classes ([abc]), range character classes ([a-z]);
- complemented character classes ([^abc], [^a-z]);
- quantifiers: "+" (one or more), "*" (zero or more), "?" (zero or one), "{x}"
- where "x" is an integer (exactly x occurrences), "{x,y}" where "x" and "y" are
- integers (at least x, at most y, occurrences);
- the beginning-of-input ("^") and end-of-input ("$") anchors;
- grouping ("(...)") and alternation ("|").
-
-
Schema authors choosing to use other regular expression features in their
- schemas SHOULD NOT expect peer implementations to support these features.
+ schemas SHOULD NOT expect peer implementations to support these features. Should
+ an implementation fail to correctly interpret a regular expression, it is
+ RECOMMENDED that JSON Schema processing be considered a failure.
@@ -176,36 +191,44 @@
validate all instance types.
+
+
+
+
- Additionally, validation of some keywords are influenced by the presence of
- other keywords. In this case, all these keywords will be grouped in the same
- section.
+ 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.
+
+
+
+
- Finally, some keywords, if absent, MAY be regarded by implementations as having
+ Some keywords, if absent, MAY be regarded by implementations as having
a default value. In this case, the default value will be mentioned.
+
- It should be noted that keywords with the possibility to validate container
- instances only validate this instance's structure. They do not, in and out of
- them, validate children instances. Some of these keywords do, however,
- influence the schema, or schemas, which a child instance must validate.
-
-
-
- The algorithms to determine the schema, or schemas, which a child instance must
- validate against are explained in separate sections (FIXME_LINK).
+ Keywords with the possibility to validate container instances only validate this
+ instance's structure, not this instance's children. Some of these keywords do,
+ however, contain information which is necessary for calculating which schema(s)
+ a child instance must be valid against. 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.
- It is RECOMMENDED that implementations do not validate a container instance's
- children until the container instance itself has validated successfully against
- all relevant keywords.
+ The algorithms to calculate a child instance's relevant schema(s) are explained
+ in a separate section. While such calculation may be done in real time for
+ applications performing interactive validation, it is RECOMMENDED that
+ applications performing non interactive validation do not attempt to validate
+ children until the container instance itself has been validated succesfully.
@@ -215,8 +238,7 @@
-
-
+
@@ -227,9 +249,9 @@
- A numeric instance is valid against "divisibleBy" if and only if the
- remainder of the division of the instance by this keyword's value is
- exactly 0.
+ A numeric instance is valid against "multipleOf" if and only if the
+ result of the division of the instance by this keyword's value is
+ an integer.
@@ -252,16 +274,16 @@
Successful validation depends on the presence and value of
"exclusiveMaximum":
-
-
- if "exclusiveMaximum" is not present, or has boolean value false,
- then the instance is valid if and only if it is lower than, or equal to,
- the value of "maximum";
- if "exclusiveMaximum" is present and has boolean value true, the the
- instance is valid if and only if it is strictly lower than the value of
- "maximum".
-
+
+ if "exclusiveMaximum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is lower than, or equal
+ to, the value of "maximum";
+ if "exclusiveMaximum" is present and has boolean value true, the
+ the instance is valid if and only if it is strictly lower than the
+ value of "maximum".
+
+
@@ -289,16 +311,16 @@
Successful validation depends on the presence and value of
"exclusiveMinimum":
-
-
- if "exclusiveMinimum" is not present, or has boolean value false,
- then the instance is valid if and only if it is greater than, or equal
- to, the value of "minimum";
- if "exclusiveMinimum" is present and has boolean value true, the the
- instance is valid if and only if it is strictly greater than the value
- of "minimum".
-
+
+ if "exclusiveMinimum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is greater than, or
+ equal to, the value of "minimum";
+ if "exclusiveMinimum" is present and has boolean value true, the
+ the instance is valid if and only if it is strictly greater than the
+ value of "minimum".
+
+
@@ -330,7 +352,7 @@
The length of a string instance is defined as the number of its
- characters as defined by FIXME_LINK.
+ characters as defined by RFC 4627.
@@ -353,7 +375,7 @@
The length of a string instance is defined as the number of its
- characters as defined by FIXME_LINK.
+ characters as defined by RFC 4627.
@@ -370,9 +392,9 @@
- The value for this keyword MUST be a string. This string MUST be a valid
- regular expression, according to the ECMA 262 regular expression
- dialect, as defined by FIXME_LINK.
+ The value for this keyword MUST be a string. This string SHOULD be a
+ valid regular expression, according to the ECMA 262 regular expression
+ dialect.
@@ -410,19 +432,20 @@
Successful validation of an array instance with regards to these two
keywords is determined as follows:
-
-
- if "items" is not present, or its value is an object, validation of
- the instance always succeeds, regardless of the value of
- "additionalItems";
- if the value of "additionalItems" is boolean value true or an object,
- validation of the instance always succeeds;
- if the value of additionalItems is boolean value false and the value
- of items is an array (which is must be at this point), the instance is
- valid if and only if its number of elements is less than, or equal to,
- the number of elements in the array value of items.
-
+
+ if "items" is not present, or its value is an object, validation
+ of the instance always succeeds, regardless of the value of
+ "additionalItems";
+ if the value of "additionalItems" is boolean value true or an
+ object, validation of the instance always succeeds;
+ if the value of additionalItems is boolean value false and the
+ value of items is an array (which is must be at this point), the
+ instance is valid if and only if its number of elements is less
+ than, or equal to, the number of elements in the array value of
+ items.
+
+
@@ -447,22 +470,22 @@
With this schema, the following instances are valid:
-
-
- [] (an empty array),
- [ [ 1, 2, 3, 4 ], [ 5, 6, 7, 8 ] ],
- [ 1, 2, 3 ];
-
+
+ [] (an empty array),
+ [ [ 1, 2, 3, 4 ], [ 5, 6, 7, 8 ] ],
+ [ 1, 2, 3 ];
+
+
the following instances are invalid:
-
-
- [ 1, 2, 3, 4 ],
- [ null, { "a": "b" }, true, 31.000002020013 ]
-
+
+ [ 1, 2, 3, 4 ],
+ [ null, { "a": "b" }, true, 31.000002020013 ]
+
+
@@ -604,8 +627,8 @@
- An object instance is valid against this keyword if and only if the set
- of its member names contains all elements in this keyword's array.
+ An object instance is valid against this keyword if and only if its
+ member set contains all elements in this keyword's array.
@@ -626,10 +649,9 @@
The value of "patternProperties" MUST be an object. Each member name of
- this object MUST be a valid regular expression, according to the ECMA
- 262 regular expression dialect, as defined by FIXME_LINK. Each value of
- this object MUST be an object, and each object MUST be a valid JSON
- Schema.
+ this object SHOULD be a valid regular expression, according to the ECMA
+ 262 regular expression dialect. Each value of this object MUST be an
+ object, and each object MUST be a valid JSON Schema.
@@ -637,13 +659,14 @@
Successful validation of an object instance against these three keywords
depends on the value of "additionalProperties":
-
-
- if its value is boolean true or a schema, validation succeeds;
- if its value is boolean false, the algorithm to determine validation
- success is described below.
-
+
+ if its value is boolean true or a schema, validation
+ succeeds;
+ if its value is boolean false, the algorithm to determine
+ validation success is described below.
+
+
@@ -661,30 +684,30 @@
- In this case, validation of the instance depends on the member names of
- "properties" and "patternProperties". In this section, member names of
- "patternProperties" will be called regexes for convenience.
+ In this case, validation of the instance depends on the member set of
+ "properties" and "patternProperties". In this section, the elements of
+ "patternProperties"' member set will be called regexes for convenience.
The first step is to collect the following sets:
-
-
- The set of member names of the instance to validate.
- The set of member names from "properties".
- The set of regexes from "patternProperties".
-
+
+ The member set of the instance to validate.
+ The member set from "properties".
+ The member set from "patternProperties".
+
+
Having collected these three sets, the process is as follows:
-
-
- remove from "s" all members of "p", if any;
- for each regex in "pp", remove all members of "s" which this regex
- matches.
-
+
+ remove from "s" all elements of "p", if any;
+ for each regex in "pp", remove all elements of "s" which this
+ regex matches.
+
+
Validation of the instance succeeds if and only if, after these two
@@ -707,7 +730,7 @@
},
"patternProperties": {
"p": {},
- "\\d": {}
+ "[0-9]": {}
}
}
]]>
@@ -735,23 +758,25 @@
The three sets are:
-
-
- { "p1", "p2", "a32&o", "", "finance", "apple" }
- { "p1" }
- { "p", "\\d" }
-
+
+ { "p1", "p2", "a32&o", "", "finance", "apple"
+ }
+ { "p1" }
+ { "p", "[0-9]" }
+
+
Applying the two steps of the algorithm:
-
-
- after the first step, "p1" is removed from "s";
- after the second step, "p2", "a32&o" and "apple" are removed from
- "s".
-
+
+ after the first step, "p1" is removed from "s";
+ after the second step, "p2" (matched by "p"), "a32&o"
+ (matched by "[0-9]) and "apple" (matched by "p") are removed from
+ "s".
+
+
The set still contains two elements, "" and "finance". Validation
@@ -765,38 +790,22 @@
- This keyword's value MUST be an object. Values for this object MUST be
- either of a string, an array or an object. If the value is an object,
- it MUST be a valid JSON Schema.
-
-
-
- If the value is an array:
+ This keyword's value MUST be an object. This object MUST be a valid JSON
+ Schema.
-
-
- this array MUST have at least one element;
- elements of this array MUST be strings;
- elements of this array MUST be unique.
-
- For each member name in the object instance with an equivalent member
- name in "dependencies":
+ For each element in the object instance's member set, if "dependencies"
+ contains a member by the same name, the object instance must validate
+ successfully against the matching schema in "dependencies".
-
- if the value in "dependencies" is an object, therefore a schema, then
- the object instance is considered valid if and only if it also validates
- successfully against this schema (note: the object instance itself, not
- the value of that particular member);
- if the value in "dependencies" is a string or an array of strings,
- this (these) strings should be considered as member name(s), and the
- object instance is required to have members by the same name(s) in order
- to validate successfully.
-
+
+ Note that this is the object instance itself which must validate
+ successfully, not the value associated with that member.
+
@@ -821,8 +830,7 @@
An instance validates successfully against this keyword if and only if
- its value is exactly equal to one of the elements in this keyword's
- array value, according to the definition in FIXME_LINK.
+ its value is equal to one of the elements in this keyword's array value.
@@ -832,22 +840,16 @@
- The value of this keyword MUST be a string or an array. If the value is
- an array, elements of this array MUST be unique. This keyword's string
- value, or array element values, MUST be either of:
+ The value of this keyword MUST be a string. The value of this string
+ MUST be one of the seven primitive types defined by FIXME_LINK.
-
-
- one of the seven primitive types defined by FIXME_LINK; or
- "any", which is equivalent to all seven primitive types.
-
- An instance matches successfully if and only if its primitive type, as
- defined in FIXME_LINK, is one of the primitive types allowed by this
- keyword's value. Recall: "number" includes "integer".
+ An instance matches successfully if and only if its primitive type is
+ the one defined by the value of this keyword. Recall: "number" includes
+ "integer".
@@ -945,20 +947,21 @@
-
+
Calculating the schema, or schemas, a child instance must validate against is
- influenced by the following, in addition to the container instance type:
+ influenced by the following:
+
+
+ the container instance type;
+ the child instance's defining characteristic in the container
+ instance;
+ the value of keywords implied in the calculation.
+
-
- the container instance type;
- the child instance's defining characteristic in the container instance;
- the value of keywords implied in the calculation.
-
-
In addition, it is important that if one or more keyword(s) implied in the
calculation are not defined, it be considered present with its default value,
@@ -1001,15 +1004,15 @@
In this situation, the schema depends on the index of the child
instance:
-
-
- if the index is less than, or equal to, the maximum index in the
- "items" array, then the child instance must be valid against the
- corresponding schema in the "items" array;
- otherwise, it must be valid against the schema defined by
- "additionalItems".
-
+
+ if the index is less than, or equal to, the maximum index in the
+ "items" array, then the child instance must be valid against the
+ corresponding schema in the "items" array;
+ otherwise, it must be valid against the schema defined by
+ "additionalItems".
+
+
@@ -1048,16 +1051,16 @@
The calculation below uses the following names:
-
-
- The member name the child instance is associated to.
- The set of member names from "properties", if any.
- The set of member names from "patternProperties", if
- any. Member names from this set will be called regexes for convenience.
- The set of schemas the child instance must validate
- against.
-
+
+ The member name the child instance is associated
+ to.
+ The member set from "properties".
+ The member set from "patternProperties". Elements
+ of this set will be called regexes for convenience.
+ The set of schemas for the child instance.
+
+
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 53b58d97..d50dc9b6 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -3,9 +3,6 @@
"$schema": "http://json-schema.org/current/schema-core.json#",
"description": "Core schema meta-schema",
"common": {
- "primitiveTypes": {
- "enum": [ "array", "boolean", "integer", "null", "number", "object", "string", "any" ]
- },
"schemaArray": {
"type": "array",
"minItems": 1,
@@ -17,12 +14,6 @@
},
"positiveIntegerDefault0": {
"allOf": [ { "$ref": "#/common/positiveInteger" }, { "default": 0 } ]
- },
- "stringArray": {
- "type": "array",
- "minItems": 1,
- "items": { "type": "string" },
- "uniqueItems": true
}
},
"type": "object",
@@ -42,7 +33,7 @@
"type": "string"
},
"default": {},
- "divisibleBy": {
+ "multipleOf": {
"type": "number",
"minimum": 0,
"exclusiveMinimum": true
@@ -89,7 +80,12 @@
},
"maxProperties": { "$ref": "#/common/positiveInteger" },
"minProperties": { "$ref": "#/common/positiveIntegerDefault0" },
- "required": { "$ref": "#/common/stringArray" },
+ "required": {
+ "type": "array",
+ "minItems": 1,
+ "items": { "type": "string" },
+ "uniqueItems": true
+ }
"additionalProperties": {
"anyOf": [
{ "type": "boolean" },
@@ -109,13 +105,7 @@
},
"dependencies": {
"type": "object",
- "additionalProperties": {
- "anyOf": [
- { "type": "string" },
- { "$ref": "#/common/stringArray" },
- { "$ref": "#" }
- ]
- }
+ "additionalProperties": { "$ref": "#" }
},
"enum": {
"type": "array",
@@ -123,15 +113,7 @@
"uniqueItems": true
},
"type": {
- "anyOf": [
- { "$ref": "#/common/primitiveTypes" },
- {
- "type": "array",
- "minItems": 1,
- "items": { "$ref": "#/common/primitiveTypes" }
- }
- ],
- "default": "any"
+ "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ]
},
"allOf": { "$ref": "#/common/schemaArray" },
"anyOf": { "$ref": "#/common/schemaArray" },
@@ -144,4 +126,3 @@
},
"default": {}
}
-
From fbfe43bb567ecaa3b33d551ce7a9c076cb6772dd Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 22 Sep 2012 19:55:25 +0200
Subject: [PATCH 0108/1659] Validation spec: add link to ECMA 262 spec (PDF)
---
proposals/json-schema-validation.txt | 12 ++++++------
proposals/json-schema-validation.xml | 10 +++++++++-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 790c9061..b953aeee 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -232,8 +232,8 @@ Internet-Draft JSON Schema September 2012
Two validation keywords, "pattern" and "patternProperties", use
regular expressions as a part of validation mechanics. These regular
- expressions SHOULD be valid according to the ECMA 262 regular
- expression dialect.
+ expressions SHOULD be valid according to the ECMA 262 [ecma262]
+ regular expression dialect.
Implementations MUST NOT consider that regular expressions are
anchored, neither at the beginning nor at the end. This means, for
@@ -1070,6 +1070,10 @@ Internet-Draft JSON Schema September 2012
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+ [ecma262] "ECMA 262 specification", .
+
Appendix A. ChangeLog
TODO
@@ -1110,10 +1114,6 @@ Authors' Addresses
-
-
-
-
Galiegue, et al. Expires March 26, 2013 [Page 20]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index a506c0a3..e40a1fac 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -134,7 +134,7 @@
Two validation keywords, "pattern" and "patternProperties", use regular
expressions as a part of validation mechanics. These regular expressions SHOULD
- be valid according to the ECMA 262 regular expression dialect.
+ be valid according to the ECMA 262 regular expression dialect.
@@ -1103,6 +1103,14 @@
&RFC4627;
+
+
+ ECMA 262 specification
+
+
+
+
From f10469902a296192de0944c7d70c8a3714969dfa Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 22 Sep 2012 21:31:45 +0200
Subject: [PATCH 0109/1659] Validation spec: define "format", meta information
keywords
---
proposals/json-schema-validation.txt | 326 ++++++++++++++++++++-------
proposals/json-schema-validation.xml | 199 +++++++++++++++-
2 files changed, 444 insertions(+), 81 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index b953aeee..51ced03f 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -104,7 +104,7 @@ Table of Contents
5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6. Calculatin child instances' schema(s) . . . . . . . . . . . . 17
+ 6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 17
@@ -113,37 +113,37 @@ Galiegue, et al. Expires March 26, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
- 6.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 18
- 6.2.1. Defining characteristic . . . . . . . . . . . . . . . 18
- 6.2.2. Implied keywords and default values. . . . . . . . . . 18
- 6.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 18
- 6.3. Object values . . . . . . . . . . . . . . . . . . . . . . 18
- 6.3.1. Defining characteristic . . . . . . . . . . . . . . . 18
- 6.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 18
- 6.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 19
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ 6.1. "title" and "description" . . . . . . . . . . . . . . . . 17
+ 6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.1. Valid values . . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Semantic validation with "format" . . . . . . . . . . . . . . 18
+ 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.2. Implementation requirements . . . . . . . . . . . . . . . 18
+ 7.3. Defined attributes . . . . . . . . . . . . . . . . . . . . 18
+ 7.3.1. date-time . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.2. email . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.5. ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8. Calculating child instances' schema(s) . . . . . . . . . . . . 20
+ 8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 20
+ 8.2.1. Defining characteristic . . . . . . . . . . . . . . . 20
+ 8.2.2. Implied keywords and default values. . . . . . . . . . 21
+ 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 21
+ 8.3. Object values . . . . . . . . . . . . . . . . . . . . . . 21
+ 8.3.1. Defining characteristic . . . . . . . . . . . . . . . 21
+ 8.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 21
+ 8.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 22
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 23
@@ -925,9 +925,172 @@ Internet-Draft JSON Schema September 2012
An instance is valid against this keyword if and only if it fails to
validate successfully against the schema defined by this keyword.
-6. Calculatin child instances' schema(s)
+6. Metadata keywords
+
+6.1. "title" and "description"
+
+6.1.1. Valid values
+
+ The value for both of these keywords MUST be a string.
+
+6.1.2. Purpose
+
+ 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 produced value associated with
+ this schema.
+
+ Both of these keywords MAY be used in root schemas, and in any
+ subschemas.
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 17]
+
+Internet-Draft JSON Schema September 2012
+
+
+6.2. "default"
+
+6.2.1. Valid values
+
+ There are no restrictions placed on the value of this keyword.
+
+6.2.2. Purpose
+
+ This keyword can be used to substitute a default value for the
+ production of a user interface. 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.
+
+7. Semantic validation with "format"
+
+7.1. Foreword
+
+ 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 MUST be a string. This value is called a
+ format attribute. 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.
+
+7.2. Implementation requirements
+
+ Implementations MAY support the "format" keyword. They MAY implement
+ part of, or all, of the format attributes defined below. They MUST
+ implement validation for defined attributes according to their
+ definitions.
+
+ Implementations MAY add custom format attributes. Format attributes
+ SHOULD NOT be defined to validate container instances. Save for
+ agreement between parties, schema authors SHALL NOT expect that a
+ peer implementation has support for a given attribute, or even for
+ the "format" keyword altogether.
+
+7.3. Defined attributes
+
+
+
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 18]
+
+Internet-Draft JSON Schema September 2012
+
+
+7.3.1. date-time
+
+7.3.1.1. Applicability
+
+ This attribute applies to string instances.
+
+7.3.1.2. Validation
+
+ A string instance is valid against this attribute if and only if it
+ is a valid date representation as defined by RFC 3339, section 5.6
+ [RFC3339].
+
+7.3.2. email
+
+7.3.2.1. Applicability
+
+ This attribute applies to string instances.
+
+7.3.2.2. Validation
+
+ A string instance is valid against this attribute if and only if it
+ is a valid Internet email address as defined by RFC 5322, section
+ 3.4.1 [RFC5322].
+
+7.3.3. hostname
+
+7.3.3.1. Applicability
+
+ This attribute applies to string instances.
-6.1. Foreword
+7.3.3.2. Validation
+
+ A string instance is valid against this attribute if and only if it
+ is a valid representation for an Internet host name, as defined by
+ RFC 1034, section 3.1 [RFC1034].
+
+7.3.4. ipv4
+
+7.3.4.1. Applicability
+
+ This attribute applies to string instances.
+
+7.3.4.2. Validation
+
+ A string instance is valid against this attribute if and only 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].
+
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 19]
+
+Internet-Draft JSON Schema September 2012
+
+
+7.3.5. ipv6
+
+7.3.5.1. Applicability
+
+ This attribute applies to string instances.
+
+7.3.5.2. Validation
+
+ A string instance is valid against this attribute if and only if it
+ is a valid representation of an IPv6 address as defined in RFC 2373,
+ section 2.2 [RFC2373].
+
+7.3.6. uri
+
+7.3.6.1. Applicability
+
+ This attribute applies to string instances.
+
+7.3.6.2. Validation
+
+ A string instance is valid against this attribute if and only if it
+ is a valid URI, according to [RFC3986].
+
+8. Calculating child instances' schema(s)
+
+8.1. Foreword
Calculating the schema, or schemas, a child instance must validate
against is influenced by the following:
@@ -943,24 +1106,22 @@ Internet-Draft JSON Schema September 2012
in the calculation are not defined, it be considered present with its
default value, which will be recalled in this section.
+8.2. Array elements
+8.2.1. Defining characteristic
+ The defining characteristic of the child instance is this instance's
+ index in the array instance. Recall: array indices start at 0.
-Galiegue, et al. Expires March 26, 2013 [Page 17]
+
+Galiegue, et al. Expires March 26, 2013 [Page 20]
Internet-Draft JSON Schema September 2012
-6.2. Array elements
-
-6.2.1. Defining characteristic
-
- The defining characteristic of the child instance is this instance's
- index in the array instance. Recall: array indices start at 0.
-
-6.2.2. Implied keywords and default values.
+8.2.2. Implied keywords and default values.
The two implied keywords in this calculation are "items" and
"additionalItems".
@@ -968,15 +1129,15 @@ Internet-Draft JSON Schema September 2012
If either keyword is absent, it is considered present with an empty
schema as a value.
-6.2.3. Calculation
+8.2.3. Calculation
-6.2.3.1. If "items" is a schema
+8.2.3.1. If "items" is a 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".
-6.2.3.2. If "items" is an array
+8.2.3.2. If "items" is an array
In this situation, the schema depends on the index of the child
instance:
@@ -988,27 +1149,19 @@ Internet-Draft JSON Schema September 2012
otherwise, it must be valid against the schema defined by
"additionalItems".
-6.3. Object values
+8.3. Object values
-6.3.1. Defining characteristic
+8.3.1. Defining characteristic
The defining characteristic of the child instance of an object is the
member name this child is associated to.
-6.3.2. Implied keywords
+8.3.2. Implied keywords
The three keywords implied in this calculation are "properties",
"patternProperties" and "additionalProperties".
If "properties" of "patternProperties" are absent, they are
-
-
-
-Galiegue, et al. Expires March 26, 2013 [Page 18]
-
-Internet-Draft JSON Schema September 2012
-
-
considered present with an empty object as a value (note, an empty
object, NOT an empty schema).
@@ -1016,9 +1169,17 @@ Internet-Draft JSON Schema September 2012
empty schema as a value. In addition, boolean value true is
considered equivalent to an empty schema.
-6.3.3. Calculation
-6.3.3.1. Names used in this calculation
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 21]
+
+Internet-Draft JSON Schema September 2012
+
+
+8.3.3. Calculation
+
+8.3.3.1. Names used in this calculation
The calculation below uses the following names:
@@ -1031,45 +1192,63 @@ Internet-Draft JSON Schema September 2012
s The set of schemas for the child instance.
-6.3.3.2. First step: schemas in "properties"
+8.3.3.2. First step: schemas in "properties"
If set "p" contains value "m", then the corresponding schema in
"properties" is added to "s".
-6.3.3.3. Second step: schemas in "patternProperties"
+8.3.3.3. Second step: schemas in "patternProperties"
For each regex in "pp", if it matches "m" successfully, the
corresponding schema in "patternProperties" is added to "s".
-6.3.3.4. Third step: "additionalProperties"
+8.3.3.4. Third step: "additionalProperties"
The schema defined by "additionalProperties" is added to "s" if and
only if, at this stage, "s" is empty.
-7. IANA Considerations
+9. IANA Considerations
This specification does not have any influence with regards to IANA.
-8. References
+10. References
-8.1. Normative References
+10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+10.2. Informative References
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+ [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
-Galiegue, et al. Expires March 26, 2013 [Page 19]
+
+
+Galiegue, et al. Expires March 26, 2013 [Page 22]
Internet-Draft JSON Schema September 2012
-8.2. Informative References
+ [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
+ RFC 2673, August 1999.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
+ Internet: Timestamps", RFC 3339, July 2002.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
[ecma262] "ECMA 262 specification", .
@@ -1105,16 +1284,5 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 26, 2013 [Page 20]
+Galiegue, et al. Expires March 26, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index e40a1fac..6a1a5e59 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -1,7 +1,13 @@
+
+
+
+
+
+
+
]>
@@ -947,7 +953,190 @@
-
+
+
+
+
+
+
+ The value for 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 produced value associated with 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 substitute a default value for the production of
+ a user interface. 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 MUST be a string. This value is called a format
+ attribute. 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. They MAY implement part of, or
+ all, of the format attributes defined below. They MUST implement validation for
+ defined attributes according to their definitions.
+
+
+
+ Implementations MAY add custom format attributes. Format attributes SHOULD NOT
+ be defined to validate container instances. Save for agreement between parties,
+ schema authors SHALL NOT expect that a peer implementation has support for a
+ given attribute, or even for the "format" keyword altogether.
+
+
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only if it is a
+ valid date representation as defined by RFC
+ 3339, section 5.6.
+
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only if it is a
+ valid Internet email address as defined by RFC
+ 5322, section 3.4.1.
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only if it is a
+ valid representation for an Internet host name, as defined by RFC 1034, section 3.1.
+
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only 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.
+
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only if it is a
+ valid representation of an IPv6 address as defined in RFC 2373, section 2.2.
+
+
+
+
+
+
+
+ This attribute applies to string instances.
+
+
+
+
+
+ A string instance is valid against this attribute if and only if it is a
+ valid URI, according to .
+
+
+
+
+
+
+
+
@@ -1102,7 +1291,13 @@
&RFC2119;
+ &RFC1034;
+ &RFC2373;
+ &RFC2673;
+ &RFC3339;
+ &RFC3986;
&RFC4627;
+ &RFC5322;
From 4e265e235929dc3c7951ebdfc273c21a77dbcf2d Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 09:05:25 +0200
Subject: [PATCH 0110/1659] Miscellaneous updates
* define $schema in core specification
* "additionalItems" being true is equivalent to an empty schema
* bring schema-core.json inline with the validation spec
---
proposals/json-schema-core.txt | 212 +++++++++++++++++----------
proposals/json-schema-core.xml | 79 +++++++++-
proposals/json-schema-validation.txt | 56 +++----
proposals/json-schema-validation.xml | 3 +-
proposals/schema-core.json | 7 +-
5 files changed, 243 insertions(+), 114 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 782e0287..9e55f195 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 26, 2013 SitePen (USA)
+Expires: March 27, 2013 SitePen (USA)
G. Court
- September 22, 2012
+ September 23, 2012
JSON Schema: core definitions and purposes
@@ -36,7 +36,7 @@ Status of This Memo
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 March 26, 2013.
+ This Internet-Draft will expire on March 27, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 26, 2013 [Page 1]
+Galiegue, et al. Expires March 27, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -63,35 +63,41 @@ Internet-Draft JSON Schema September 2012
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
- 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . . 3
- 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . . 3
- 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
- 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . . 4
- 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Instance validation . . . . . . . . . . . . . . . . . . . . 5
- 4.2. Hyperlinking . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.3. Design Considerations . . . . . . . . . . . . . . . . . . . 5
- 5. Schema addressing . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.1. Addressing mechanisms and general considerations . . . . . 6
- 5.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 6
- 5.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 6
- 5.4. Inner schema addressing . . . . . . . . . . . . . . . . . . 6
- 5.5. Security considerations . . . . . . . . . . . . . . . . . . 7
- 6. Schema/Instance Association . . . . . . . . . . . . . . . . . . 8
- 6.1. Purpose of this section . . . . . . . . . . . . . . . . . . 8
- 6.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . . 8
- 6.2.1. Correlation by means of the "Content-Type" header . . . 8
- 6.2.2. Correlation by means of the "Link" header . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 9
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
+ 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
+ 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
+ 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
+ 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
+ 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Hyperlinking . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Design discussion . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Generic considerations . . . . . . . . . . . . . . . . . . 5
+ 5.2. The "$schema" keyword . . . . . . . . . . . . . . . . . . 6
+ 5.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2.2. Valid values . . . . . . . . . . . . . . . . . . . . . 6
+ 5.2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5.3. Extending JSON Schema . . . . . . . . . . . . . . . . . . 6
+ 6. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 7
+ 6.1. Addressing mechanisms and general considerations . . . . . 7
+ 6.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
+ 6.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
+ 6.4. Inner schema addressing . . . . . . . . . . . . . . . . . 7
+ 6.5. Security considerations . . . . . . . . . . . . . . . . . 8
+ 7. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
+ 7.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
+ 7.2. Recommended correlation mechanisms for use with the
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 9
+ 7.2.1. Correlation by means of the "Content-Type" header . . 9
+ 7.2.2. Correlation by means of the "Link" header . . . . . . 9
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
@@ -102,13 +108,7 @@ Table of Contents
-
-
-
-
-
-
-Galiegue, et al. Expires March 26, 2013 [Page 2]
+Galiegue, et al. Expires March 27, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 3]
+Galiegue, et al. Expires March 27, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -220,7 +220,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 4]
+Galiegue, et al. Expires March 27, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -260,7 +260,9 @@ Internet-Draft JSON Schema September 2012
JSON Schema defines a mechanism to build links to a variety of
resources. FIXME: describe it better.
-4.3. Design Considerations
+5. Design discussion
+
+5.1. Generic considerations
It is acknowledged that JSON values can be of any type defined by the
JSON specification. As such, JSON Schema does not mandate that an
@@ -270,20 +272,74 @@ Internet-Draft JSON Schema September 2012
of the JSON instance being processed.
JSON Schema is agnostic with regards to both protocols and
- programming languages. In particular, this means that defining the
- semantics of the client-server interface is dependent on the protocol
- being used.
+ programming languages. In particular, the semantics of the client-
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 5]
+
+Internet-Draft JSON Schema September 2012
+
+
+ server interface is dependent on the protocol being used. This
+ specification nevertheless suggests mechanisms to correlate an
+ instance to a schema over HTTP, which is the dominant protocol used
+ for Internet-enabled interactive applications.
+
+5.2. The "$schema" keyword
+
+5.2.1. Purpose
+
+ The "$schema" keyword plays two roles in JSON Schema:
+
+ it defines the version of the schema which a particular JSON
+ Schema is valid against;
+
+ it is a URI which is a location to a JSON Schema which validates
+ any schema written for this version.
+
+ Any of these schemas also validate themselves successfully.
+
+5.2.2. Valid values
+
+ The value of this keyword MUST be one of the following string values:
+
+ "http://json-schema.org/draft-03/schema#" (core JSON Schema
+ written against JSON Schema, draft v3 [json-schema-03]);
+
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
+ hyperschema written against JSON Schema, draft v3
+ [json-schema-03]);
+
+ "http://json-schema.org/current/schema-core.json#" (schema written
+ against the current version of the specification -- this one).
+
+5.2.3. Usage
+ It is RECOMMENDED that schema authors include this keyword in their
+ schemas. This keyword MUST be located at the root of a schema.
+ It is RECOMMENDED that implementations not supporting a particular
+ schema version fail JSON Schema processing.
-Galiegue, et al. Expires March 26, 2013 [Page 5]
+5.3. Extending JSON Schema
+
+ Implementations MAY choose to define additional keywords to JSON
+ Schema. Save for explicit agreement, schema authors SHALL NOT expect
+ these additional keywords to be supported by peer implementations.
+
+
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
-5. Schema addressing
+6. Schema addressing
-5.1. Addressing mechanisms and general considerations
+6.1. Addressing mechanisms and general considerations
JSON Schema addressing is done using URIs [RFC3986]. Two addressing
mechanisms are defined: canonical addressing and inner schema
@@ -294,7 +350,7 @@ Internet-Draft JSON Schema September 2012
The value of this keyword MUST be a string; this string MUST be a
valid URI, and SHOULD be normalized.
-5.2. URI of a root schema
+6.2. URI of a root schema
When a schema is loaded via a URI, the loading URI SHALL be
considered to be the URI for this schema. If a schema is loaded
@@ -306,13 +362,13 @@ Internet-Draft JSON Schema September 2012
otherwise, it is RECOMMENDED that implementations consider that
the URI of the schema is either the empty URI, or a URN.
-5.3. Canonical addressing
+6.3. Canonical addressing
Canonical addressing in JSON Schema is done using JSON Reference
[json-reference]. JSON References, when encountered, MUST be
resolved against the root schema URI before being processed.
-5.4. Inner schema addressing
+6.4. Inner schema addressing
When "id" is encountered in a subschema, implementations MAY resolve
this URI against the root schema's URI, and consider that the
@@ -332,7 +388,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 6]
+Galiegue, et al. Expires March 27, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
@@ -372,7 +428,7 @@ Internet-Draft JSON Schema September 2012
#/schema3 some://where.else/completely#
-5.5. Security considerations
+6.5. Security considerations
Inner schema addressing can produce canonical URIs which differ from
the canonical URI of the root schema. Implementations MAY choose,
@@ -388,14 +444,14 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 7]
+Galiegue, et al. Expires March 27, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
-6. Schema/Instance Association
+7. Schema/Instance Association
-6.1. Purpose of this section
+7.1. Purpose of this section
A JSON instance MAY be correlated to one, or even several, JSON
Schemas. This correlation MAY be embodied within existing protocol
@@ -409,14 +465,14 @@ Internet-Draft JSON Schema September 2012
of, or restrictions on, protocol headers, such a correlation is out
of the normative scope of this specification.
-6.2. Recommended correlation mechanisms for use with the HTTP protocol
+7.2. Recommended correlation mechanisms for use with the HTTP protocol
It is acknowledged by this specification that the majority of
interactive JSON Schema processing will be over HTTP. This section
therefore gives recommendations for materializing an instance/schema
correlation using mechanisms currently available for this protocol.
-6.2.1. Correlation by means of the "Content-Type" header
+7.2.1. Correlation by means of the "Content-Type" header
It is RECOMMENDED that a MIME type parameter by the name of "profile"
be appended to the "Content-Type" header of the instance being
@@ -430,7 +486,7 @@ Internet-Draft JSON Schema September 2012
profile=http://example.com/my-hyper-schema
-6.2.2. Correlation by means of the "Link" header
+7.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
by the name "describedBy" be used, as defined by RFC 2048, section
@@ -444,7 +500,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 8]
+Galiegue, et al. Expires March 27, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
@@ -452,7 +508,7 @@ Internet-Draft JSON Schema September 2012
Link: ; rel="describedBy"
-7. IANA Considerations
+8. IANA Considerations
The proposed MIME media type for JSON Schema is defined as follows:
@@ -460,9 +516,9 @@ Internet-Draft JSON Schema September 2012
subtype name: schema+json.
-8. References
+9. References
-8.1. Normative References
+9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
@@ -475,7 +531,11 @@ Internet-Draft JSON Schema September 2012
September 2012, .
-8.2. Informative References
+ [json-schema-03] Court, G. and K. Zyp, "JSON Schema, draft 3",
+ September 2012, .
+
+9.2. Informative References
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
@@ -489,22 +549,25 @@ Appendix A. ChangeLog
TODO
-Authors' Addresses
-
- Francis Galiegue
- EMail: fgaliegue@gmail.com
-Galiegue, et al. Expires March 26, 2013 [Page 9]
+Galiegue, et al. Expires March 27, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
+Authors' Addresses
+
+ Francis Galiegue
+
+ EMail: fgaliegue@gmail.com
+
+
Kris Zyp (editor)
SitePen (USA)
530 Lytton Avenue
@@ -549,12 +612,5 @@ Internet-Draft JSON Schema September 2012
-
-
-
-
-
-
-
-Galiegue, et al. Expires March 26, 2013 [Page 10]
+Galiegue, et al. Expires March 27, 2013 [Page 11]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index b50bce70..5234965c 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -215,8 +215,11 @@
describe it better.
+
+
+
-
+
It is acknowledged that JSON values can be of any type defined by the JSON
specification. As such, JSON Schema does not mandate that an instance be of a
@@ -227,8 +230,65 @@
JSON Schema is agnostic with regards to both protocols and programming
- languages. In particular, this means that defining the semantics of the
- client-server interface is dependent on the protocol being used.
+ languages. In particular, the semantics of the client-server interface is
+ dependent on the protocol being used. This specification nevertheless suggests
+ mechanisms to correlate an instance to a schema over HTTP, which is the dominant
+ protocol used for Internet-enabled interactive applications.
+
+
+
+
+
+
+ The "$schema" keyword plays two roles in JSON Schema:
+
+
+ it defines the version of the schema which a particular JSON Schema
+ is valid against;
+ it is a URI which is a location to a JSON Schema which validates any
+ schema written for this version.
+
+
+
+
+ Any of these schemas also validate themselves successfully.
+
+
+
+
+
+ The value of this keyword MUST be one of the following string values:
+
+
+ "http://json-schema.org/draft-03/schema#" (core JSON Schema written
+ against JSON Schema, draft v3);
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
+ hyperschema written against JSON Schema,
+ draft v3);
+ "http://json-schema.org/current/schema-core.json#" (schema written
+ against the current version of the specification -- this one).
+
+
+
+
+
+
+ It is RECOMMENDED that schema authors include this keyword in their schemas.
+ This keyword MUST be located at the root of a schema.
+
+
+
+ It is RECOMMENDED that implementations not supporting a particular schema
+ version fail JSON Schema processing.
+
+
+
+
+
+
+ Implementations MAY choose to define additional keywords to JSON Schema. Save
+ for explicit agreement, schema authors SHALL NOT expect these additional
+ keywords to be supported by peer implementations.
@@ -476,6 +536,19 @@ Link: ; rel="describedBy"
+
+
+ JSON Schema, draft 3
+
+
+
+
+ SitePen (USA)
+
+
+
+
&RFC4627;
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 51ced03f..c6dbca0b 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 26, 2013 SitePen (USA)
+Expires: March 27, 2013 SitePen (USA)
G. Court
- September 22, 2012
+ September 23, 2012
JSON Schema: interactive and non interactive validation
@@ -37,7 +37,7 @@ Status of This Memo
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 March 26, 2013.
+ This Internet-Draft will expire on March 27, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 26, 2013 [Page 1]
+Galiegue, et al. Expires March 27, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -108,7 +108,7 @@ Table of Contents
-Galiegue, et al. Expires March 26, 2013 [Page 2]
+Galiegue, et al. Expires March 27, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 3]
+Galiegue, et al. Expires March 27, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -220,7 +220,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 4]
+Galiegue, et al. Expires March 27, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -276,7 +276,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 5]
+Galiegue, et al. Expires March 27, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
@@ -332,7 +332,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 6]
+Galiegue, et al. Expires March 27, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
@@ -388,7 +388,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 7]
+Galiegue, et al. Expires March 27, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
@@ -444,7 +444,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 8]
+Galiegue, et al. Expires March 27, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
@@ -500,7 +500,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 9]
+Galiegue, et al. Expires March 27, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
@@ -556,7 +556,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 10]
+Galiegue, et al. Expires March 27, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
@@ -612,7 +612,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 11]
+Galiegue, et al. Expires March 27, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
@@ -668,7 +668,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 12]
+Galiegue, et al. Expires March 27, 2013 [Page 12]
Internet-Draft JSON Schema September 2012
@@ -724,7 +724,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 13]
+Galiegue, et al. Expires March 27, 2013 [Page 13]
Internet-Draft JSON Schema September 2012
@@ -780,7 +780,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 14]
+Galiegue, et al. Expires March 27, 2013 [Page 14]
Internet-Draft JSON Schema September 2012
@@ -836,7 +836,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 15]
+Galiegue, et al. Expires March 27, 2013 [Page 15]
Internet-Draft JSON Schema September 2012
@@ -892,7 +892,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 16]
+Galiegue, et al. Expires March 27, 2013 [Page 16]
Internet-Draft JSON Schema September 2012
@@ -948,7 +948,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 17]
+Galiegue, et al. Expires March 27, 2013 [Page 17]
Internet-Draft JSON Schema September 2012
@@ -1004,7 +1004,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 18]
+Galiegue, et al. Expires March 27, 2013 [Page 18]
Internet-Draft JSON Schema September 2012
@@ -1060,7 +1060,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 19]
+Galiegue, et al. Expires March 27, 2013 [Page 19]
Internet-Draft JSON Schema September 2012
@@ -1116,7 +1116,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 20]
+Galiegue, et al. Expires March 27, 2013 [Page 20]
Internet-Draft JSON Schema September 2012
@@ -1127,7 +1127,8 @@ Internet-Draft JSON Schema September 2012
"additionalItems".
If either keyword is absent, it is considered present with an empty
- schema as a value.
+ schema as a value. In addition, boolean value true for
+ "additionalItems" is considered equivalent to an empty schema.
8.2.3. Calculation
@@ -1171,8 +1172,7 @@ Internet-Draft JSON Schema September 2012
-
-Galiegue, et al. Expires March 26, 2013 [Page 21]
+Galiegue, et al. Expires March 27, 2013 [Page 21]
Internet-Draft JSON Schema September 2012
@@ -1228,7 +1228,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 26, 2013 [Page 22]
+Galiegue, et al. Expires March 27, 2013 [Page 22]
Internet-Draft JSON Schema September 2012
@@ -1284,5 +1284,5 @@ Authors' Addresses
-Galiegue, et al. Expires March 26, 2013 [Page 23]
+Galiegue, et al. Expires March 27, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index 6a1a5e59..ae220eaa 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -1175,7 +1175,8 @@
If either keyword is absent, it is considered present with an empty schema as a
- value.
+ value. In addition, boolean value true for "additionalItems" is considered
+ equivalent to an empty schema.
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index d50dc9b6..8db26487 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -55,8 +55,7 @@
"maxLength": { "$ref": "#/common/positiveInteger" },
"minLength": { "$ref": "#/common/positiveIntegerDefault0" },
"pattern": {
- "type": "string",
- "format": "regex"
+ "type": "string"
},
"additionalItems": {
"anyOf": [
@@ -121,8 +120,8 @@
"not": { "$ref": "#" }
},
"dependencies": {
- "exclusiveMaximum": "maximum",
- "exclusiveMinimum": "minimum"
+ "exclusiveMaximum": { "required": [ "maximum" ] },
+ "exclusiveMinimum": { "required": [ "minimum" ] }
},
"default": {}
}
From 158784642b50dd44fd64761d6dbdce98be53714f Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 12:01:52 +0200
Subject: [PATCH 0111/1659] json-schema-core: cite RFC 4627, section 2.4
1 and 1.0 are not the same!
---
proposals/json-schema-core.txt | 14 +++++++-------
proposals/json-schema-core.xml | 5 +++--
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 9e55f195..8d5a4c88 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -184,7 +184,8 @@ Internet-Draft JSON Schema September 2012
boolean A JSON boolean (true or false).
- integer A JSON number without a decimal part.
+ integer A JSON number without a decimal or exponent part (see RFC
+ 4627, section 2.4 [RFC4627].
number Any JSON number. Number includes integer.
@@ -204,7 +205,7 @@ Internet-Draft JSON Schema September 2012
both are strings, and have the same value; or
- both are numbers, and evaluate to the same numeric value; or
+ both are numbers, and have the same JSON representation; or
both are arrays, and:
@@ -215,7 +216,6 @@ Internet-Draft JSON Schema September 2012
both are objects, and:
- have the same set of members; and
@@ -225,6 +225,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
+ have the same set of members; and
+
values for a same member are equal according to this
definition.
@@ -271,8 +273,6 @@ Internet-Draft JSON Schema September 2012
add useful constraints to the structure and, optionally, semantics,
of the JSON instance being processed.
- JSON Schema is agnostic with regards to both protocols and
- programming languages. In particular, the semantics of the client-
@@ -281,6 +281,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+ JSON Schema is agnostic with regards to both protocols and
+ programming languages. In particular, the semantics of the client-
server interface is dependent on the protocol being used. This
specification nevertheless suggests mechanisms to correlate an
instance to a schema over HTTP, which is the dominant protocol used
@@ -330,8 +332,6 @@ Internet-Draft JSON Schema September 2012
-
-
Galiegue, et al. Expires March 27, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 5234965c..c2f4b91d 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -140,7 +140,8 @@
A JSON array.A JSON boolean (true or false).
- A JSON number without a decimal part.
+ A JSON number without a decimal or exponent part (see
+ RFC 4627, section 2.4.Any JSON number. Number includes integer.The JSON null value.A JSON object.
@@ -157,7 +158,7 @@
both are nulls; orboth are booleans, and have the same value; orboth are strings, and have the same value; or
- both are numbers, and evaluate to the same numeric value; or
+ both are numbers, and have the same JSON representation; orboth are arrays, and:
have the same number of elements; and
From 4e6c18a4f3a682cf7e953189944e11a64778248a Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 12:51:23 +0200
Subject: [PATCH 0112/1659] More changes to core schema
* Add section about security
* Some rewording
* Separate $schema into its own section
---
proposals/json-schema-core.txt | 258 ++++++++++++++++-----------------
proposals/json-schema-core.xml | 171 ++++++++++++----------
2 files changed, 223 insertions(+), 206 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 8d5a4c88..1db1031d 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -74,32 +74,32 @@ Table of Contents
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
4.2. Hyperlinking . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Design discussion . . . . . . . . . . . . . . . . . . . . . . 5
- 5.1. Generic considerations . . . . . . . . . . . . . . . . . . 5
- 5.2. The "$schema" keyword . . . . . . . . . . . . . . . . . . 6
- 5.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 6
- 5.2.2. Valid values . . . . . . . . . . . . . . . . . . . . . 6
- 5.2.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 5. General considerations . . . . . . . . . . . . . . . . . . . . 5
+ 5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 5
+ 5.2. Protocol and programming language independence . . . . . . 6
5.3. Extending JSON Schema . . . . . . . . . . . . . . . . . . 6
- 6. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 7
- 6.1. Addressing mechanisms and general considerations . . . . . 7
- 6.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
- 6.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
- 6.4. Inner schema addressing . . . . . . . . . . . . . . . . . 7
- 6.5. Security considerations . . . . . . . . . . . . . . . . . 8
- 7. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
- 7.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
- 7.2. Recommended correlation mechanisms for use with the
+ 5.4. Security considerations . . . . . . . . . . . . . . . . . 6
+ 6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 6
+ 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6.2. Valid values . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 7
+ 7.1. Addressing mechanisms . . . . . . . . . . . . . . . . . . 7
+ 7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
+ 7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
+ 7.4. Internal addressing . . . . . . . . . . . . . . . . . . . 7
+ 7.5. Security considerations . . . . . . . . . . . . . . . . . 9
+ 8. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
+ 8.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
+ 8.2. Recommended correlation mechanisms for use with the
HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 9
- 7.2.1. Correlation by means of the "Content-Type" header . . 9
- 7.2.2. Correlation by means of the "Link" header . . . . . . 9
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 10
-
-
+ 8.2.1. Correlation by means of the "Content-Type" header . . 9
+ 8.2.2. Correlation by means of the "Link" header . . . . . . 10
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 11
@@ -185,7 +185,7 @@ Internet-Draft JSON Schema September 2012
boolean A JSON boolean (true or false).
integer A JSON number without a decimal or exponent part (see RFC
- 4627, section 2.4 [RFC4627].
+ 4627, section 2.4) [RFC4627].
number Any JSON number. Number includes integer.
@@ -262,13 +262,13 @@ Internet-Draft JSON Schema September 2012
JSON Schema defines a mechanism to build links to a variety of
resources. FIXME: describe it better.
-5. Design discussion
+5. General considerations
-5.1. Generic considerations
+5.1. Valid instances
- It is acknowledged that JSON values can be of any type defined by the
- JSON specification. As such, JSON Schema does not mandate that an
- instance be of a particular type: JSON Schema can process any JSON
+ It is acknowledged that a JSON instance may be any valid JSON value
+ as defined by [RFC4627]. As such, JSON Schema does not mandate that
+ an instance be of a particular type: JSON Schema can process any JSON
value, including null. It is the domain of JSON Schema validation to
add useful constraints to the structure and, optionally, semantics,
of the JSON instance being processed.
@@ -281,6 +281,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+5.2. Protocol and programming language independence
+
JSON Schema is agnostic with regards to both protocols and
programming languages. In particular, the semantics of the client-
server interface is dependent on the protocol being used. This
@@ -288,9 +290,25 @@ Internet-Draft JSON Schema September 2012
instance to a schema over HTTP, which is the dominant protocol used
for Internet-enabled interactive applications.
-5.2. The "$schema" keyword
+5.3. Extending JSON Schema
+
+ Implementations MAY choose to define additional keywords to JSON
+ Schema. Save for explicit agreement, schema authors SHALL NOT expect
+ these additional keywords to be supported by peer implementations.
-5.2.1. Purpose
+5.4. Security considerations
+
+ Both schemas and instances are written in JSON. As such, all
+ security considerations defined in [RFC4627] apply.
+
+ JSON Schema does not define an internal security mechanism. It is up
+ to applications to determine the level of trust placed into JSON data
+ coming from external sources (whether this data be an instance or a
+ schema).
+
+6. The "$schema" keyword
+
+6.1. Purpose
The "$schema" keyword plays two roles in JSON Schema:
@@ -302,7 +320,7 @@ Internet-Draft JSON Schema September 2012
Any of these schemas also validate themselves successfully.
-5.2.2. Valid values
+6.2. Valid values
The value of this keyword MUST be one of the following string values:
@@ -311,12 +329,20 @@ Internet-Draft JSON Schema September 2012
"http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
hyperschema written against JSON Schema, draft v3
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+
+
[json-schema-03]);
"http://json-schema.org/current/schema-core.json#" (schema written
against the current version of the specification -- this one).
-5.2.3. Usage
+6.3. Usage
It is RECOMMENDED that schema authors include this keyword in their
schemas. This keyword MUST be located at the root of a schema.
@@ -324,33 +350,20 @@ Internet-Draft JSON Schema September 2012
It is RECOMMENDED that implementations not supporting a particular
schema version fail JSON Schema processing.
-5.3. Extending JSON Schema
-
- Implementations MAY choose to define additional keywords to JSON
- Schema. Save for explicit agreement, schema authors SHALL NOT expect
- these additional keywords to be supported by peer implementations.
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
-
-
-6. Schema addressing
+7. Schema addressing
-6.1. Addressing mechanisms and general considerations
+7.1. Addressing mechanisms
JSON Schema addressing is done using URIs [RFC3986]. Two addressing
- mechanisms are defined: canonical addressing and inner schema
- addressing. Implementations MUST support canonical addressing, and
- MAY support inner schema addressing.
+ mechanisms are defined: canonical addressing and internal addressing.
+ Implementations MUST support canonical addressing, and MAY support
+ internal addressing.
- Inner schema addressing is done by the means of the "id" keyword.
- The value of this keyword MUST be a string; this string MUST be a
- valid URI, and SHOULD be normalized.
+ Internal addressing is done by the means of the "id" keyword. The
+ value of this keyword MUST be a string; this string MUST be a valid
+ URI, and SHOULD be normalized.
-6.2. URI of a root schema
+7.2. URI of a root schema
When a schema is loaded via a URI, the loading URI SHALL be
considered to be the URI for this schema. If a schema is loaded
@@ -362,35 +375,32 @@ Internet-Draft JSON Schema September 2012
otherwise, it is RECOMMENDED that implementations consider that
the URI of the schema is either the empty URI, or a URN.
-6.3. Canonical addressing
+7.3. Canonical addressing
Canonical addressing in JSON Schema is done using JSON Reference
[json-reference]. JSON References, when encountered, MUST be
resolved against the root schema URI before being processed.
-6.4. Inner schema addressing
+7.4. Internal addressing
When "id" is encountered in a subschema, implementations MAY resolve
this URI against the root schema's URI, and consider that the
- canonical URI of this subschema is the calculated URI. This is
- called inner schema addressing.
-
- There SHOULD NOT be two identical "id" values in the same schema
- which resolve to the same URI. If this is the case, subschema lookup
- using inner schema addressing is undefined.
-
- This schema will be taken as an example:
-
+Galiegue, et al. Expires March 27, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+ canonical URI of this subschema is the calculated URI. This is
+ called internal addressing.
+ There SHOULD NOT be two identical "id" values in the same schema
+ which resolve to the same URI. If this is the case, subschema lookup
+ using internal addressing is undefined.
-Galiegue, et al. Expires March 27, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
+ This schema will be taken as an example:
{
@@ -428,18 +438,8 @@ Internet-Draft JSON Schema September 2012
#/schema3 some://where.else/completely#
-6.5. Security considerations
- Inner schema addressing can produce canonical URIs which differ from
- the canonical URI of the root schema. Implementations MAY choose,
- for security reasons, to ignore inner schema addressing, and always
- dereference canonical URIs. Schema authors SHALL NOT expect that
- inner schema addressing be used by an implementation.
- Dereferencing URIs may fail to complete, or may lead to content which
- is not a JSON Schema (another type of JSON value, or not a JSON
- value). It is RECOMMENDED that JSON Schema processing be stopped in
- such a situation.
@@ -449,9 +449,22 @@ Galiegue, et al. Expires March 27, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
-7. Schema/Instance Association
+7.5. Security considerations
+
+ Internal addressing can produce canonical URIs which differ from the
+ canonical URI of the root schema. Implementations MAY choose, for
+ security reasons, to ignore internal addressing, and always
+ dereference canonical URIs. Schema authors SHALL NOT expect that
+ internal addressing be used by an implementation.
+
+ Dereferencing URIs may fail to complete, or may lead to content which
+ is not a JSON Schema (another type of JSON value, or not a JSON
+ value). It is RECOMMENDED that JSON Schema processing be considered
+ a failure in such a situation.
+
+8. Schema/Instance Association
-7.1. Purpose of this section
+8.1. Purpose of this section
A JSON instance MAY be correlated to one, or even several, JSON
Schemas. This correlation MAY be embodied within existing protocol
@@ -465,14 +478,14 @@ Internet-Draft JSON Schema September 2012
of, or restrictions on, protocol headers, such a correlation is out
of the normative scope of this specification.
-7.2. Recommended correlation mechanisms for use with the HTTP protocol
+8.2. Recommended correlation mechanisms for use with the HTTP protocol
It is acknowledged by this specification that the majority of
interactive JSON Schema processing will be over HTTP. This section
therefore gives recommendations for materializing an instance/schema
correlation using mechanisms currently available for this protocol.
-7.2.1. Correlation by means of the "Content-Type" header
+8.2.1. Correlation by means of the "Content-Type" header
It is RECOMMENDED that a MIME type parameter by the name of "profile"
be appended to the "Content-Type" header of the instance being
@@ -486,29 +499,29 @@ Internet-Draft JSON Schema September 2012
profile=http://example.com/my-hyper-schema
-7.2.2. Correlation by means of the "Link" header
+
+Galiegue, et al. Expires March 27, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
+8.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
by the name "describedBy" be used, as defined by RFC 2048, section
- 19.6.2.4 (FIXME: make real link). Note: it should be remembered that
- relationship values are case insensitive, so "describedBy" is just as
- valid a relationship as "DESCRIBEDBY".
+ 19.6.2.4 [RFC2048]. Note: it should be remembered that relationship
+ values are case insensitive, so "describedBy" is just as valid a
+ relationship as "DESCRIBEDBY".
The target URI of the "Link" header SHOULD be a valid JSON Schema.
An example of such a header would be:
-
-Galiegue, et al. Expires March 27, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
Link: ; rel="describedBy"
-8. IANA Considerations
+9. IANA Considerations
The proposed MIME media type for JSON Schema is defined as follows:
@@ -516,26 +529,19 @@ Internet-Draft JSON Schema September 2012
subtype name: schema+json.
-9. References
+10. References
-9.1. Normative References
+10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
- [json-reference] Bryan, P. and K. Zyp, "JSON Reference",
- September 2012, .
-
- [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer",
- September 2012, .
-
- [json-schema-03] Court, G. and K. Zyp, "JSON Schema, draft 3",
- September 2012, .
+10.2. Informative References
-9.2. Informative References
+ [RFC2048] Freed, N., Klensin, J., and J. Postel,
+ "Multipurpose Internet Mail Extensions (MIME) Part
+ Four: Registration Procedures", BCP 13, RFC 2048,
+ November 1996.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
@@ -545,21 +551,29 @@ Internet-Draft JSON Schema September 2012
"Uniform Resource Identifier (URI): Generic
Syntax", STD 66, RFC 3986, January 2005.
-Appendix A. ChangeLog
-
- TODO
+ [json-reference] Bryan, P. and K. Zyp, "JSON Reference",
+ September 2012, .
+ [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer",
+ September 2012, .
+ [json-schema-03] Court, G. and K. Zyp, "JSON Schema, draft 3",
+ September 2012, .
-Galiegue, et al. Expires March 27, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
+Appendix A. ChangeLog
+ TODO
Authors' Addresses
@@ -591,20 +605,6 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index c2f4b91d..0745a942 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -1,5 +1,6 @@
@@ -141,7 +142,7 @@
A JSON array.A JSON boolean (true or false).A JSON number without a decimal or exponent part (see
- RFC 4627, section 2.4.
+ RFC 4627, section 2.4).Any JSON number. Number includes integer.The JSON null value.A JSON object.
@@ -218,17 +219,20 @@
-
+
-
+
- It is acknowledged that JSON values can be of any type defined by the JSON
- specification. As such, JSON Schema does not mandate that an instance be of a
- particular type: JSON Schema can process any JSON value, including null. It is
- the domain of JSON Schema validation to add useful constraints to the structure
- and, optionally, semantics, of the JSON instance being processed.
+ It is acknowledged that a JSON instance may be any valid JSON value as defined
+ by . As such, JSON Schema does not mandate that an
+ instance be of a particular type: JSON Schema can process any JSON value,
+ including null. It is the domain of JSON Schema validation to add useful
+ constraints to the structure and, optionally, semantics, of the JSON instance
+ being processed.
-
+
+
+
JSON Schema is agnostic with regards to both protocols and programming
languages. In particular, the semantics of the client-server interface is
@@ -238,75 +242,88 @@
-
-
-
- The "$schema" keyword plays two roles in JSON Schema:
+
+
+ Implementations MAY choose to define additional keywords to JSON Schema. Save
+ for explicit agreement, schema authors SHALL NOT expect these additional
+ keywords to be supported by peer implementations.
+
+
-
- it defines the version of the schema which a particular JSON Schema
- is valid against;
- it is a URI which is a location to a JSON Schema which validates any
- schema written for this version.
-
-
+
+
+ Both schemas and instances are written in JSON. As such, all security
+ considerations defined in apply.
+
-
- Any of these schemas also validate themselves successfully.
-
-
+
+ JSON Schema does not define an internal security mechanism. It is up to
+ applications to determine the level of trust placed into JSON data coming from
+ external sources (whether this data be an instance or a schema).
+
+
+
-
-
- The value of this keyword MUST be one of the following string values:
-
-
- "http://json-schema.org/draft-03/schema#" (core JSON Schema written
- against JSON Schema, draft v3);
- "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
- hyperschema written against JSON Schema,
- draft v3);
- "http://json-schema.org/current/schema-core.json#" (schema written
- against the current version of the specification -- this one).
-
-
-
+
+
+
+ The "$schema" keyword plays two roles in JSON Schema:
-
-
- It is RECOMMENDED that schema authors include this keyword in their schemas.
- This keyword MUST be located at the root of a schema.
-
+
+ it defines the version of the schema which a particular JSON Schema is
+ valid against;
+ it is a URI which is a location to a JSON Schema which validates any
+ schema written for this version.
+
+
-
- It is RECOMMENDED that implementations not supporting a particular schema
- version fail JSON Schema processing.
-
-
+
+ Any of these schemas also validate themselves successfully.
+
-
+
- Implementations MAY choose to define additional keywords to JSON Schema. Save
- for explicit agreement, schema authors SHALL NOT expect these additional
- keywords to be supported by peer implementations.
+ The value of this keyword MUST be one of the following string values:
+
+
+ "http://json-schema.org/draft-03/schema#" (core JSON Schema written
+ against JSON Schema, draft v3);
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema hyperschema
+ written against JSON Schema, draft
+ v3);
+ "http://json-schema.org/current/schema-core.json#" (schema written
+ against the current version of the specification -- this one).
+
+
+
+
+
+
+ It is RECOMMENDED that schema authors include this keyword in their schemas.
+ This keyword MUST be located at the root of a schema.
+
+
+
+ It is RECOMMENDED that implementations not supporting a particular schema
+ version fail JSON Schema processing.
-
+
JSON Schema addressing is done using URIs. Two
- addressing mechanisms are defined: canonical addressing and inner schema
- addressing. Implementations MUST support canonical addressing, and MAY support
- inner schema addressing.
+ addressing mechanisms are defined: canonical addressing and internal addressing.
+ Implementations MUST support canonical addressing, and MAY support internal
+ addressing.
- Inner schema addressing is done by the means of the "id" keyword. The value of
- this keyword MUST be a string; this string MUST be a valid URI, and SHOULD be
+ Internal addressing is done by the means of the "id" keyword. The value of this
+ keyword MUST be a string; this string MUST be a valid URI, and SHOULD be
normalized.
@@ -334,17 +351,17 @@
-
+
When "id" is encountered in a subschema, implementations MAY resolve this URI
against the root schema's URI, and consider that the canonical URI of this
- subschema is the calculated URI. This is called inner schema addressing.
+ subschema is the calculated URI. This is called internal addressing.
There SHOULD NOT be two identical "id" values in the same schema which resolve
- to the same URI. If this is the case, subschema lookup using inner schema
- addressing is undefined.
+ to the same URI. If this is the case, subschema lookup using internal addressing
+ is undefined.
@@ -396,17 +413,16 @@
- Inner schema addressing can produce canonical URIs which differ from the
- canonical URI of the root schema. Implementations MAY choose, for security
- reasons, to ignore inner schema addressing, and always dereference canonical
- URIs. Schema authors SHALL NOT expect that inner schema addressing be used by
- an implementation.
+ Internal addressing can produce canonical URIs which differ from the canonical
+ URI of the root schema. Implementations MAY choose, for security reasons, to
+ ignore internal addressing, and always dereference canonical URIs. Schema
+ authors SHALL NOT expect that internal addressing be used by an implementation.
Dereferencing URIs may fail to complete, or may lead to content which is not a
JSON Schema (another type of JSON value, or not a JSON value). It is RECOMMENDED
- that JSON Schema processing be stopped in such a situation.
+ that JSON Schema processing be considered a failure in such a situation.
@@ -467,10 +483,10 @@ Content-Type: application/my-media-type+json;
When using the "Link" header, it is RECOMMENDED that a relationship by the
- name "describedBy" be used, as defined by RFC 2048, section 19.6.2.4 (FIXME:
- make real link). Note: it should be remembered that relationship values are
- case insensitive, so "describedBy" is just as valid a relationship as
- "DESCRIBEDBY".
+ name "describedBy" be used, as defined by RFC 2048,
+ section 19.6.2.4. Note: it should be remembered that relationship
+ values are case insensitive, so "describedBy" is just as valid a
+ relationship as "DESCRIBEDBY".
@@ -511,6 +527,11 @@ Link: ; rel="describedBy"
&RFC2119;
+
+
+ &RFC2048;
+ &RFC4627;
+ &RFC3986;
@@ -551,10 +572,6 @@ Link: ; rel="describedBy"
-
- &RFC4627;
- &RFC3986;
- TODO
From bbc714c60e8c479c55903c17f7ec17dbbfb679e4 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 13:10:20 +0200
Subject: [PATCH 0113/1659] Space cleanup. Some fixes to validation spec
punctuation.
---
proposals/json-schema-core.xml | 8 +-
proposals/json-schema-validation.txt | 402 +++++++++++++--------------
proposals/json-schema-validation.xml | 38 ++-
3 files changed, 222 insertions(+), 226 deletions(-)
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 0745a942..27080a72 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -97,7 +97,7 @@
-
+
A JSON Schema is a JSON document, and that document MUST be an object. Object
@@ -394,11 +394,11 @@
]]>
-
+
Subschemas at the following URI-encoded JSON
Pointers (starting from the root schema) have the following URIs:
-
+
http://x.y.z/rootschema.json#http://x.y.z/rootschema.json#foo
@@ -468,7 +468,7 @@
An example of such a header would be:
-
+
.
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 22]
+
+Internet-Draft JSON Schema September 2012
+
+
Appendix A. ChangeLog
TODO
@@ -1283,6 +1263,26 @@ Authors' Addresses
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Galiegue, et al. Expires March 27, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index ae220eaa..510b57cf 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -104,7 +104,7 @@
This specification uses the term "member set" for an object instance as the set of
its member names; for instance, the member set of object value { "a": 1, "b": 2 } is
- [ "a", "b" ]
+ [ "a", "b" ].
@@ -112,13 +112,12 @@
-
+
- It should be noted that the null character (\x00) is valid in JSON string
- values. JSON Schema does not define any further constraints than RFC 4627 on validated instances, and as such, an
- instance to validate MAY be and/or contain such a string value, regardless of
- the ability of the underlying programming language to deal with such data.
+ It should be noted that the null character (\x00) is a valid character 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.
@@ -215,7 +214,7 @@
Some keywords, if absent, MAY be regarded by implementations as having
a default value. In this case, the default value will be mentioned.
-
+
@@ -224,17 +223,14 @@
Keywords with the possibility to validate container instances only validate this
instance's structure, not this instance's children. Some of these keywords do,
however, contain information which is necessary for calculating which schema(s)
- a child instance must be valid against. 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.
+ a child instance must be valid against. The algorithms to calculate a child
+ instance's relevant schema(s) are explained in a separate section.
- The algorithms to calculate a child instance's relevant schema(s) are explained
- in a separate section. While such calculation may be done in real time for
- applications performing interactive validation, it is RECOMMENDED that
- applications performing non interactive validation do not attempt to validate
- children until the container instance itself has been validated succesfully.
+ 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.
@@ -779,7 +775,7 @@
after the first step, "p1" is removed from "s";after the second step, "p2" (matched by "p"), "a32&o"
- (matched by "[0-9]) and "apple" (matched by "p") are removed from
+ (matched by "[0-9]") and "apple" (matched by "p") are removed from
"s".
@@ -956,7 +952,7 @@
-
+
The value for both of these keywords MUST be a string.
@@ -979,7 +975,7 @@
-
+
There are no restrictions placed on the value of this keyword.
@@ -1002,7 +998,7 @@
-
+
Structural validation alone may be insufficient to validate that an instance
@@ -1027,7 +1023,7 @@
all, of the format attributes defined below. They MUST implement validation for
defined attributes according to their definitions.
-
+
Implementations MAY add custom format attributes. Format attributes SHOULD NOT
be defined to validate container instances. Save for agreement between parties,
From 4927d8f2117ded01f471bb0043ad5cf24348647d Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 17:29:55 +0200
Subject: [PATCH 0114/1659] More changes to the core specification
* Clarify JSON equality (number vs integer).
* Rename "internal" schema addressing to "inline" schema addressing.
---
proposals/json-schema-core.txt | 74 +++++++++++++++++-----------------
proposals/json-schema-core.xml | 24 ++++++-----
2 files changed, 50 insertions(+), 48 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 1db1031d..05a57ba7 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -87,7 +87,7 @@ Table of Contents
7.1. Addressing mechanisms . . . . . . . . . . . . . . . . . . 7
7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
- 7.4. Internal addressing . . . . . . . . . . . . . . . . . . . 7
+ 7.4. Inline addressing . . . . . . . . . . . . . . . . . . . . 8
7.5. Security considerations . . . . . . . . . . . . . . . . . 9
8. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
8.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
@@ -205,7 +205,10 @@ Internet-Draft JSON Schema September 2012
both are strings, and have the same value; or
- both are numbers, and have the same JSON representation; or
+ both are integers, and have the same value; or
+
+ both are numbers, and have the same integer and decimal/exponent
+ part; or
both are arrays, and:
@@ -214,9 +217,6 @@ Internet-Draft JSON Schema September 2012
elements at the same index are equal according to this
definition; or
- both are objects, and:
-
-
@@ -225,6 +225,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
+ both are objects, and:
+
have the same set of members; and
values for a same member are equal according to this
@@ -271,8 +273,6 @@ Internet-Draft JSON Schema September 2012
an instance be of a particular type: JSON Schema can process any JSON
value, including null. It is the domain of JSON Schema validation to
add useful constraints to the structure and, optionally, semantics,
- of the JSON instance being processed.
-
@@ -281,6 +281,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+ of the JSON instance being processed.
+
5.2. Protocol and programming language independence
JSON Schema is agnostic with regards to both protocols and
@@ -327,8 +329,6 @@ Internet-Draft JSON Schema September 2012
"http://json-schema.org/draft-03/schema#" (core JSON Schema
written against JSON Schema, draft v3 [json-schema-03]);
- "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
- hyperschema written against JSON Schema, draft v3
@@ -337,6 +337,8 @@ Galiegue, et al. Expires March 27, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
+ hyperschema written against JSON Schema, draft v3
[json-schema-03]);
"http://json-schema.org/current/schema-core.json#" (schema written
@@ -355,11 +357,11 @@ Internet-Draft JSON Schema September 2012
7.1. Addressing mechanisms
JSON Schema addressing is done using URIs [RFC3986]. Two addressing
- mechanisms are defined: canonical addressing and internal addressing.
+ mechanisms are defined: canonical addressing and inline addressing.
Implementations MUST support canonical addressing, and MAY support
- internal addressing.
+ inline addressing.
- Internal addressing is done by the means of the "id" keyword. The
+ Inline addressing is done by the means of the "id" keyword. The
value of this keyword MUST be a string; this string MUST be a valid
URI, and SHOULD be normalized.
@@ -381,10 +383,8 @@ Internet-Draft JSON Schema September 2012
[json-reference]. JSON References, when encountered, MUST be
resolved against the root schema URI before being processed.
-7.4. Internal addressing
- When "id" is encountered in a subschema, implementations MAY resolve
- this URI against the root schema's URI, and consider that the
+
@@ -393,12 +393,16 @@ Galiegue, et al. Expires March 27, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+7.4. Inline addressing
+
+ When "id" is encountered in a subschema, implementations MAY resolve
+ this URI against the root schema's URI, and consider that the
canonical URI of this subschema is the calculated URI. This is
- called internal addressing.
+ called inline addressing.
There SHOULD NOT be two identical "id" values in the same schema
which resolve to the same URI. If this is the case, subschema lookup
- using internal addressing is undefined.
+ using inline addressing is undefined.
This schema will be taken as an example:
@@ -434,10 +438,6 @@ Internet-Draft JSON Schema September 2012
#/schema2/nested http://x.y.z/rootschema.json#bar
- #/schema2/alsonested http://x.y.z/t/inner.json#a
-
- #/schema3 some://where.else/completely#
-
@@ -449,13 +449,17 @@ Galiegue, et al. Expires March 27, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
+ #/schema2/alsonested http://x.y.z/t/inner.json#a
+
+ #/schema3 some://where.else/completely#
+
7.5. Security considerations
- Internal addressing can produce canonical URIs which differ from the
+ Inline addressing can produce canonical URIs which differ from the
canonical URI of the root schema. Implementations MAY choose, for
- security reasons, to ignore internal addressing, and always
- dereference canonical URIs. Schema authors SHALL NOT expect that
- internal addressing be used by an implementation.
+ security reasons, to ignore inline addressing, and always dereference
+ canonical URIs. Schema authors SHALL NOT expect that inline
+ addressing be used by an implementation.
Dereferencing URIs may fail to complete, or may lead to content which
is not a JSON Schema (another type of JSON value, or not a JSON
@@ -495,16 +499,16 @@ Internet-Draft JSON Schema September 2012
An example of such a header would be:
- Content-Type: application/my-media-type+json;
- profile=http://example.com/my-hyper-schema
-
-
Galiegue, et al. Expires March 27, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
+ Content-Type: application/my-media-type+json;
+ profile=http://example.com/my-hyper-schema
+
+
8.2.2. Correlation by means of the "Link" header
When using the "Link" header, it is RECOMMENDED that a relationship
@@ -549,10 +553,6 @@ Internet-Draft JSON Schema September 2012
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
- Syntax", STD 66, RFC 3986, January 2005.
-
- [json-reference] Bryan, P. and K. Zyp, "JSON Reference",
- September 2012, .
[json-pointer] Bryan, P. and K. Zyp, "JSON Pointer",
@@ -608,9 +612,5 @@ Authors' Addresses
-
-
-
-
Galiegue, et al. Expires March 27, 2013 [Page 11]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 27080a72..4d1410c1 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -159,7 +159,9 @@
both are nulls; orboth are booleans, and have the same value; orboth are strings, and have the same value; or
- both are numbers, and have the same JSON representation; or
+ both are integers, and have the same value; or
+ both are numbers, and have the same integer and decimal/exponent part;
+ orboth are arrays, and:
have the same number of elements; and
@@ -316,13 +318,13 @@
JSON Schema addressing is done using URIs. Two
- addressing mechanisms are defined: canonical addressing and internal addressing.
- Implementations MUST support canonical addressing, and MAY support internal
+ addressing mechanisms are defined: canonical addressing and inline addressing.
+ Implementations MUST support canonical addressing, and MAY support inline
addressing.
- Internal addressing is done by the means of the "id" keyword. The value of this
+ Inline addressing is done by the means of the "id" keyword. The value of this
keyword MUST be a string; this string MUST be a valid URI, and SHOULD be
normalized.
@@ -351,16 +353,16 @@
-
+
When "id" is encountered in a subschema, implementations MAY resolve this URI
against the root schema's URI, and consider that the canonical URI of this
- subschema is the calculated URI. This is called internal addressing.
+ subschema is the calculated URI. This is called inline addressing.
There SHOULD NOT be two identical "id" values in the same schema which resolve
- to the same URI. If this is the case, subschema lookup using internal addressing
+ to the same URI. If this is the case, subschema lookup using inline addressing
is undefined.
@@ -413,10 +415,10 @@
- Internal addressing can produce canonical URIs which differ from the canonical
- URI of the root schema. Implementations MAY choose, for security reasons, to
- ignore internal addressing, and always dereference canonical URIs. Schema
- authors SHALL NOT expect that internal addressing be used by an implementation.
+ Inline addressing can produce canonical URIs which differ from the canonical URI
+ of the root schema. Implementations MAY choose, for security reasons, to ignore
+ inline addressing, and always dereference canonical URIs. Schema authors SHALL
+ NOT expect that inline addressing be used by an implementation.
From 6c6f64aa23675da633ab1abd83f2b3ed9b15ec40 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sun, 23 Sep 2012 19:39:03 +0200
Subject: [PATCH 0115/1659] Both drafts: replace "equality" of JSON values with
"lexical equivalence"
Numeric instances are quite a bitch in this regard since most people regard 1.0
as equal to 1. This is true mathematically speaking, not lexically speaking.
---
proposals/json-schema-core.txt | 26 +--
proposals/json-schema-core.xml | 23 +-
proposals/json-schema-validation.txt | 330 +++++++++++++--------------
proposals/json-schema-validation.xml | 11 +-
4 files changed, 197 insertions(+), 193 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 05a57ba7..43bc1754 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -69,7 +69,7 @@ Table of Contents
3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
+ 3.4. JSON value lexical equivalence . . . . . . . . . . . . . . 4
3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
@@ -184,7 +184,7 @@ Internet-Draft JSON Schema September 2012
boolean A JSON boolean (true or false).
- integer A JSON number without a decimal or exponent part (see RFC
+ integer A JSON number without a fraction or exponent part (see RFC
4627, section 2.4) [RFC4627].
number Any JSON number. Number includes integer.
@@ -195,28 +195,28 @@ Internet-Draft JSON Schema September 2012
string A JSON string.
-3.4. JSON value equality
+3.4. JSON value lexical equivalence
- Two JSON values are said to be equal if and only if:
+ Two JSON values are said to be lexically equivalent if and only if:
both are nulls; or
both are booleans, and have the same value; or
- both are strings, and have the same value; or
+ both are strings, and have the same lexical representation (see
+ RFC 4627, section 2.5 [RFC4627]; or
- both are integers, and have the same value; or
+ both are integers, and have the same lexical representation; or
- both are numbers, and have the same integer and decimal/exponent
- part; or
+ both are numbers, and have the same lexical representation (see
+ RFC 4627, section 2.4) [RFC4627]; or
both are arrays, and:
have the same number of elements; and
- elements at the same index are equal according to this
- definition; or
-
+ elements at the same index are lexically equivalent according
+ to this definition; or
@@ -229,8 +229,8 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
- values for a same member are equal according to this
- definition.
+ values for a same member are lexically equivalent according to
+ this definition.
3.5. Instance
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 4d1410c1..d8620597 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -141,7 +141,7 @@
A JSON array.A JSON boolean (true or false).
- A JSON number without a decimal or exponent part (see
+ A JSON number without a fraction or exponent part (see
RFC 4627, section 2.4).Any JSON number. Number includes integer.The JSON null value.
@@ -151,29 +151,30 @@
-
+
- Two JSON values are said to be equal if and only if:
+ Two JSON values are said to be lexically equivalent if and only if:
both are nulls; orboth are booleans, and have the same value; or
- both are strings, and have the same value; or
- both are integers, and have the same value; or
- both are numbers, and have the same integer and decimal/exponent part;
- or
+ both are strings, and have the same lexical representation (see RFC 4627, section 2.5; or
+ both are integers, and have the same lexical representation; or
+ both are numbers, and have the same lexical representation (see RFC 4627, section 2.4); orboth are arrays, and:
have the same number of elements; and
- elements at the same index are equal according to this
- definition; or
+ elements at the same index are lexically equivalent according to
+ this definition; orboth are objects, and:
have the same set of members; and
- values for a same member are equal according to this
- definition.
+ values for a same member are lexically equivalent according to
+ this definition.
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 13a5079f..3f139962 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -70,8 +70,8 @@ Table of Contents
3.1. Validation of string instances . . . . . . . . . . . . . . 4
3.2. Validation of numeric instances . . . . . . . . . . . . . 4
3.3. Regular expressions . . . . . . . . . . . . . . . . . . . 5
- 4. General validation considerations . . . . . . . . . . . . . . 5
- 4.1. Keywords and instance primitive types . . . . . . . . . . 5
+ 4. General validation considerations . . . . . . . . . . . . . . 6
+ 4.1. Keywords and instance primitive types . . . . . . . . . . 6
4.2. Inter-dependent keywords . . . . . . . . . . . . . . . . . 6
4.3. Default values for missing keywords . . . . . . . . . . . 6
4.4. Validation of container instances . . . . . . . . . . . . 6
@@ -84,11 +84,11 @@ Table of Contents
5.2. Validation keywords for strings . . . . . . . . . . . . . 8
5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8
- 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Validation keywords for arrays . . . . . . . . . . . . . . 9
5.3.1. additionalItems and items . . . . . . . . . . . . . . 9
5.3.2. maxItems . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.4. uniqueItems . . . . . . . . . . . . . . . . . . . . . 11
5.4. Validation keywords for objects . . . . . . . . . . . . . 11
5.4.1. maxProperties . . . . . . . . . . . . . . . . . . . . 11
@@ -96,14 +96,14 @@ Table of Contents
5.4.3. required . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. additionalProperties, properties and
patternProperties . . . . . . . . . . . . . . . . . . 12
- 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 14
+ 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 15
5.5. Validation keywords for any instance type . . . . . . . . 15
5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 17
@@ -119,8 +119,8 @@ Internet-Draft JSON Schema September 2012
6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
- 7. Semantic validation with "format" . . . . . . . . . . . . . . 17
- 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7. Semantic validation with "format" . . . . . . . . . . . . . . 18
+ 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Implementation requirements . . . . . . . . . . . . . . . 18
7.3. Defined attributes . . . . . . . . . . . . . . . . . . . . 18
7.3.1. date-time . . . . . . . . . . . . . . . . . . . . . . 18
@@ -128,13 +128,13 @@ Internet-Draft JSON Schema September 2012
7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.5. ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Calculating child instances' schema(s) . . . . . . . . . . . . 20
8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Defining characteristic . . . . . . . . . . . . . . . 20
8.2.2. Implied keywords and default values. . . . . . . . . . 20
- 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 20
+ 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 21
8.3. Object values . . . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Defining characteristic . . . . . . . . . . . . . . . 21
8.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 21
@@ -200,6 +200,9 @@ Internet-Draft JSON Schema September 2012
as the set of its member names; for instance, the member set of
object value { "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 lexically equivalent, as defined in FIXME_LINK.
+
3. Interoperability considerations
3.1. Validation of string instances
@@ -214,9 +217,6 @@ Internet-Draft JSON Schema September 2012
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.
@@ -225,6 +225,10 @@ Galiegue, et al. Expires March 27, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
+ 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.
+
3.3. Regular expressions
Two validation keywords, "pattern" and "patternProperties", use
@@ -266,13 +270,9 @@ Internet-Draft JSON Schema September 2012
regular expression, it is RECOMMENDED that JSON Schema processing be
considered a failure.
-4. General validation considerations
-4.1. Keywords and instance primitive types
- 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
+
@@ -281,6 +281,13 @@ Galiegue, et al. Expires March 27, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+4. General validation considerations
+
+4.1. Keywords and instance primitive types
+
+ 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
@@ -323,13 +330,6 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be a JSON number. This number MUST
be strictly greater than 0.
-5.1.1.2. Conditions for successful validation
-
- A numeric instance is valid against "multipleOf" if and only if the
- result of the division of the instance by this keyword's value is an
- integer.
-
-
Galiegue, et al. Expires March 27, 2013 [Page 6]
@@ -337,6 +337,12 @@ Galiegue, et al. Expires March 27, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+5.1.1.2. Conditions for successful validation
+
+ A numeric instance is valid against "multipleOf" if and only if the
+ result of the division of the instance by this keyword's value is an
+ integer.
+
5.1.2. maximum and exclusiveMaximum
5.1.2.1. Valid values
@@ -378,13 +384,7 @@ Internet-Draft JSON Schema September 2012
Successful validation depends on the presence and value of
"exclusiveMinimum":
- if "exclusiveMinimum" is not present, or has boolean value false,
- then the instance is valid if and only if it is greater than, or
- equal to, the value of "minimum";
- if "exclusiveMinimum" is present and has boolean value true, the
- the instance is valid if and only if it is strictly greater than
- the value of "minimum".
@@ -393,6 +393,14 @@ Galiegue, et al. Expires March 27, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+ if "exclusiveMinimum" is not present, or has boolean value false,
+ then the instance is valid if and only if it is greater than, or
+ equal to, the value of "minimum";
+
+ if "exclusiveMinimum" is present and has boolean value true, the
+ the instance is valid if and only if it is strictly greater than
+ the value of "minimum".
+
5.1.3.3. Default value
"exclusiveMinimum", if absent, may be considered as being present
@@ -430,17 +438,9 @@ Internet-Draft JSON Schema September 2012
The length of a string instance is defined as the number of its
characters as defined by RFC 4627 [RFC4627].
-5.2.2.3. Default value
- "minLength", if absent, may be considered as being present with
- integer value 0.
-5.2.3. pattern
-5.2.3.1. Valid values
-
- The value for this keyword MUST be a string. This string SHOULD be a
- valid regular expression, according to the ECMA 262 regular
@@ -449,6 +449,17 @@ Galiegue, et al. Expires March 27, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
+5.2.2.3. Default value
+
+ "minLength", if absent, may be considered as being present with
+ integer value 0.
+
+5.2.3. pattern
+
+5.2.3.1. Valid values
+
+ The value for this keyword MUST be a string. This string SHOULD be a
+ valid regular expression, according to the ECMA 262 regular
expression dialect.
5.2.3.2. Conditions for successful validation
@@ -486,6 +497,14 @@ Internet-Draft JSON Schema September 2012
value of items is an array (which is must be at this point), the
instance is valid if and only if its number of elements is less
than, or equal to, the number of elements in the array value of
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
items.
5.3.1.3. Example
@@ -495,16 +514,6 @@ Internet-Draft JSON Schema September 2012
only situation under which an instance may fail to validate
successfully.
-
-
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
This is an example schema:
@@ -544,22 +553,22 @@ Internet-Draft JSON Schema September 2012
An array instance is valid against "maxItems" if and only if its
number of elements is less than, or equal to, the value of this
- keyword.
-5.3.3. minItems
-5.3.3.1. Valid values
- The value for this keyword MUST be an integer. This integer MUST be
- greater than, or equal to, 0.
+Galiegue, et al. Expires March 27, 2013 [Page 10]
+
+Internet-Draft JSON Schema September 2012
+ keyword.
+5.3.3. minItems
-Galiegue, et al. Expires March 27, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
+5.3.3.1. Valid values
+ The value for this keyword MUST be an integer. This integer MUST be
+ greater than, or equal to, 0.
5.3.3.2. Conditions for successful validation
@@ -582,9 +591,7 @@ Internet-Draft JSON Schema September 2012
If this keyword has boolean value false, the instance validates
successfully. If it has boolean value true, the instance validates
- successfully if and only if all of its elements are unique. In other
- words, no two elements of the array instance should be equal as per
- the definition in FIXME_LINK.
+ successfully if and only if all of its elements are unique.
5.3.4.3. Default value
@@ -600,13 +607,6 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be an integer. This integer MUST be
greater than, or equal to, 0.
-5.4.1.2. Conditions for successful validation
-
- An object instance is valid against "maxProperties" if and only if
- its number of members is less than, or equal to, the value of this
- keyword.
-
-
@@ -617,6 +617,12 @@ Galiegue, et al. Expires March 27, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
+5.4.1.2. Conditions for successful validation
+
+ An object instance is valid against "maxProperties" if and only if
+ its number of members is less than, or equal to, the value of this
+ keyword.
+
5.4.2. minProperties
5.4.2.1. Valid values
@@ -659,12 +665,6 @@ Internet-Draft JSON Schema September 2012
object MUST be an object, and each object MUST be a valid JSON
Schema.
- The value of "patternProperties" MUST be an object. Each member name
- of this object SHOULD be a valid regular expression, according to the
- ECMA 262 regular expression dialect. Each value of this object MUST
- be an object, and each object MUST be a valid JSON Schema.
-
-
@@ -673,6 +673,11 @@ Galiegue, et al. Expires March 27, 2013 [Page 12]
Internet-Draft JSON Schema September 2012
+ The value of "patternProperties" MUST be an object. Each member name
+ of this object SHOULD be a valid regular expression, according to the
+ ECMA 262 regular expression dialect. Each value of this object MUST
+ be an object, and each object MUST be a valid JSON Schema.
+
5.4.4.2. Conditions for successful validation
Successful validation of an object instance against these three
@@ -717,11 +722,6 @@ Internet-Draft JSON Schema September 2012
Validation of the instance succeeds if and only if, after these two
steps, set "s" is empty.
-5.4.4.5. Example
-
- This schema will be used as an example:
-
-
Galiegue, et al. Expires March 27, 2013 [Page 13]
@@ -729,6 +729,11 @@ Galiegue, et al. Expires March 27, 2013 [Page 13]
Internet-Draft JSON Schema September 2012
+5.4.4.5. Example
+
+ This schema will be used as an example:
+
+
{
"properties": {
"p1": {}
@@ -771,12 +776,7 @@ Internet-Draft JSON Schema September 2012
The set still contains two elements, "" and "finance". Validation
therefore fails.
-5.4.5. dependencies
-5.4.5.1. Valid values
-
- This keyword's value MUST be an object. This object MUST be a valid
- JSON Schema.
@@ -785,6 +785,13 @@ Galiegue, et al. Expires March 27, 2013 [Page 14]
Internet-Draft JSON Schema September 2012
+5.4.5. dependencies
+
+5.4.5.1. Valid values
+
+ This keyword's value MUST be an object. This object MUST be a valid
+ JSON Schema.
+
5.4.5.2. Conditions for successful validation
For each element in the object instance's member set, if
@@ -809,8 +816,8 @@ Internet-Draft JSON Schema September 2012
5.5.1.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
- if its value is equal to one of the elements in this keyword's array
- value.
+ if its value is lexically equivalent to one of the elements in this
+ keyword's array value.
5.5.2. type
@@ -825,14 +832,7 @@ Internet-Draft JSON Schema September 2012
the one defined by the value of this keyword. Recall: "number"
includes "integer".
-5.5.3. allOf
-
-5.5.3.1. Valid values
- 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
@@ -841,6 +841,14 @@ Galiegue, et al. Expires March 27, 2013 [Page 15]
Internet-Draft JSON Schema September 2012
+5.5.3. allOf
+
+5.5.3.1. Valid values
+
+ 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.
5.5.3.2. Conditions for successful validation
@@ -881,14 +889,6 @@ Internet-Draft JSON Schema September 2012
if it validates successfully against exactly one schema defined by
this keyword's value.
-5.5.6. not
-
-5.5.6.1. Valid values
-
- This keyword's value MUST be an object. This object MUST be a valid
- JSON Schema.
-
-
@@ -897,6 +897,13 @@ Galiegue, et al. Expires March 27, 2013 [Page 16]
Internet-Draft JSON Schema September 2012
+5.5.6. not
+
+5.5.6.1. Valid values
+
+ This keyword's value MUST be an object. This object MUST be a valid
+ JSON Schema.
+
5.5.6.2. Conditions for successful validation
An instance is valid against this keyword if and only if it fails to
@@ -935,6 +942,17 @@ Internet-Draft JSON Schema September 2012
This keyword MAY be used in root schemas, and in any subschemas.
+
+
+
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 17]
+
+Internet-Draft JSON Schema September 2012
+
+
7. Semantic validation with "format"
7.1. Foreword
@@ -946,13 +964,6 @@ Internet-Draft JSON Schema September 2012
authoritative resources, be they RFCs or other external
specifications.
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 17]
-
-Internet-Draft JSON Schema September 2012
-
-
The value of this keyword MUST be a string. This value is called a
format attribute. A format attribute can generally only validate a
given set of instance types. If the type of the instance to validate
@@ -988,26 +999,25 @@ Internet-Draft JSON Schema September 2012
7.3.2. email
-7.3.2.1. Applicability
- This attribute applies to string instances.
-7.3.2.2. Validation
-
- A string instance is valid against this attribute if and only if it
- is a valid Internet email address as defined by RFC 5322, section
- 3.4.1 [RFC5322].
+Galiegue, et al. Expires March 27, 2013 [Page 18]
+
+Internet-Draft JSON Schema September 2012
+7.3.2.1. Applicability
+ This attribute applies to string instances.
-Galiegue, et al. Expires March 27, 2013 [Page 18]
-
-Internet-Draft JSON Schema September 2012
+7.3.2.2. Validation
+ A string instance is valid against this attribute if and only if it
+ is a valid Internet email address as defined by RFC 5322, section
+ 3.4.1 [RFC5322].
7.3.3. hostname
@@ -1046,6 +1056,15 @@ Internet-Draft JSON Schema September 2012
is a valid representation of an IPv6 address as defined in RFC 2373,
section 2.2 [RFC2373].
+
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 19]
+
+Internet-Draft JSON Schema September 2012
+
+
7.3.6. uri
7.3.6.1. Applicability
@@ -1057,14 +1076,6 @@ Internet-Draft JSON Schema September 2012
A string instance is valid against this attribute if and only if it
is a valid URI, according to [RFC3986].
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 19]
-
-Internet-Draft JSON Schema September 2012
-
-
8. Calculating child instances' schema(s)
8.1. Foreword
@@ -1099,6 +1110,17 @@ Internet-Draft JSON Schema September 2012
schema as a value. In addition, boolean value true for
"additionalItems" is considered equivalent to an empty schema.
+
+
+
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 20]
+
+Internet-Draft JSON Schema September 2012
+
+
8.2.3. Calculation
8.2.3.1. If "items" is a schema
@@ -1112,15 +1134,6 @@ Internet-Draft JSON Schema September 2012
In this situation, the schema depends on the index of the child
instance:
-
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 20]
-
-Internet-Draft JSON Schema September 2012
-
-
if the index is less than, or equal to, the maximum index in the
"items" array, then the child instance must be valid against the
corresponding schema in the "items" array;
@@ -1154,6 +1167,16 @@ Internet-Draft JSON Schema September 2012
The calculation below uses the following names:
+
+
+
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 21]
+
+Internet-Draft JSON Schema September 2012
+
+
m The member name the child instance is associated to.
p The member set from "properties".
@@ -1168,15 +1191,6 @@ Internet-Draft JSON Schema September 2012
If set "p" contains value "m", then the corresponding schema in
"properties" is added to "s".
-
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 21]
-
-Internet-Draft JSON Schema September 2012
-
-
8.3.3.3. Second step: schemas in "patternProperties"
For each regex in "pp", if it matches "m" successfully, the
@@ -1212,6 +1226,13 @@ Internet-Draft JSON Schema September 2012
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
+
+
+Galiegue, et al. Expires March 27, 2013 [Page 22]
+
+Internet-Draft JSON Schema September 2012
+
+
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
@@ -1226,13 +1247,6 @@ Internet-Draft JSON Schema September 2012
www.ecma-international.org/publications/files/ECMA-ST/
Ecma-262.pdf>.
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 22]
-
-Internet-Draft JSON Schema September 2012
-
-
Appendix A. ChangeLog
TODO
@@ -1263,20 +1277,6 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index 510b57cf..5cfc6422 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -107,6 +107,10 @@
[ "a", "b" ].
+
+ Elements in an array value are said to be unique if no two elements of this array
+ are lexically equivalent, as defined in FIXME_LINK.
+
@@ -553,9 +557,7 @@
If this keyword has boolean value false, the instance validates
successfully. If it has boolean value true, the instance validates
- successfully if and only if all of its elements are unique. In other
- words, no two elements of the array instance should be equal as per the
- definition in FIXME_LINK.
+ successfully if and only if all of its elements are unique.
@@ -832,7 +834,8 @@
An instance validates successfully against this keyword if and only if
- its value is equal to one of the elements in this keyword's array value.
+ its value is lexically equivalent to one of the elements in this
+ keyword's array value.
From 5a80764d1a438ae3b8e401166d3d8e998309a58c Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 24 Sep 2012 23:06:16 +0200
Subject: [PATCH 0116/1659] Validation spec: fix mistake in "dependencies"
definition
---
proposals/json-schema-validation.txt | 56 ++++++++++++++--------------
proposals/json-schema-validation.xml | 4 +-
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 3f139962..12d4945c 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 27, 2013 SitePen (USA)
+Expires: March 28, 2013 SitePen (USA)
G. Court
- September 23, 2012
+ September 24, 2012
JSON Schema: interactive and non interactive validation
@@ -37,7 +37,7 @@ Status of This Memo
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 March 27, 2013.
+ This Internet-Draft will expire on March 28, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 27, 2013 [Page 1]
+Galiegue, et al. Expires March 28, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -108,7 +108,7 @@ Table of Contents
-Galiegue, et al. Expires March 27, 2013 [Page 2]
+Galiegue, et al. Expires March 28, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 3]
+Galiegue, et al. Expires March 28, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -220,7 +220,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 4]
+Galiegue, et al. Expires March 28, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -276,7 +276,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 5]
+Galiegue, et al. Expires March 28, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
@@ -332,7 +332,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 6]
+Galiegue, et al. Expires March 28, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
@@ -388,7 +388,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 7]
+Galiegue, et al. Expires March 28, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
@@ -444,7 +444,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 8]
+Galiegue, et al. Expires March 28, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
@@ -500,7 +500,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 9]
+Galiegue, et al. Expires March 28, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
@@ -556,7 +556,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 10]
+Galiegue, et al. Expires March 28, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
@@ -612,7 +612,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 11]
+Galiegue, et al. Expires March 28, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
@@ -668,7 +668,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 12]
+Galiegue, et al. Expires March 28, 2013 [Page 12]
Internet-Draft JSON Schema September 2012
@@ -724,7 +724,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 13]
+Galiegue, et al. Expires March 28, 2013 [Page 13]
Internet-Draft JSON Schema September 2012
@@ -780,7 +780,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 14]
+Galiegue, et al. Expires March 28, 2013 [Page 14]
Internet-Draft JSON Schema September 2012
@@ -789,8 +789,8 @@ Internet-Draft JSON Schema September 2012
5.4.5.1. Valid values
- This keyword's value MUST be an object. This object MUST be a valid
- JSON Schema.
+ This keyword's value MUST be an object. Each value of this object
+ MUST be an object, and MUST be a valid JSON Schema.
5.4.5.2. Conditions for successful validation
@@ -836,7 +836,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 15]
+Galiegue, et al. Expires March 28, 2013 [Page 15]
Internet-Draft JSON Schema September 2012
@@ -892,7 +892,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 16]
+Galiegue, et al. Expires March 28, 2013 [Page 16]
Internet-Draft JSON Schema September 2012
@@ -948,7 +948,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 17]
+Galiegue, et al. Expires March 28, 2013 [Page 17]
Internet-Draft JSON Schema September 2012
@@ -1004,7 +1004,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 18]
+Galiegue, et al. Expires March 28, 2013 [Page 18]
Internet-Draft JSON Schema September 2012
@@ -1060,7 +1060,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 19]
+Galiegue, et al. Expires March 28, 2013 [Page 19]
Internet-Draft JSON Schema September 2012
@@ -1116,7 +1116,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 20]
+Galiegue, et al. Expires March 28, 2013 [Page 20]
Internet-Draft JSON Schema September 2012
@@ -1172,7 +1172,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 21]
+Galiegue, et al. Expires March 28, 2013 [Page 21]
Internet-Draft JSON Schema September 2012
@@ -1228,7 +1228,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 22]
+Galiegue, et al. Expires March 28, 2013 [Page 22]
Internet-Draft JSON Schema September 2012
@@ -1284,5 +1284,5 @@ Authors' Addresses
-Galiegue, et al. Expires March 27, 2013 [Page 23]
+Galiegue, et al. Expires March 28, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index 5cfc6422..af9c91b8 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -794,8 +794,8 @@
- This keyword's value MUST be an object. This object MUST be a valid JSON
- Schema.
+ This keyword's value MUST be an object. Each value of this object MUST
+ be an object, and MUST be a valid JSON Schema.
From 4739e2286b1104272fc225b10815d5459c5c89ef Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 25 Sep 2012 20:30:09 +0200
Subject: [PATCH 0117/1659] Changes to core specification
* Change definition of equality :/ "Real" programming languages will have a very
hard time.
* Add definition for hyperlinking.
---
proposals/json-schema-core.txt | 208 +++++++++++++++++++++------------
proposals/json-schema-core.xml | 105 ++++++++++-------
2 files changed, 198 insertions(+), 115 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 43bc1754..79d3e7cd 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -4,9 +4,9 @@
Internet Engineering Task Force fge. Galiegue
Internet-Draft
Intended status: Informational K. Zyp, Ed.
-Expires: March 27, 2013 SitePen (USA)
+Expires: March 29, 2013 SitePen (USA)
G. Court
- September 23, 2012
+ September 25, 2012
JSON Schema: core definitions and purposes
@@ -36,7 +36,7 @@ Status of This Memo
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 March 27, 2013.
+ This Internet-Draft will expire on March 29, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue, et al. Expires March 27, 2013 [Page 1]
+Galiegue, et al. Expires March 29, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -69,11 +69,11 @@ Table of Contents
3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value lexical equivalence . . . . . . . . . . . . . . 4
+ 3.4. JSON value equivalence . . . . . . . . . . . . . . . . . . 4
3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
- 4.2. Hyperlinking . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Hypermedia and linking . . . . . . . . . . . . . . . . . . 5
5. General considerations . . . . . . . . . . . . . . . . . . . . 5
5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 5
5.2. Protocol and programming language independence . . . . . . 6
@@ -88,17 +88,18 @@ Table of Contents
7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
7.4. Inline addressing . . . . . . . . . . . . . . . . . . . . 8
+ 7.4.1. JSON Reference extension . . . . . . . . . . . . . . . 9
7.5. Security considerations . . . . . . . . . . . . . . . . . 9
8. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
8.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
8.2. Recommended correlation mechanisms for use with the
- HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 9
- 8.2.1. Correlation by means of the "Content-Type" header . . 9
+ HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 10
+ 8.2.1. Correlation by means of the "Content-Type" header . . 10
8.2.2. Correlation by means of the "Link" header . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 11
@@ -107,8 +108,7 @@ Table of Contents
-
-Galiegue, et al. Expires March 27, 2013 [Page 2]
+Galiegue, et al. Expires March 29, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 3]
+Galiegue, et al. Expires March 29, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -178,49 +178,49 @@ Internet-Draft JSON Schema September 2012
3.3. JSON Schema primitive types
- JSON Schema defines seven primitive types for JSON values:
-
- array A JSON array.
+ JSON Schema defines seven primitive types for JSON values. Primitive
+ types "array", "boolean", "number", "null", "object" and "string" are
+ equivalent to the same values as defined by RFC 4627 [RFC4627].
- boolean A JSON boolean (true or false).
+ In addition, JSON Schema defines "integer" as a subset of JSON
+ numbers whose mathematical values are natural numbers. This means
+ that the following JSON numbers are viewed as integers:
- integer A JSON number without a fraction or exponent part (see RFC
- 4627, section 2.4) [RFC4627].
+ 1;
- number Any JSON number. Number includes integer.
+ 1.0;
- null The JSON null value.
+ 1e0;
- object A JSON object.
+ 20e-1;
- string A JSON string.
+ etc.
-3.4. JSON value lexical equivalence
+3.4. JSON value equivalence
- Two JSON values are said to be lexically equivalent if and only if:
+ Two JSON values are said to be equivalent if and only if:
both are nulls; or
both are booleans, and have the same value; or
- both are strings, and have the same lexical representation (see
- RFC 4627, section 2.5 [RFC4627]; or
-
- both are integers, and have the same lexical representation; or
+ both are strings, and have the same value; or
- both are numbers, and have the same lexical representation (see
- RFC 4627, section 2.4) [RFC4627]; or
+ both are numbers, and have the same mathematical value; or
both are arrays, and:
have the same number of elements; and
- elements at the same index are lexically equivalent according
- to this definition; or
+ elements at the same index are equivalent according to this
+ definition; or
+
+
+
-Galiegue, et al. Expires March 27, 2013 [Page 4]
+Galiegue, et al. Expires March 29, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -229,8 +229,8 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
- values for a same member are lexically equivalent according to
- this definition.
+ values for a same member are equivalent according to this
+ definition.
3.5. Instance
@@ -252,17 +252,20 @@ Internet-Draft JSON Schema September 2012
4.1. Instance validation
JSON Schema allows applications to validate any JSON instance, either
- noninteractively or interactively. For instance, an application may
+ non interactively or interactively. For instance, an application may
use an external service to collect JSON instances and check that
these collected instances match its requirements against a given
schema; another application may use a schema to build an interactve
interface in order to collect user input, and check the correctness
of said input.
-4.2. Hyperlinking
+4.2. Hypermedia and linking
- JSON Schema defines a mechanism to build links to a variety of
- resources. FIXME: describe it better.
+ JSON Schema provides a method for defining link relations from
+ instances to other resources, as well as describing interpretations
+ of instances as multimedia data. This allows JSON data to be
+ interpreted as rich hypermedia documents, placed in the context of a
+ larger set of related resources.
5. General considerations
@@ -270,17 +273,17 @@ Internet-Draft JSON Schema September 2012
It is acknowledged that a JSON instance may be any valid JSON value
as defined by [RFC4627]. As such, JSON Schema does not mandate that
- an instance be of a particular type: JSON Schema can process any JSON
- value, including null. It is the domain of JSON Schema validation to
- add useful constraints to the structure and, optionally, semantics,
-Galiegue, et al. Expires March 27, 2013 [Page 5]
+Galiegue, et al. Expires March 29, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
+ an instance be of a particular type: JSON Schema can process any JSON
+ value, including null. It is the domain of JSON Schema validation to
+ add useful constraints to the structure and, optionally, semantics,
of the JSON instance being processed.
5.2. Protocol and programming language independence
@@ -326,17 +329,17 @@ Internet-Draft JSON Schema September 2012
The value of this keyword MUST be one of the following string values:
- "http://json-schema.org/draft-03/schema#" (core JSON Schema
- written against JSON Schema, draft v3 [json-schema-03]);
-
-Galiegue, et al. Expires March 27, 2013 [Page 6]
+Galiegue, et al. Expires March 29, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+ "http://json-schema.org/draft-03/schema#" (core JSON Schema
+ written against JSON Schema, draft v3 [json-schema-03]);
+
"http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
hyperschema written against JSON Schema, draft v3
[json-schema-03]);
@@ -381,14 +384,11 @@ Internet-Draft JSON Schema September 2012
Canonical addressing in JSON Schema is done using JSON Reference
[json-reference]. JSON References, when encountered, MUST be
- resolved against the root schema URI before being processed.
+ resolved against the URI of the current root schema.
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 7]
+Galiegue, et al. Expires March 29, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
@@ -396,11 +396,11 @@ Internet-Draft JSON Schema September 2012
7.4. Inline addressing
When "id" is encountered in a subschema, implementations MAY resolve
- this URI against the root schema's URI, and consider that the
+ this URI against the URI of a root schema, and consider that the
canonical URI of this subschema is the calculated URI. This is
called inline addressing.
- There SHOULD NOT be two identical "id" values in the same schema
+ There SHOULD NOT be two identical "id" values in the same root schema
which resolve to the same URI. If this is the case, subschema lookup
using inline addressing is undefined.
@@ -418,7 +418,7 @@ Internet-Draft JSON Schema September 2012
"id": "#bar"
},
"alsonested": {
- "id": t/inner.json#a"
+ "id": "t/inner.json#a"
}
},
"schema3": {
@@ -444,7 +444,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 27, 2013 [Page 8]
+Galiegue, et al. Expires March 29, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
@@ -453,13 +453,29 @@ Internet-Draft JSON Schema September 2012
#/schema3 some://where.else/completely#
+7.4.1. JSON Reference extension
+
+ The JSON Reference specification mandates that the fragment part of a
+ reference, if any, be a JSON Pointer. However, this would prevent
+ some of the URIs in the example above from being addressable. Schema
+ authors MAY use an extended form of a JSON Reference for inline
+ addressing, such as in this example:
+
+
+ {
+ "$ref": "http://x.y.z/t/inner.json#a
+ }
+
+
+ An implementation choosing to support inline addressing SHOULD
+ support this extension to JSON Reference.
+
7.5. Security considerations
Inline addressing can produce canonical URIs which differ from the
canonical URI of the root schema. Implementations MAY choose, for
- security reasons, to ignore inline addressing, and always dereference
- canonical URIs. Schema authors SHALL NOT expect that inline
- addressing be used by an implementation.
+ security reasons, to ignore inline addressing in such a situation,
+ and always dereference such canonical URIs.
Dereferencing URIs may fail to complete, or may lead to content which
is not a JSON Schema (another type of JSON value, or not a JSON
@@ -482,6 +498,13 @@ Internet-Draft JSON Schema September 2012
of, or restrictions on, protocol headers, such a correlation is out
of the normative scope of this specification.
+
+
+Galiegue, et al. Expires March 29, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
8.2. Recommended correlation mechanisms for use with the HTTP protocol
It is acknowledged by this specification that the majority of
@@ -499,12 +522,6 @@ Internet-Draft JSON Schema September 2012
An example of such a header would be:
-
-Galiegue, et al. Expires March 27, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
Content-Type: application/my-media-type+json;
profile=http://example.com/my-hyper-schema
@@ -535,6 +552,15 @@ Internet-Draft JSON Schema September 2012
10. References
+
+
+
+
+Galiegue, et al. Expires March 29, 2013 [Page 10]
+
+Internet-Draft JSON Schema September 2012
+
+
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
@@ -553,14 +579,6 @@ Internet-Draft JSON Schema September 2012
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
-
-
-
-Galiegue, et al. Expires March 27, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
-
-
Syntax", STD 66, RFC 3986, January 2005.
[json-reference] Bryan, P. and K. Zyp, "JSON Reference",
@@ -586,6 +604,19 @@ Authors' Addresses
EMail: fgaliegue@gmail.com
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 29, 2013 [Page 11]
+
+Internet-Draft JSON Schema September 2012
+
+
Kris Zyp (editor)
SitePen (USA)
530 Lytton Avenue
@@ -612,5 +643,30 @@ Authors' Addresses
-Galiegue, et al. Expires March 27, 2013 [Page 11]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue, et al. Expires March 29, 2013 [Page 12]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index d8620597..3144ead6 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -137,44 +137,46 @@
- JSON Schema defines seven primitive types for JSON values:
-
- A JSON array.
- A JSON boolean (true or false).
- A JSON number without a fraction or exponent part (see
- RFC 4627, section 2.4).
- Any JSON number. Number includes integer.
- The JSON null value.
- A JSON object.
- A JSON string.
+ JSON Schema defines seven primitive types for JSON values. Primitive types
+ "array", "boolean", "number", "null", "object" and "string" are equivalent to
+ the same values as defined by RFC 4627.
+
+
+
+ In addition, JSON Schema defines "integer" as a subset of JSON numbers whose
+ mathematical values are natural numbers. This means that the following JSON
+ numbers are viewed as integers:
+
+ 1;
+ 1.0;
+ 1e0;
+ 20e-1;
+ etc.
-
+
- Two JSON values are said to be lexically equivalent if and only if:
+ Two JSON values are said to be equivalent if and only if:
both are nulls; orboth are booleans, and have the same value; or
- both are strings, and have the same lexical representation (see RFC 4627, section 2.5; or
- both are integers, and have the same lexical representation; or
- both are numbers, and have the same lexical representation (see RFC 4627, section 2.4); or
+ both are strings, and have the same value; or
+ both are numbers, and have the same mathematical value; orboth are arrays, and:
have the same number of elements; and
- elements at the same index are lexically equivalent according to
- this definition; or
+ elements at the same index are equivalent according to this
+ definition; orboth are objects, and:
have the same set of members; and
- values for a same member are lexically equivalent according to
- this definition.
+ values for a same member are equivalent according to this
+ definition.
@@ -205,19 +207,21 @@
- JSON Schema allows applications to validate any JSON instance, either
- noninteractively or interactively. For instance, an application may use an
- external service to collect JSON instances and check that these collected
- instances match its requirements against a given schema; another application may
- use a schema to build an interactve interface in order to collect user input,
- and check the correctness of said input.
+ JSON Schema allows applications to validate any JSON instance, either non
+ interactively or interactively. For instance, an application may use an external
+ service to collect JSON instances and check that these collected instances match
+ its requirements against a given schema; another application may use a schema to
+ build an interactve interface in order to collect user input, and check the
+ correctness of said input.
-
+
- JSON Schema defines a mechanism to build links to a variety of resources. FIXME:
- describe it better.
+ JSON Schema provides a method for defining link relations from instances to
+ other resources, as well as describing interpretations of instances as
+ multimedia data. This allows JSON data to be interpreted as rich hypermedia
+ documents, placed in the context of a larger set of related resources.
@@ -349,22 +353,21 @@
Canonical addressing in JSON Schema is done using JSON Reference. JSON References, when
- encountered, MUST be resolved against the root schema URI before being
- processed.
+ encountered, MUST be resolved against the URI of the current root schema.
When "id" is encountered in a subschema, implementations MAY resolve this URI
- against the root schema's URI, and consider that the canonical URI of this
+ against the URI of a root schema, and consider that the canonical URI of this
subschema is the calculated URI. This is called inline addressing.
- There SHOULD NOT be two identical "id" values in the same schema which resolve
- to the same URI. If this is the case, subschema lookup using inline addressing
- is undefined.
+ There SHOULD NOT be two identical "id" values in the same root schema which
+ resolve to the same URI. If this is the case, subschema lookup using inline
+ addressing is undefined.
@@ -387,7 +390,7 @@
"id": "#bar"
},
"alsonested": {
- "id": t/inner.json#a"
+ "id": "t/inner.json#a"
}
},
"schema3": {
@@ -412,14 +415,38 @@
+
+
+ The JSON Reference specification mandates that the fragment part of a
+ reference, if any, be a JSON Pointer. However, this would prevent some of
+ the URIs in the example above from being addressable. Schema authors MAY use
+ an extended form of a JSON Reference for inline addressing, such as in this
+ example:
+
+
+
+
+
+
+
+
+
+ An implementation choosing to support inline addressing SHOULD support this
+ extension to JSON Reference.
+
+
Inline addressing can produce canonical URIs which differ from the canonical URI
of the root schema. Implementations MAY choose, for security reasons, to ignore
- inline addressing, and always dereference canonical URIs. Schema authors SHALL
- NOT expect that inline addressing be used by an implementation.
+ inline addressing in such a situation, and always dereference such canonical
+ URIs.
From 046184e69a99d3506c1ecc50727a9017ff7f14fd Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 25 Sep 2012 20:42:31 +0200
Subject: [PATCH 0118/1659] Changes to validation spec
* Change "member set" to "key set", "member name" to "key"
* Be in line with JSON value equality definition.
---
proposals/json-schema-validation.txt | 436 +++++++++++++--------------
proposals/json-schema-validation.xml | 79 ++---
2 files changed, 244 insertions(+), 271 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 12d4945c..5bb27688 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -2,11 +2,9 @@
Internet Engineering Task Force fge. Galiegue
-Internet-Draft
-Intended status: Informational K. Zyp, Ed.
-Expires: March 28, 2013 SitePen (USA)
- G. Court
- September 24, 2012
+Internet-Draft September 25, 2012
+Intended status: Informational
+Expires: March 29, 2013
JSON Schema: interactive and non interactive validation
@@ -37,7 +35,7 @@ Status of This Memo
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 March 28, 2013.
+ This Internet-Draft will expire on March 29, 2013.
Copyright Notice
@@ -49,16 +47,16 @@ Copyright Notice
(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
-Galiegue, et al. Expires March 28, 2013 [Page 1]
+Galiegue Expires March 29, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
- 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.
@@ -70,8 +68,8 @@ Table of Contents
3.1. Validation of string instances . . . . . . . . . . . . . . 4
3.2. Validation of numeric instances . . . . . . . . . . . . . 4
3.3. Regular expressions . . . . . . . . . . . . . . . . . . . 5
- 4. General validation considerations . . . . . . . . . . . . . . 6
- 4.1. Keywords and instance primitive types . . . . . . . . . . 6
+ 4. General validation considerations . . . . . . . . . . . . . . 5
+ 4.1. Keywords and instance primitive types . . . . . . . . . . 5
4.2. Inter-dependent keywords . . . . . . . . . . . . . . . . . 6
4.3. Default values for missing keywords . . . . . . . . . . . 6
4.4. Validation of container instances . . . . . . . . . . . . 6
@@ -84,43 +82,43 @@ Table of Contents
5.2. Validation keywords for strings . . . . . . . . . . . . . 8
5.2.1. maxLength . . . . . . . . . . . . . . . . . . . . . . 8
5.2.2. minLength . . . . . . . . . . . . . . . . . . . . . . 8
- 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.2.3. pattern . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Validation keywords for arrays . . . . . . . . . . . . . . 9
5.3.1. additionalItems and items . . . . . . . . . . . . . . 9
5.3.2. maxItems . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.3.3. minItems . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.4. uniqueItems . . . . . . . . . . . . . . . . . . . . . 11
5.4. Validation keywords for objects . . . . . . . . . . . . . 11
5.4.1. maxProperties . . . . . . . . . . . . . . . . . . . . 11
- 5.4.2. minProperties . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.2. minProperties . . . . . . . . . . . . . . . . . . . . 11
5.4.3. required . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.4. additionalProperties, properties and
patternProperties . . . . . . . . . . . . . . . . . . 12
- 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 15
+ 5.4.5. dependencies . . . . . . . . . . . . . . . . . . . . . 14
5.5. Validation keywords for any instance type . . . . . . . . 15
5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. "title" and "description" . . . . . . . . . . . . . . . . 17
+ 6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
-Galiegue, et al. Expires March 28, 2013 [Page 2]
+Galiegue Expires March 29, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
- 6.1. "title" and "description" . . . . . . . . . . . . . . . . 17
- 6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
6.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
- 7. Semantic validation with "format" . . . . . . . . . . . . . . 18
- 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Semantic validation with "format" . . . . . . . . . . . . . . 17
+ 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Implementation requirements . . . . . . . . . . . . . . . 18
7.3. Defined attributes . . . . . . . . . . . . . . . . . . . . 18
7.3.1. date-time . . . . . . . . . . . . . . . . . . . . . . 18
@@ -128,13 +126,13 @@ Internet-Draft JSON Schema September 2012
7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.5. ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. Calculating child instances' schema(s) . . . . . . . . . . . . 20
8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Defining characteristic . . . . . . . . . . . . . . . 20
8.2.2. Implied keywords and default values. . . . . . . . . . 20
- 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 21
+ 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 20
8.3. Object values . . . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Defining characteristic . . . . . . . . . . . . . . . 21
8.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 21
@@ -164,7 +162,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue, et al. Expires March 28, 2013 [Page 3]
+
+
+Galiegue Expires March 29, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -178,10 +178,6 @@ Internet-Draft JSON Schema September 2012
in interactive instance generation. Those are also described in this
specification.
- Validation is primarily concerned about structural validation of
- instances. Keywords also exist to perform semantic analysis;
- however, support for these keywords is optional.
-
This specification will use the terminology defined by the JSON
Schema core specification. It is advised that readers have a copy of
this specification.
@@ -196,12 +192,13 @@ Internet-Draft JSON Schema September 2012
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 "member set" for an object instance
- as the set of its member names; for instance, the member set of
- object value { "a": 1, "b": 2 } is [ "a", "b" ].
+ This specification uses the term "key" to refer to an object's member
+ name, and "key set" as the set of an object's member names; for
+ instance, the key set of object value { "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 lexically equivalent, as defined in FIXME_LINK.
+ of this array are equal, as defined in FIXME_LINK.
3. Interoperability considerations
@@ -217,18 +214,17 @@ Internet-Draft JSON Schema September 2012
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.
-Galiegue, et al. Expires March 28, 2013 [Page 4]
+Galiegue Expires March 29, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
- 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.
-
3.3. Regular expressions
Two validation keywords, "pattern" and "patternProperties", use
@@ -270,24 +266,21 @@ Internet-Draft JSON Schema September 2012
regular expression, it is RECOMMENDED that JSON Schema processing be
considered a failure.
+4. General validation considerations
+4.1. Keywords and instance primitive types
+ 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
-
-Galiegue, et al. Expires March 28, 2013 [Page 5]
+Galiegue Expires March 29, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
-4. General validation considerations
-
-4.1. Keywords and instance primitive types
-
- 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
@@ -330,19 +323,20 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be a JSON number. This number MUST
be strictly greater than 0.
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
-
-
5.1.1.2. Conditions for successful validation
A numeric instance is valid against "multipleOf" if and only if the
result of the division of the instance by this keyword's value is an
integer.
+
+
+
+Galiegue Expires March 29, 2013 [Page 6]
+
+Internet-Draft JSON Schema September 2012
+
+
5.1.2. maximum and exclusiveMaximum
5.1.2.1. Valid values
@@ -384,15 +378,6 @@ Internet-Draft JSON Schema September 2012
Successful validation depends on the presence and value of
"exclusiveMinimum":
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
-
-
if "exclusiveMinimum" is not present, or has boolean value false,
then the instance is valid if and only if it is greater than, or
equal to, the value of "minimum";
@@ -401,6 +386,13 @@ Internet-Draft JSON Schema September 2012
the instance is valid if and only if it is strictly greater than
the value of "minimum".
+
+
+Galiegue Expires March 29, 2013 [Page 7]
+
+Internet-Draft JSON Schema September 2012
+
+
5.1.3.3. Default value
"exclusiveMinimum", if absent, may be considered as being present
@@ -438,17 +430,6 @@ Internet-Draft JSON Schema September 2012
The length of a string instance is defined as the number of its
characters as defined by RFC 4627 [RFC4627].
-
-
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
-
5.2.2.3. Default value
"minLength", if absent, may be considered as being present with
@@ -460,6 +441,14 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be a string. This string SHOULD be a
valid regular expression, according to the ECMA 262 regular
+
+
+
+Galiegue Expires March 29, 2013 [Page 8]
+
+Internet-Draft JSON Schema September 2012
+
+
expression dialect.
5.2.3.2. Conditions for successful validation
@@ -497,14 +486,6 @@ Internet-Draft JSON Schema September 2012
value of items is an array (which is must be at this point), the
instance is valid if and only if its number of elements is less
than, or equal to, the number of elements in the array value of
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
items.
5.3.1.3. Example
@@ -514,6 +495,16 @@ Internet-Draft JSON Schema September 2012
only situation under which an instance may fail to validate
successfully.
+
+
+
+
+
+Galiegue Expires March 29, 2013 [Page 9]
+
+Internet-Draft JSON Schema September 2012
+
+
This is an example schema:
@@ -553,14 +544,6 @@ Internet-Draft JSON Schema September 2012
An array instance is valid against "maxItems" if and only if its
number of elements is less than, or equal to, the value of this
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
-
-
keyword.
5.3.3. minItems
@@ -570,6 +553,14 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be an integer. This integer MUST be
greater than, or equal to, 0.
+
+
+
+Galiegue Expires March 29, 2013 [Page 10]
+
+Internet-Draft JSON Schema September 2012
+
+
5.3.3.2. Conditions for successful validation
An array instance is valid against "minItems" if and only if its
@@ -607,23 +598,24 @@ Internet-Draft JSON Schema September 2012
The value for this keyword MUST be an integer. This integer MUST be
greater than, or equal to, 0.
+5.4.1.2. Conditions for successful validation
+
+ An object instance is valid against "maxProperties" if and only if
+ its number of members is less than, or equal to, the value of this
+ keyword.
+5.4.2. minProperties
-Galiegue, et al. Expires March 28, 2013 [Page 11]
-
-Internet-Draft JSON Schema September 2012
-5.4.1.2. Conditions for successful validation
- An object instance is valid against "maxProperties" if and only if
- its number of members is less than, or equal to, the value of this
- keyword.
+Galiegue Expires March 29, 2013 [Page 11]
+
+Internet-Draft JSON Schema September 2012
-5.4.2. minProperties
5.4.2.1. Valid values
@@ -652,7 +644,7 @@ Internet-Draft JSON Schema September 2012
5.4.3.2. Conditions for successful validation
An object instance is valid against this keyword if and only if its
- member set contains all elements in this keyword's array.
+ key set contains all elements in this keyword's array.
5.4.4. additionalProperties, properties and patternProperties
@@ -665,19 +657,22 @@ Internet-Draft JSON Schema September 2012
object MUST be an object, and each object MUST be a valid JSON
Schema.
+ The value of "patternProperties" MUST be an object. Each key of this
+ object SHOULD be a valid regular expression, according to the ECMA
+ 262 regular expression dialect. Each value of this object MUST be an
+ object, and each object MUST be a valid JSON Schema.
+
+
-Galiegue, et al. Expires March 28, 2013 [Page 12]
+
+
+Galiegue Expires March 29, 2013 [Page 12]
Internet-Draft JSON Schema September 2012
- The value of "patternProperties" MUST be an object. Each member name
- of this object SHOULD be a valid regular expression, according to the
- ECMA 262 regular expression dialect. Each value of this object MUST
- be an object, and each object MUST be a valid JSON Schema.
-
5.4.4.2. Conditions for successful validation
Successful validation of an object instance against these three
@@ -699,18 +694,18 @@ Internet-Draft JSON Schema September 2012
5.4.4.4. If "additionalProperties" has boolean value false
- In this case, validation of the instance depends on the member set of
+ In this case, validation of the instance depends on the key set of
"properties" and "patternProperties". In this section, the elements
- of "patternProperties"' member set will be called regexes for
+ of "patternProperties"' key set will be called regexes for
convenience.
The first step is to collect the following sets:
- s The member set of the instance to validate.
+ s The key set of the instance to validate.
- p The member set from "properties".
+ p The key set from "properties".
- pp The member set from "patternProperties".
+ pp The key set from "patternProperties".
Having collected these three sets, the process is as follows:
@@ -722,16 +717,16 @@ Internet-Draft JSON Schema September 2012
Validation of the instance succeeds if and only if, after these two
steps, set "s" is empty.
+5.4.4.5. Example
+ This schema will be used as an example:
-Galiegue, et al. Expires March 28, 2013 [Page 13]
-
-Internet-Draft JSON Schema September 2012
-5.4.4.5. Example
- This schema will be used as an example:
+Galiegue Expires March 29, 2013 [Page 13]
+
+Internet-Draft JSON Schema September 2012
{
@@ -776,31 +771,28 @@ Internet-Draft JSON Schema September 2012
The set still contains two elements, "" and "finance". Validation
therefore fails.
+5.4.5. dependencies
+
+5.4.5.1. Valid values
+ This keyword's value MUST be an object. Each value of this object
+ MUST be an object, and MUST be a valid JSON Schema.
-Galiegue, et al. Expires March 28, 2013 [Page 14]
+Galiegue Expires March 29, 2013 [Page 14]
Internet-Draft JSON Schema September 2012
-5.4.5. dependencies
-
-5.4.5.1. Valid values
-
- This keyword's value MUST be an object. Each value of this object
- MUST be an object, and MUST be a valid JSON Schema.
-
5.4.5.2. Conditions for successful validation
- For each element in the object instance's member set, if
- "dependencies" contains a member by the same name, the object
- instance must validate successfully against the matching schema in
- "dependencies".
+ For each element in the object instance's key set, if "dependencies"
+ contains a key by the same name, the object instance must validate
+ successfully against the matching schema in "dependencies".
Note that this is the object instance itself which must validate
- successfully, not the value associated with that member.
+ successfully, not the value associated with that key.
5.5. Validation keywords for any instance type
@@ -816,8 +808,8 @@ Internet-Draft JSON Schema September 2012
5.5.1.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
- if its value is lexically equivalent to one of the elements in this
- keyword's array value.
+ if its value is equal to one of the elements in this keyword's array
+ value.
5.5.2. type
@@ -832,15 +824,6 @@ Internet-Draft JSON Schema September 2012
the one defined by the value of this keyword. Recall: "number"
includes "integer".
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 15]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5.3. allOf
5.5.3.1. Valid values
@@ -851,6 +834,13 @@ Internet-Draft JSON Schema September 2012
Elements of the array MUST be objects. Each object MUST be a valid
JSON Schema.
+
+
+Galiegue Expires March 29, 2013 [Page 15]
+
+Internet-Draft JSON Schema September 2012
+
+
5.5.3.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
@@ -889,20 +879,23 @@ Internet-Draft JSON Schema September 2012
if it validates successfully against exactly one schema defined by
this keyword's value.
+5.5.6. not
+
+5.5.6.1. Valid values
+
+ This keyword's value MUST be an object. This object MUST be a valid
+ JSON Schema.
-Galiegue, et al. Expires March 28, 2013 [Page 16]
-
-Internet-Draft JSON Schema September 2012
-5.5.6. not
-5.5.6.1. Valid values
- This keyword's value MUST be an object. This object MUST be a valid
- JSON Schema.
+Galiegue Expires March 29, 2013 [Page 16]
+
+Internet-Draft JSON Schema September 2012
+
5.5.6.2. Conditions for successful validation
@@ -942,17 +935,6 @@ Internet-Draft JSON Schema September 2012
This keyword MAY be used in root schemas, and in any subschemas.
-
-
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 17]
-
-Internet-Draft JSON Schema September 2012
-
-
7. Semantic validation with "format"
7.1. Foreword
@@ -964,6 +946,13 @@ Internet-Draft JSON Schema September 2012
authoritative resources, be they RFCs or other external
specifications.
+
+
+Galiegue Expires March 29, 2013 [Page 17]
+
+Internet-Draft JSON Schema September 2012
+
+
The value of this keyword MUST be a string. This value is called a
format attribute. A format attribute can generally only validate a
given set of instance types. If the type of the instance to validate
@@ -999,25 +988,26 @@ Internet-Draft JSON Schema September 2012
7.3.2. email
+7.3.2.1. Applicability
+ This attribute applies to string instances.
+7.3.2.2. Validation
+ A string instance is valid against this attribute if and only if it
+ is a valid Internet email address as defined by RFC 5322, section
+ 3.4.1 [RFC5322].
-Galiegue, et al. Expires March 28, 2013 [Page 18]
-
-Internet-Draft JSON Schema September 2012
-7.3.2.1. Applicability
- This attribute applies to string instances.
-7.3.2.2. Validation
- A string instance is valid against this attribute if and only if it
- is a valid Internet email address as defined by RFC 5322, section
- 3.4.1 [RFC5322].
+Galiegue Expires March 29, 2013 [Page 18]
+
+Internet-Draft JSON Schema September 2012
+
7.3.3. hostname
@@ -1056,15 +1046,6 @@ Internet-Draft JSON Schema September 2012
is a valid representation of an IPv6 address as defined in RFC 2373,
section 2.2 [RFC2373].
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 19]
-
-Internet-Draft JSON Schema September 2012
-
-
7.3.6. uri
7.3.6.1. Applicability
@@ -1076,6 +1057,14 @@ Internet-Draft JSON Schema September 2012
A string instance is valid against this attribute if and only if it
is a valid URI, according to [RFC3986].
+
+
+
+Galiegue Expires March 29, 2013 [Page 19]
+
+Internet-Draft JSON Schema September 2012
+
+
8. Calculating child instances' schema(s)
8.1. Foreword
@@ -1110,17 +1099,6 @@ Internet-Draft JSON Schema September 2012
schema as a value. In addition, boolean value true for
"additionalItems" is considered equivalent to an empty schema.
-
-
-
-
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 20]
-
-Internet-Draft JSON Schema September 2012
-
-
8.2.3. Calculation
8.2.3.1. If "items" is a schema
@@ -1134,6 +1112,15 @@ Internet-Draft JSON Schema September 2012
In this situation, the schema depends on the index of the child
instance:
+
+
+
+
+Galiegue Expires March 29, 2013 [Page 20]
+
+Internet-Draft JSON Schema September 2012
+
+
if the index is less than, or equal to, the maximum index in the
"items" array, then the child instance must be valid against the
corresponding schema in the "items" array;
@@ -1146,14 +1133,14 @@ Internet-Draft JSON Schema September 2012
8.3.1. Defining characteristic
The defining characteristic of the child instance of an object is the
- member name this child is associated to.
+ key this child is associated to.
8.3.2. Implied keywords
The three keywords implied in this calculation are "properties",
"patternProperties" and "additionalProperties".
- If "properties" of "patternProperties" are absent, they are
+ If "properties" or "patternProperties" are absent, they are
considered present with an empty object as a value (note, an empty
object, NOT an empty schema).
@@ -1167,29 +1154,28 @@ Internet-Draft JSON Schema September 2012
The calculation below uses the following names:
+ m The key the child instance is associated to.
+ p The key set from "properties".
+ pp The key set from "patternProperties". Elements of this set will
+ be called regexes for convenience.
+ s The set of schemas for the child instance.
+8.3.3.2. First step: schemas in "properties"
-Galiegue, et al. Expires March 28, 2013 [Page 21]
-
-Internet-Draft JSON Schema September 2012
-
+ If set "p" contains value "m", then the corresponding schema in
+ "properties" is added to "s".
- m The member name the child instance is associated to.
- p The member set from "properties".
- pp The member set from "patternProperties". Elements of this set
- will be called regexes for convenience.
- s The set of schemas for the child instance.
-8.3.3.2. First step: schemas in "properties"
+Galiegue Expires March 29, 2013 [Page 21]
+
+Internet-Draft JSON Schema September 2012
- If set "p" contains value "m", then the corresponding schema in
- "properties" is added to "s".
8.3.3.3. Second step: schemas in "patternProperties"
@@ -1226,13 +1212,6 @@ Internet-Draft JSON Schema September 2012
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
-
-
-Galiegue, et al. Expires March 28, 2013 [Page 22]
-
-Internet-Draft JSON Schema September 2012
-
-
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
@@ -1247,30 +1226,28 @@ Internet-Draft JSON Schema September 2012
www.ecma-international.org/publications/files/ECMA-ST/
Ecma-262.pdf>.
+
+
+Galiegue Expires March 29, 2013 [Page 22]
+
+Internet-Draft JSON Schema September 2012
+
+
Appendix A. ChangeLog
TODO
-Authors' Addresses
+Author's Address
Francis Galiegue
EMail: fgaliegue@gmail.com
- Kris Zyp (editor)
- SitePen (USA)
- 530 Lytton Avenue
- Palo Alto, CA 94301
- USA
- Phone: +1 650 968 8787
- EMail: kris@sitepen.com
- Gary Court
- EMail: gary.court@gmail.com
@@ -1284,5 +1261,28 @@ Authors' Addresses
-Galiegue, et al. Expires March 28, 2013 [Page 23]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Galiegue Expires March 29, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index af9c91b8..ff0cf033 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -25,25 +25,6 @@
-
- SitePen (USA)
-
-
- 530 Lytton Avenue
- Palo Alto, CA 94301
- USA
-
- +1 650 968 8787
- kris@sitepen.com
-
-
-
-
-
- gary.court@gmail.com
-
-
-
Internet Engineering Task ForceJSON
@@ -72,12 +53,6 @@
this specification.
-
- Validation is primarily concerned about structural validation of instances.
- Keywords also exist to perform semantic analysis; however, support for these
- keywords is optional.
-
-
This specification will use the terminology defined by the JSON Schema core
specification. It is advised that readers have a copy of this specification.
@@ -102,14 +77,14 @@
- This specification uses the term "member set" for an object instance as the set of
- its member names; for instance, the member set of object value { "a": 1, "b": 2 } is
- [ "a", "b" ].
+ This specification uses the term "key" to refer to an object's member name, and "key
+ set" as the set of an object's member names; for instance, the key set of object
+ value { "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 lexically equivalent, as defined in FIXME_LINK.
+ are equal, as defined in FIXME_LINK.
@@ -631,8 +606,8 @@
- An object instance is valid against this keyword if and only if its
- member set contains all elements in this keyword's array.
+ An object instance is valid against this keyword if and only if its key
+ set contains all elements in this keyword's array.
@@ -652,10 +627,10 @@
- The value of "patternProperties" MUST be an object. Each member name of
- this object SHOULD be a valid regular expression, according to the ECMA
- 262 regular expression dialect. 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 key of this
+ object SHOULD be a valid regular expression, according to the ECMA 262
+ regular expression dialect. Each value of this object MUST be an object,
+ and each object MUST be a valid JSON Schema.
@@ -688,18 +663,18 @@
- In this case, validation of the instance depends on the member set of
+ In this case, validation of the instance depends on the key set of
"properties" and "patternProperties". In this section, the elements of
- "patternProperties"' member set will be called regexes for convenience.
+ "patternProperties"' key set will be called regexes for convenience.
The first step is to collect the following sets:
- The member set of the instance to validate.
- The member set from "properties".
- The member set from "patternProperties".
+ The key set of the instance to validate.
+ The key set from "properties".
+ The key set from "patternProperties".
@@ -801,14 +776,14 @@
- For each element in the object instance's member set, if "dependencies"
- contains a member by the same name, the object instance must validate
+ For each element in the object instance's key set, if "dependencies"
+ contains a key by the same name, the object instance must validate
successfully against the matching schema in "dependencies".
Note that this is the object instance itself which must validate
- successfully, not the value associated with that member.
+ successfully, not the value associated with that key.
@@ -834,8 +809,7 @@
An instance validates successfully against this keyword if and only if
- its value is lexically equivalent to one of the elements in this
- keyword's array value.
+ its value is equal to one of the elements in this keyword's array value.
@@ -1211,8 +1185,8 @@
- The defining characteristic of the child instance of an object is the member
- name this child is associated to.
+ The defining characteristic of the child instance of an object is the key
+ this child is associated to.
@@ -1223,7 +1197,7 @@
- If "properties" of "patternProperties" are absent, they are considered
+ If "properties" or "patternProperties" are absent, they are considered
present with an empty object as a value (note, an empty object, NOT an empty
schema).
@@ -1242,11 +1216,10 @@
The calculation below uses the following names:
- The member name the child instance is associated
- to.
- The member set from "properties".
- The member set from "patternProperties". Elements
- of this set will be called regexes for convenience.
+ The key the child instance is associated to.
+ The key set from "properties".
+ The key set from "patternProperties". Elements of
+ this set will be called regexes for convenience.The set of schemas for the child instance.
From 5598459d8d3d09a8e9bfd87f3c2af871e83ae826 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 25 Sep 2012 20:48:27 +0200
Subject: [PATCH 0119/1659] Some more wording changes
---
proposals/json-schema-core.txt | 102 ++++++++++++++++-----------------
proposals/json-schema-core.xml | 15 +++--
2 files changed, 61 insertions(+), 56 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index 79d3e7cd..c1ee19f3 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -77,16 +77,16 @@ Table of Contents
5. General considerations . . . . . . . . . . . . . . . . . . . . 5
5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 5
5.2. Protocol and programming language independence . . . . . . 6
- 5.3. Extending JSON Schema . . . . . . . . . . . . . . . . . . 6
+ 5.3. Keyword support and extension . . . . . . . . . . . . . . 6
5.4. Security considerations . . . . . . . . . . . . . . . . . 6
6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 6
6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 6.2. Valid values . . . . . . . . . . . . . . . . . . . . . . . 6
+ 6.2. Valid values . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Addressing mechanisms . . . . . . . . . . . . . . . . . . 7
7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
- 7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 7
+ 7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 8
7.4. Inline addressing . . . . . . . . . . . . . . . . . . . . 8
7.4.1. JSON Reference extension . . . . . . . . . . . . . . . 9
7.5. Security considerations . . . . . . . . . . . . . . . . . 9
@@ -96,7 +96,7 @@ Table of Contents
HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 10
8.2.1. Correlation by means of the "Content-Type" header . . 10
8.2.2. Correlation by means of the "Link" header . . . . . . 10
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
@@ -295,21 +295,23 @@ Internet-Draft JSON Schema September 2012
instance to a schema over HTTP, which is the dominant protocol used
for Internet-enabled interactive applications.
-5.3. Extending JSON Schema
+5.3. Keyword support and extension
Implementations MAY choose to 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 handle.
+
5.4. Security considerations
- Both schemas and instances are written in JSON. As such, all
- security considerations defined in [RFC4627] apply.
+ Both schemas and instances are JSON values. As such, all security
+ considerations defined in [RFC4627] apply.
JSON Schema does not define an internal security mechanism. It is up
- to applications to determine the level of trust placed into JSON data
- coming from external sources (whether this data be an instance or a
- schema).
+ to applications to determine the level of trust placed into JSON
+ values coming from external sources (whether this data be an instance
+ or a schema), using any mechanism at their disposal.
6. The "$schema" keyword
@@ -325,9 +327,7 @@ Internet-Draft JSON Schema September 2012
Any of these schemas also validate themselves successfully.
-6.2. Valid values
- The value of this keyword MUST be one of the following string values:
@@ -337,6 +337,10 @@ Galiegue, et al. Expires March 29, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+6.2. Valid values
+
+ The value of this keyword MUST be one of the following string values:
+
"http://json-schema.org/draft-03/schema#" (core JSON Schema
written against JSON Schema, draft v3 [json-schema-03]);
@@ -380,11 +384,7 @@ Internet-Draft JSON Schema September 2012
otherwise, it is RECOMMENDED that implementations consider that
the URI of the schema is either the empty URI, or a URN.
-7.3. Canonical addressing
- Canonical addressing in JSON Schema is done using JSON Reference
- [json-reference]. JSON References, when encountered, MUST be
- resolved against the URI of the current root schema.
@@ -393,6 +393,12 @@ Galiegue, et al. Expires March 29, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+7.3. Canonical addressing
+
+ Canonical addressing in JSON Schema is done using JSON Reference
+ [json-reference]. JSON References, when encountered, MUST be
+ resolved against the URI of the current root schema.
+
7.4. Inline addressing
When "id" is encountered in a subschema, implementations MAY resolve
@@ -432,12 +438,6 @@ Internet-Draft JSON Schema September 2012
# (document root) http://x.y.z/rootschema.json#
- #/schema1 http://x.y.z/rootschema.json#foo
-
- #/schema2 http://x.y.z/otherschema.json#
-
- #/schema2/nested http://x.y.z/rootschema.json#bar
-
@@ -449,6 +449,12 @@ Galiegue, et al. Expires March 29, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
+ #/schema1 http://x.y.z/rootschema.json#foo
+
+ #/schema2 http://x.y.z/otherschema.json#
+
+ #/schema2/nested http://x.y.z/rootschema.json#bar
+
#/schema2/alsonested http://x.y.z/t/inner.json#a
#/schema3 some://where.else/completely#
@@ -491,12 +497,6 @@ Internet-Draft JSON Schema September 2012
headers.
In addition, if the protocol also carries media type information (by
- means, for instance, of a "Content-Type" header), an instance MUST be
- one of "application/json" or any other subtype.
-
- Should the scenario above be inapplicable, due either to the absence
- of, or restrictions on, protocol headers, such a correlation is out
- of the normative scope of this specification.
@@ -505,6 +505,13 @@ Galiegue, et al. Expires March 29, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
+ means, for instance, of a "Content-Type" header), an instance MUST be
+ one of "application/json" or any other subtype.
+
+ Should the scenario above be inapplicable, due either to the absence
+ of, or restrictions on, protocol headers, such a correlation is out
+ of the normative scope of this specification.
+
8.2. Recommended correlation mechanisms for use with the HTTP protocol
It is acknowledged by this specification that the majority of
@@ -542,15 +549,8 @@ Internet-Draft JSON Schema September 2012
Link: ; rel="describedBy"
-9. IANA Considerations
-
- The proposed MIME media type for JSON Schema is defined as follows:
-
- type name: application;
- subtype name: schema+json.
-10. References
@@ -561,6 +561,16 @@ Galiegue, et al. Expires March 29, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
+9. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is defined as follows:
+
+ type name: application;
+
+ subtype name: schema+json.
+
+10. References
+
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
@@ -597,24 +607,21 @@ Appendix A. ChangeLog
TODO
-Authors' Addresses
-
- Francis Galiegue
-
- EMail: fgaliegue@gmail.com
-
+Galiegue, et al. Expires March 29, 2013 [Page 11]
+
+Internet-Draft JSON Schema September 2012
+Authors' Addresses
+ Francis Galiegue
-Galiegue, et al. Expires March 29, 2013 [Page 11]
-
-Internet-Draft JSON Schema September 2012
+ EMail: fgaliegue@gmail.com
Kris Zyp (editor)
@@ -653,13 +660,6 @@ Internet-Draft JSON Schema September 2012
-
-
-
-
-
-
-
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 3144ead6..c80bec99 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -249,24 +249,29 @@
-
+
Implementations MAY choose to 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 handle.
+
- Both schemas and instances are written in JSON. As such, all security
- considerations defined in apply.
+ Both schemas and instances are JSON values. As such, all security considerations
+ defined in apply.
JSON Schema does not define an internal security mechanism. It is up to
- applications to determine the level of trust placed into JSON data coming from
- external sources (whether this data be an instance or a schema).
+ applications to determine the level of trust placed into JSON values coming from
+ external sources (whether this data be an instance or a schema), using any
+ mechanism at their disposal.
From 8518279126bd27664d8ed3e51a676f71e59d5f38 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 25 Sep 2012 21:49:56 +0200
Subject: [PATCH 0120/1659] Core schema: fix integer definition
N does not include negative numbers.
---
proposals/json-schema-core.txt | 10 +++++-----
proposals/json-schema-core.xml | 7 ++++---
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index c1ee19f3..ce7e6b6b 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -182,9 +182,9 @@ Internet-Draft JSON Schema September 2012
types "array", "boolean", "number", "null", "object" and "string" are
equivalent to the same values as defined by RFC 4627 [RFC4627].
- In addition, JSON Schema defines "integer" as a subset of JSON
- numbers whose mathematical values are natural numbers. This means
- that the following JSON numbers are viewed as integers:
+ In addition, JSON Schema defines an "integer" as any JSON number
+ whose mathematical value is an integer. This means that the
+ following JSON numbers are viewed as integers:
1;
@@ -194,6 +194,8 @@ Internet-Draft JSON Schema September 2012
20e-1;
+ -0.3e3;
+
etc.
3.4. JSON value equivalence
@@ -218,8 +220,6 @@ Internet-Draft JSON Schema September 2012
-
-
Galiegue, et al. Expires March 29, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index c80bec99..924afe56 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -143,14 +143,15 @@
- In addition, JSON Schema defines "integer" as a subset of JSON numbers whose
- mathematical values are natural numbers. This means that the following JSON
- numbers are viewed as integers:
+ In addition, JSON Schema defines an "integer" as any JSON number whose
+ mathematical value is an integer. This means that the following JSON numbers are
+ viewed as integers:
1;1.0;1e0;20e-1;
+ -0.3e3;etc.
From b3b31bd06a2330b97a7bb22bc00f76a4bd4992f0 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Tue, 25 Sep 2012 23:27:03 +0200
Subject: [PATCH 0121/1659] Back to lexical equivalence, even if too strong
But "1.0 is an integer" generates an outcry, as predicted.
---
proposals/json-schema-core.txt | 44 +++++++++++++--------------
proposals/json-schema-core.xml | 45 +++++++++++++---------------
proposals/json-schema-validation.txt | 6 ++--
proposals/json-schema-validation.xml | 5 ++--
4 files changed, 49 insertions(+), 51 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index ce7e6b6b..cc9b8dfe 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -69,7 +69,7 @@ Table of Contents
3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value equivalence . . . . . . . . . . . . . . . . . . 4
+ 3.4. JSON value lexical equivalence . . . . . . . . . . . . . . 4
3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
@@ -178,45 +178,45 @@ Internet-Draft JSON Schema September 2012
3.3. JSON Schema primitive types
- JSON Schema defines seven primitive types for JSON values. Primitive
- types "array", "boolean", "number", "null", "object" and "string" are
- equivalent to the same values as defined by RFC 4627 [RFC4627].
+ JSON Schema defines seven primitive types for JSON values:
- In addition, JSON Schema defines an "integer" as any JSON number
- whose mathematical value is an integer. This means that the
- following JSON numbers are viewed as integers:
+ array A JSON array.
- 1;
+ boolean A JSON boolean (true or false).
- 1.0;
+ integer A JSON number without a fraction or exponent part (see RFC
+ 4627, section 2.4) [RFC4627].
- 1e0;
+ number Any JSON number. Number includes integer.
- 20e-1;
+ null The JSON null value.
- -0.3e3;
+ object A JSON object.
- etc.
+ string A JSON string.
-3.4. JSON value equivalence
+3.4. JSON value lexical equivalence
- Two JSON values are said to be equivalent if and only if:
+ Two JSON values are said to be lexically equivalent if and only if:
both are nulls; or
both are booleans, and have the same value; or
- both are strings, and have the same value; or
+ both are strings, and have the same lexical representation (see
+ RFC 4627, section 2.5 [RFC4627]; or
- both are numbers, and have the same mathematical value; or
+ both are integers, and have the same lexical representation; or
+
+ both are numbers, and have the same lexical representation (see
+ RFC 4627, section 2.4) [RFC4627]; or
both are arrays, and:
have the same number of elements; and
- elements at the same index are equivalent according to this
- definition; or
-
+ elements at the same index are lexically equivalent according
+ to this definition; or
@@ -229,8 +229,8 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
- values for a same member are equivalent according to this
- definition.
+ values for a same member are lexically equivalent according to
+ this definition.
3.5. Instance
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 924afe56..0776932f 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -137,47 +137,44 @@
- JSON Schema defines seven primitive types for JSON values. Primitive types
- "array", "boolean", "number", "null", "object" and "string" are equivalent to
- the same values as defined by RFC 4627.
-
-
-
- In addition, JSON Schema defines an "integer" as any JSON number whose
- mathematical value is an integer. This means that the following JSON numbers are
- viewed as integers:
-
- 1;
- 1.0;
- 1e0;
- 20e-1;
- -0.3e3;
- etc.
+ JSON Schema defines seven primitive types for JSON values:
+
+ A JSON array.
+ A JSON boolean (true or false).
+ A JSON number without a fraction or exponent part (see
+ RFC 4627, section 2.4).
+ Any JSON number. Number includes integer.
+ The JSON null value.
+ A JSON object.
+ A JSON string.
-
+
- Two JSON values are said to be equivalent if and only if:
+ Two JSON values are said to be lexically equivalent if and only if:
both are nulls; orboth are booleans, and have the same value; or
- both are strings, and have the same value; or
- both are numbers, and have the same mathematical value; or
+ both are strings, and have the same lexical representation (see RFC 4627, section 2.5; or
+ both are integers, and have the same lexical representation; or
+ both are numbers, and have the same lexical representation (see RFC 4627, section 2.4); orboth are arrays, and:
have the same number of elements; and
- elements at the same index are equivalent according to this
- definition; or
+ elements at the same index are lexically equivalent according to
+ this definition; orboth are objects, and:
have the same set of members; and
- values for a same member are equivalent according to this
- definition.
+ values for a same member are lexically equivalent according to
+ this definition.
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 5bb27688..e4f3cb70 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -198,7 +198,7 @@ Internet-Draft JSON Schema September 2012
"b" ].
Elements in an array value are said to be unique if no two elements
- of this array are equal, as defined in FIXME_LINK.
+ of this array are lexically equivalent, as defined in FIXME_LINK.
3. Interoperability considerations
@@ -808,8 +808,8 @@ Internet-Draft JSON Schema September 2012
5.5.1.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
- if its value is equal to one of the elements in this keyword's array
- value.
+ if its value is lexically equivalent to one of the elements in this
+ keyword's array value.
5.5.2. type
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index ff0cf033..8e15b350 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -84,7 +84,7 @@
Elements in an array value are said to be unique if no two elements of this array
- are equal, as defined in FIXME_LINK.
+ are lexically equivalent, as defined in FIXME_LINK.
@@ -809,7 +809,8 @@
An instance validates successfully against this keyword if and only if
- its value is equal to one of the elements in this keyword's array value.
+ its value is lexically equivalent to one of the elements in this
+ keyword's array value.
From 1f629f35951a0723eb86a1b54056016afebaf053 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Wed, 26 Sep 2012 12:17:41 +0200
Subject: [PATCH 0122/1659] Get back on the definition of equality again
Place constraints on schema authors and instance producers so that integer
numeric instances be produced using their canonical form.
---
proposals/json-schema-core.txt | 176 +++++++++++++--------------
proposals/json-schema-core.xml | 83 ++++++-------
proposals/json-schema-validation.txt | 58 ++++-----
proposals/json-schema-validation.xml | 5 +-
4 files changed, 154 insertions(+), 168 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index cc9b8dfe..b5796846 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -2,11 +2,9 @@
Internet Engineering Task Force fge. Galiegue
-Internet-Draft
-Intended status: Informational K. Zyp, Ed.
-Expires: March 29, 2013 SitePen (USA)
- G. Court
- September 25, 2012
+Internet-Draft September 26, 2012
+Intended status: Informational
+Expires: March 30, 2013
JSON Schema: core definitions and purposes
@@ -36,7 +34,7 @@ Status of This Memo
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 March 29, 2013.
+ This Internet-Draft will expire on March 30, 2013.
Copyright Notice
@@ -49,16 +47,16 @@ Copyright Notice
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
-Galiegue, et al. Expires March 29, 2013 [Page 1]
+Galiegue Expires March 30, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
- 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.
Table of Contents
@@ -69,7 +67,7 @@ Table of Contents
3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value lexical equivalence . . . . . . . . . . . . . . 4
+ 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
@@ -77,8 +75,9 @@ Table of Contents
5. General considerations . . . . . . . . . . . . . . . . . . . . 5
5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 5
5.2. Protocol and programming language independence . . . . . . 6
- 5.3. Keyword support and extension . . . . . . . . . . . . . . 6
- 5.4. Security considerations . . . . . . . . . . . . . . . . . 6
+ 5.3. Integer numeric instances . . . . . . . . . . . . . . . . 6
+ 5.4. JSON Schema extension . . . . . . . . . . . . . . . . . . 6
+ 5.5. Security considerations . . . . . . . . . . . . . . . . . 6
6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 6
6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Valid values . . . . . . . . . . . . . . . . . . . . . . . 7
@@ -108,7 +107,8 @@ Table of Contents
-Galiegue, et al. Expires March 29, 2013 [Page 2]
+
+Galiegue Expires March 30, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -123,10 +123,8 @@ Internet-Draft JSON Schema September 2012
This document defines the core terminology used by JSON Schema.
Other linked specifications, which expand on a particular role of
- JSON Schema, will use that terminology.
-
- This document also defines the mechanisms used for JSON Schema
- identification and referencing.
+ JSON Schema, will use that terminology. This document also defines
+ the mechanisms used for JSON Schema identification and addressing.
2. Conventions and Terminology
@@ -161,18 +159,16 @@ Internet-Draft JSON Schema September 2012
"anotherschema": {
"title": "alsonested"
}
+ }
+ }
-Galiegue, et al. Expires March 29, 2013 [Page 3]
+Galiegue Expires March 30, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
- }
- }
-
-
In this example, "nested" and "alsonested" are subschemas, and "root"
is a root schema.
@@ -182,7 +178,7 @@ Internet-Draft JSON Schema September 2012
array A JSON array.
- boolean A JSON boolean (true or false).
+ boolean A JSON boolean.
integer A JSON number without a fraction or exponent part (see RFC
4627, section 2.4) [RFC4627].
@@ -195,42 +191,42 @@ Internet-Draft JSON Schema September 2012
string A JSON string.
-3.4. JSON value lexical equivalence
+3.4. JSON value equality
- Two JSON values are said to be lexically equivalent if and only if:
+ Two JSON values are said to be equal if and only if:
both are nulls; or
both are booleans, and have the same value; or
- both are strings, and have the same lexical representation (see
- RFC 4627, section 2.5 [RFC4627]; or
+ both are strings, and have the same value; or
- both are integers, and have the same lexical representation; or
+ both are integers, and have the same value; or
- both are numbers, and have the same lexical representation (see
- RFC 4627, section 2.4) [RFC4627]; or
+ both are numbers, and have the same value; or
both are arrays, and:
have the same number of elements; and
- elements at the same index are lexically equivalent according
- to this definition; or
+ elements at the same index are equal according to this
+ definition; or
+ both are objects, and:
+ have the same set of members; and
-Galiegue, et al. Expires March 29, 2013 [Page 4]
-
-Internet-Draft JSON Schema September 2012
- both are objects, and:
- have the same set of members; and
- values for a same member are lexically equivalent according to
- this definition.
+Galiegue Expires March 30, 2013 [Page 4]
+
+Internet-Draft JSON Schema September 2012
+
+
+ values for a same member are equal according to this
+ definition.
3.5. Instance
@@ -273,19 +269,18 @@ Internet-Draft JSON Schema September 2012
It is acknowledged that a JSON instance may be any valid JSON value
as defined by [RFC4627]. As such, JSON Schema does not mandate that
+ an instance be of a particular type: JSON Schema can process any JSON
+ value, including null. It is the domain of JSON Schema validation to
+ add useful constraints to the structure and, optionally, semantics,
+ of the JSON instance being processed.
-Galiegue, et al. Expires March 29, 2013 [Page 5]
+Galiegue Expires March 30, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
- an instance be of a particular type: JSON Schema can process any JSON
- value, including null. It is the domain of JSON Schema validation to
- add useful constraints to the structure and, optionally, semantics,
- of the JSON instance being processed.
-
5.2. Protocol and programming language independence
JSON Schema is agnostic with regards to both protocols and
@@ -295,23 +290,34 @@ Internet-Draft JSON Schema September 2012
instance to a schema over HTTP, which is the dominant protocol used
for Internet-enabled interactive applications.
-5.3. Keyword support and extension
+5.3. Integer numeric instances
+
+ It is acknowledged by this specification that programming language
+ support for numeric types vary. In particular, some programming
+ languages, and their associated parsers, yield different internal
+ representations for floating point numbers and integers, while others
+ do not.
+
+ As a consequence, for interoperability reasons, schema authors and
+ instance producers SHOULD ensure that integer numeric values be
+ written using their canonical mathematical representation.
+
+5.4. JSON Schema extension
Implementations MAY choose to 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.
- Implementations SHOULD ignore keywords they do not handle.
-
-5.4. Security considerations
+5.5. Security considerations
Both schemas and instances are JSON values. As such, all security
considerations defined in [RFC4627] apply.
JSON Schema does not define an internal security mechanism. It is up
- to applications to determine the level of trust placed into JSON
- values coming from external sources (whether this data be an instance
- or a schema), using any mechanism at their disposal.
+ to applications to determine the level of trust placed into JSON data
+ coming from external sources (whether this data be an instance or a
+ schema), using any mechanism at their disposal.
6. The "$schema" keyword
@@ -322,21 +328,20 @@ Internet-Draft JSON Schema September 2012
it defines the version of the schema which a particular JSON
Schema is valid against;
- it is a URI which is a location to a JSON Schema which validates
- any schema written for this version.
-
- Any of these schemas also validate themselves successfully.
-
-
-Galiegue, et al. Expires March 29, 2013 [Page 6]
+Galiegue Expires March 30, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
+ it is a URI which is a location to a JSON Schema which validates
+ any schema written for this version.
+
+ Any of these schemas also validate themselves successfully.
+
6.2. Valid values
The value of this keyword MUST be one of the following string values:
@@ -381,18 +386,16 @@ Internet-Draft JSON Schema September 2012
if "id" is present in the root schema, its value MAY be considered
to be the schema URI;
- otherwise, it is RECOMMENDED that implementations consider that
- the URI of the schema is either the empty URI, or a URN.
-
-
-
-Galiegue, et al. Expires March 29, 2013 [Page 7]
+Galiegue Expires March 30, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
+ otherwise, it is RECOMMENDED that implementations consider that
+ the URI of the schema is either the empty URI, or a URN.
+
7.3. Canonical addressing
Canonical addressing in JSON Schema is done using JSON Reference
@@ -436,19 +439,18 @@ Internet-Draft JSON Schema September 2012
Subschemas at the following URI-encoded JSON Pointer [json-pointer]s
(starting from the root schema) have the following URIs:
- # (document root) http://x.y.z/rootschema.json#
-
-
-Galiegue, et al. Expires March 29, 2013 [Page 8]
+Galiegue Expires March 30, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
+ # (document root) http://x.y.z/rootschema.json#
+
#/schema1 http://x.y.z/rootschema.json#foo
#/schema2 http://x.y.z/otherschema.json#
@@ -481,9 +483,9 @@ Internet-Draft JSON Schema September 2012
Inline addressing can produce canonical URIs which differ from the
canonical URI of the root schema. Implementations MAY choose, for
security reasons, to ignore inline addressing in such a situation,
- and always dereference such canonical URIs.
+ and fall back to canonical addressing.
- Dereferencing URIs may fail to complete, or may lead to content which
+ Dereferencing URIs MAY fail to complete, or MAY procude content which
is not a JSON Schema (another type of JSON value, or not a JSON
value). It is RECOMMENDED that JSON Schema processing be considered
a failure in such a situation.
@@ -496,15 +498,14 @@ Internet-Draft JSON Schema September 2012
Schemas. This correlation MAY be embodied within existing protocol
headers.
- In addition, if the protocol also carries media type information (by
-
-Galiegue, et al. Expires March 29, 2013 [Page 9]
+Galiegue Expires March 30, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
+ In addition, if the protocol also carries media type information (by
means, for instance, of a "Content-Type" header), an instance MUST be
one of "application/json" or any other subtype.
@@ -555,8 +556,7 @@ Internet-Draft JSON Schema September 2012
-
-Galiegue, et al. Expires March 29, 2013 [Page 10]
+Galiegue Expires March 30, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
@@ -612,31 +612,22 @@ Appendix A. ChangeLog
-Galiegue, et al. Expires March 29, 2013 [Page 11]
+Galiegue Expires March 30, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
-Authors' Addresses
+Author's Address
Francis Galiegue
EMail: fgaliegue@gmail.com
- Kris Zyp (editor)
- SitePen (USA)
- 530 Lytton Avenue
- Palo Alto, CA 94301
- USA
- Phone: +1 650 968 8787
- EMail: kris@sitepen.com
- Gary Court
- EMail: gary.court@gmail.com
@@ -668,5 +659,14 @@ Authors' Addresses
-Galiegue, et al. Expires March 29, 2013 [Page 12]
+
+
+
+
+
+
+
+
+
+Galiegue Expires March 30, 2013 [Page 12]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 0776932f..1d4f8416 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -21,25 +21,6 @@
-
- SitePen (USA)
-
-
- 530 Lytton Avenue
- Palo Alto, CA 94301
- USA
-
- +1 650 968 8787
- kris@sitepen.com
-
-
-
-
-
- gary.court@gmail.com
-
-
-
Internet Engineering Task ForceJSON
@@ -70,12 +51,8 @@
This document defines the core terminology used by JSON Schema. Other linked
specifications, which expand on a particular role of JSON Schema, will use that
- terminology.
-
-
-
- This document also defines the mechanisms used for JSON Schema identification and
- referencing.
+ terminology. This document also defines the mechanisms used for JSON Schema
+ identification and addressing.
@@ -140,7 +117,7 @@
JSON Schema defines seven primitive types for JSON values:
A JSON array.
- A JSON boolean (true or false).
+ A JSON boolean.A JSON number without a fraction or exponent part (see
RFC 4627, section 2.4).Any JSON number. Number includes integer.
@@ -151,30 +128,28 @@
-
+
- Two JSON values are said to be lexically equivalent if and only if:
+ Two JSON values are said to be equal if and only if:
both are nulls; orboth are booleans, and have the same value; or
- both are strings, and have the same lexical representation (see RFC 4627, section 2.5; or
- both are integers, and have the same lexical representation; or
- both are numbers, and have the same lexical representation (see RFC 4627, section 2.4); or
+ both are strings, and have the same value; or
+ both are integers, and have the same value; or
+ both are numbers, and have the same value; orboth are arrays, and:
have the same number of elements; and
- elements at the same index are lexically equivalent according to
- this definition; or
+ elements at the same index are equal according to this
+ definition; orboth are objects, and:
have the same set of members; and
- values for a same member are lexically equivalent according to
- this definition.
+ values for a same member are equal according to this
+ definition.
@@ -247,15 +222,27 @@
-
+
- Implementations MAY choose to define additional keywords to JSON Schema. Save
- for explicit agreement, schema authors SHALL NOT expect these additional
- keywords to be supported by peer implementations.
+ It is acknowledged by this specification that programming language support for
+ numeric types vary. In particular, some programming languages, and their
+ associated parsers, yield different internal representations for floating point
+ numbers and integers, while others do not.
- Implementations SHOULD ignore keywords they do not handle.
+ As a consequence, for interoperability reasons, schema authors and instance
+ producers SHOULD ensure that integer numeric values be written using their
+ canonical mathematical representation.
+
+
+
+
+
+ Implementations MAY choose to 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.
@@ -267,7 +254,7 @@
JSON Schema does not define an internal security mechanism. It is up to
- applications to determine the level of trust placed into JSON values coming from
+ applications to determine the level of trust placed into JSON data coming from
external sources (whether this data be an instance or a schema), using any
mechanism at their disposal.
@@ -377,8 +364,9 @@
This schema will be taken as an example:
-
+
Inline addressing can produce canonical URIs which differ from the canonical URI
of the root schema. Implementations MAY choose, for security reasons, to ignore
- inline addressing in such a situation, and always dereference such canonical
- URIs.
+ inline addressing in such a situation, and fall back to canonical addressing.
- Dereferencing URIs may fail to complete, or may lead to content which is not a
+ Dereferencing URIs MAY fail to complete, or MAY procude content which is not a
JSON Schema (another type of JSON value, or not a JSON value). It is RECOMMENDED
that JSON Schema processing be considered a failure in such a situation.
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index e4f3cb70..6293b150 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -2,9 +2,9 @@
Internet Engineering Task Force fge. Galiegue
-Internet-Draft September 25, 2012
+Internet-Draft September 26, 2012
Intended status: Informational
-Expires: March 29, 2013
+Expires: March 30, 2013
JSON Schema: interactive and non interactive validation
@@ -35,7 +35,7 @@ Status of This Memo
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 March 29, 2013.
+ This Internet-Draft will expire on March 30, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Galiegue Expires March 29, 2013 [Page 1]
+Galiegue Expires March 30, 2013 [Page 1]
Internet-Draft JSON Schema September 2012
@@ -108,7 +108,7 @@ Table of Contents
-Galiegue Expires March 29, 2013 [Page 2]
+Galiegue Expires March 30, 2013 [Page 2]
Internet-Draft JSON Schema September 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 3]
+Galiegue Expires March 30, 2013 [Page 3]
Internet-Draft JSON Schema September 2012
@@ -198,7 +198,7 @@ Internet-Draft JSON Schema September 2012
"b" ].
Elements in an array value are said to be unique if no two elements
- of this array are lexically equivalent, as defined in FIXME_LINK.
+ of this array are equal, as defined in FIXME_LINK.
3. Interoperability considerations
@@ -220,7 +220,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 4]
+Galiegue Expires March 30, 2013 [Page 4]
Internet-Draft JSON Schema September 2012
@@ -276,7 +276,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 5]
+Galiegue Expires March 30, 2013 [Page 5]
Internet-Draft JSON Schema September 2012
@@ -332,7 +332,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 6]
+Galiegue Expires March 30, 2013 [Page 6]
Internet-Draft JSON Schema September 2012
@@ -388,7 +388,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 7]
+Galiegue Expires March 30, 2013 [Page 7]
Internet-Draft JSON Schema September 2012
@@ -444,7 +444,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 8]
+Galiegue Expires March 30, 2013 [Page 8]
Internet-Draft JSON Schema September 2012
@@ -500,7 +500,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 9]
+Galiegue Expires March 30, 2013 [Page 9]
Internet-Draft JSON Schema September 2012
@@ -556,7 +556,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 10]
+Galiegue Expires March 30, 2013 [Page 10]
Internet-Draft JSON Schema September 2012
@@ -612,7 +612,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 11]
+Galiegue Expires March 30, 2013 [Page 11]
Internet-Draft JSON Schema September 2012
@@ -668,7 +668,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 12]
+Galiegue Expires March 30, 2013 [Page 12]
Internet-Draft JSON Schema September 2012
@@ -724,7 +724,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 13]
+Galiegue Expires March 30, 2013 [Page 13]
Internet-Draft JSON Schema September 2012
@@ -780,7 +780,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 14]
+Galiegue Expires March 30, 2013 [Page 14]
Internet-Draft JSON Schema September 2012
@@ -808,8 +808,8 @@ Internet-Draft JSON Schema September 2012
5.5.1.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
- if its value is lexically equivalent to one of the elements in this
- keyword's array value.
+ if its value is equal to one of the elements in this keyword's array
+ value.
5.5.2. type
@@ -836,7 +836,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 15]
+Galiegue Expires March 30, 2013 [Page 15]
Internet-Draft JSON Schema September 2012
@@ -892,7 +892,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 16]
+Galiegue Expires March 30, 2013 [Page 16]
Internet-Draft JSON Schema September 2012
@@ -948,7 +948,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 17]
+Galiegue Expires March 30, 2013 [Page 17]
Internet-Draft JSON Schema September 2012
@@ -1004,7 +1004,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 18]
+Galiegue Expires March 30, 2013 [Page 18]
Internet-Draft JSON Schema September 2012
@@ -1060,7 +1060,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 19]
+Galiegue Expires March 30, 2013 [Page 19]
Internet-Draft JSON Schema September 2012
@@ -1116,7 +1116,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 20]
+Galiegue Expires March 30, 2013 [Page 20]
Internet-Draft JSON Schema September 2012
@@ -1172,7 +1172,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 21]
+Galiegue Expires March 30, 2013 [Page 21]
Internet-Draft JSON Schema September 2012
@@ -1228,7 +1228,7 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 29, 2013 [Page 22]
+Galiegue Expires March 30, 2013 [Page 22]
Internet-Draft JSON Schema September 2012
@@ -1284,5 +1284,5 @@ Author's Address
-Galiegue Expires March 29, 2013 [Page 23]
+Galiegue Expires March 30, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index 8e15b350..ff0cf033 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -84,7 +84,7 @@
Elements in an array value are said to be unique if no two elements of this array
- are lexically equivalent, as defined in FIXME_LINK.
+ are equal, as defined in FIXME_LINK.
@@ -809,8 +809,7 @@
An instance validates successfully against this keyword if and only if
- its value is lexically equivalent to one of the elements in this
- keyword's array value.
+ its value is equal to one of the elements in this keyword's array value.
From 567a70c456b610addcd4c37af28bf45cfb795629 Mon Sep 17 00:00:00 2001
From: "user@server"
Date: Wed, 26 Sep 2012 22:55:11 +0100
Subject: [PATCH 0123/1659] Added hypermedia specification
---
proposals/json-schema-hypermedia.html | 1213 ++++++++++++++++++++++++
proposals/json-schema-hypermedia.txt | 1232 +++++++++++++++++++++++++
proposals/json-schema-hypermedia.xml | 838 +++++++++++++++++
3 files changed, 3283 insertions(+)
create mode 100644 proposals/json-schema-hypermedia.html
create mode 100644 proposals/json-schema-hypermedia.txt
create mode 100644 proposals/json-schema-hypermedia.xml
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
new file mode 100644
index 00000000..718d19bc
--- /dev/null
+++ b/proposals/json-schema-hypermedia.html
@@ -0,0 +1,1213 @@
+
+Hyperlinks and media for JSON Schema
+
+
+
+
+
+
+
+
Hyperlinks and media for JSON Schema draft-zyp-json-hyper-schema-04
+
+
Abstract
+
+
+ JSON Schema is a JSON based format for defining the structure of JSON data.
+ This document specifies hyperlink- and hypermedia-related keywords for the JSON Schema format.
+
+
+
Status of This Memo
+
+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 March 30, 2013.
+
+
Copyright Notice
+
+Copyright (c) 2012 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.
+
+
Table of Contents
+
+1.
+Introduction
+2.
+Conventions and Terminology
+3.
+Overview
+ 3.1.
+Design Considerations
+4.
+Keywords
+ 4.1.
+links
+ 4.1.1.
+Link Description Object
+ 4.2.
+fragmentResolution
+ 4.2.1.
+json-pointer fragment resolution
+ 4.3.
+media
+ 4.3.1.
+contentEncoding
+ 4.3.2.
+mediaType
+ 4.4.
+pathStart
+5.
+Security Considerations
+ 5.1.
+"self" links
+ 5.2.
+"mediaType" property of Link Description Objects
+ 5.3.
+"targetSchema" property of Link Description Objects
+ 5.4.
+"invalidates" property of Link Description Objects
+6.
+IANA Considerations
+ 6.1.
+Registry of Link Relations
+7.
+References
+ 7.1.
+Normative References
+ 7.2.
+Informative References
+Appendix A.
+Change Log
+
+ JSON Schema is a JSON based format for defining the structure of JSON data.
+ This document specifies hyperlink- and hypermedia-related keywords for the JSON Schema format.
+
+
+ JSON Schema defines the media type "application/schema+json".
+ JSON Schemas are also written in JSON and include facilities for describing the structure of JSON data in terms of allowable values, descriptions, and interpreting relations with other resources.
+
+
+
+ This document describes how JSON Schema can be used to define hyperlinks on instance data, and to define how to interpret JSON data as rich multimedia documents.
+
+
+
+ Just as with the core JSON schema attributes, all the attributes described here are optional.
+ Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
+ Addition of attributes provides additive information for user agents.
+
+
+
An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
+
+ This schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property.
+ It also defines link relations for the instance, with URIs incorporating values from the instance.
+
+
+ In addition to the design considerations for the core JSON Schema specification:
+
+
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the semantics of the client-server interface, the retrieval of resource representations linked to by JSON representations, and modification of those resources.
+ The goal of this format is to sufficiently describe JSON structures such that one can utilize existing information available in existing JSON representations from a large variety of services that leverage a representational state transfer architecture using existing protocols.
+
+
+ The property of schemas is used to associate Link Description Options with instances. The value of this property MUST be an array, and the items in the array must be Link Description Objects, as defined below.
+
+
+
An example schema using the links keywords could be:
+
+ A link description object is used to describe link relations.
+ In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
+ The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
+ The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
+
+
+ The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] and MAY be a relative URI.
+ The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
+ Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
+ Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
+ The property name between the braces SHOULD be percent encoded (FIXME reference?).
+ In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
+
+
+
For example, if an href value is defined:
+
+
+http://somesite.com/{id}
+
+
+
Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+
+
+
If the value of the "id" property was "45", the expanded URI would be:
+
+
+http://somesite.com/45
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
+
+
+
+
Values may only be used for substitution if they are of a scalar type (string, boolean or number).
+
+
In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
+
+ The value of the "rel" property indicates the name of the relation to the target resource.
+ The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
+ If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
+ A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287 (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287]).
+ However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
+
+
+
+
self
+
+ If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
+
+
+
full
+
+ This indicates that the target of the link is the full representation for the instance object.
+ The instance that contains this link may not be the full representation.
+
+
+
describedBy
+
+ This indicates the target of the link is a schema describing the instance object.
+ This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
root
+
+ This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
+ All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+
+
instances
+
+ This indicates the target resource that represents a collection of instances of a schema.
+
+
+
create
+
+ This indicates a target to use for creating new instances of a schema.
+ This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+
+ Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
+
+
+
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+
+
+
+ This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
+
+
+ This property is analogous to the "type" property of elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].
+ User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
+ When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
+
+
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+
+
+ A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
+
+
+
+ Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
+ The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
+
+
+ The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
+
+
+
+ If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href (href)" property.
+ Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
+
+
+
+ If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
+
+
+ The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
+
+
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
+
+ If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
+ The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
+
+
+
This indicates that the client can query the server for instances that have a specific name.
+
+
+
+
For example:
+
+
+/Product/?name=Slinky
+
+
+
+ If no encType or method is specified, only the single URI specified by the href property is defined.
+ If the method is POST, "application/json" is the default media type.
+
+
+
+
+ This attribute contains a schema which defines the acceptable structure of the submitted request.
+ For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
+
+
+ This property indicates the fragment resolution protocol to use for resolving fragment identifiers in URIs within the instance representations.
+ This applies to the instance object URIs and all children of the instance object's URIs.
+ The default fragment resolution protocol is "json-pointer", which is defined below.
+ Other fragment resolution protocols MAY be used, but are not defined in this document.
+
+
+ Note that if the instance is described by a schema providing the a link with "root" relation, or such a link is provided in using the HTTP Link header, then all fragment resolution should be resolved relative to the target of the root link.
+ The only exception to this is the resolution of "root" links themselves.
+
+
+ If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
+
+
+ When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
+ If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
+ Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
+
+
+ When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
+
+
+
+
+Content-Type: application/json; profile=/schema-for-this-data
+
+[{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+}, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+}, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+}]
+
+
5.2.
+"mediaType" property of Link Description Objects
+
+
+ The "mediaType" property in link definitions defines the expected format of the link's target.
+ However, this is advisory only, and MUST NOT be considered authoritative.
+ User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
+ If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
+
+
+
+ When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mimeType" property of the link MUST NOT be used.
+
+
+
+ This is to guard against situations where a source is providing data that is safe when interpreted as the correct type (for example plain text), but that could be damaging if a third party were allowed to provide a different interpretation (such as client-side code).
+
+
5.3.
+"targetSchema" property of Link Description Objects
+
+
+ Since, through the "media" keyword, schemas can provide interpretations of string data, exactly the same considerations apply for this keyword as for the "mediaType" keyword of Link Description Objects.
+
+
5.4.
+"invalidates" property of Link Description Objects
+
+
+ User agents also MUST NOT fetch the target of a link when the resulting data is validated, unless the user has already explicitly or implicitly indicated them to do so.
+ If the user's intentions are not known, then the user agent SHOULD NOT refetch the data unless the target of the link is a sub-path of the URI being invalidated.
+ (See above for a discussion of how to determine if one path is a sub-path of another.)
+
+
+
+ This is to guard against the possibility of tricking user agents into making requests on behalf of the user, to track their behaviour.
+
+
The proposed MIME media type for JSON Schema is "application/schema+json".
+
+
Type name: application
+
+
Subtype name: schema+json
+
+
Required parameters: profile
+
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that refers to the schema used to define the structure of this structure (the meta-schema).
+ Normally the value would be http://json-schema.org/draft-04/hyper-schema, but it is allowable to use other schemas that extend the hyper schema's meta-schema.
+
+
+
Optional parameters: pretty
+
+
The value of the pretty parameter MAY be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” draft-gregorio-uritemplate-08 (work in progress), January 2012 (TXT).
+
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
new file mode 100644
index 00000000..358e36cb
--- /dev/null
+++ b/proposals/json-schema-hypermedia.txt
@@ -0,0 +1,1232 @@
+
+
+
+Internet Engineering Task Force K. Zyp, Ed.
+Internet-Draft SitePen (USA)
+Intended status: Informational G. Court
+Expires: March 30, 2013 G. Luff
+ September 26, 2012
+
+
+ Hyperlinks and media for JSON Schema
+ draft-zyp-json-hyper-schema-04
+
+Abstract
+
+ JSON Schema is a JSON based format for defining the structure of JSON
+ data. This document specifies hyperlink- and hypermedia-related
+ keywords for the JSON Schema format.
+
+Status of This Memo
+
+ 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 March 30, 2013.
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 1]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
+ 4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1.1. Link Description Object . . . . . . . . . . . . . . . 6
+ 4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 12
+ 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 13
+ 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 13
+ 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 5.1. "self" links . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.2. "mediaType" property of Link Description Objects . . . . . 16
+ 5.3. "targetSchema" property of Link Description Objects . . . 16
+ 5.4. "invalidates" property of Link Description Objects . . . . 17
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 17
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 2]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+1. Introduction
+
+ JSON Schema is a JSON based format for defining the structure of JSON
+ data. This document specifies hyperlink- and hypermedia-related
+ keywords for the JSON Schema format.
+
+2. Conventions and Terminology
+
+ 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].
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element",
+ "object", "array", "number", "string", "boolean", "true", "false",
+ and "null" in this document are to be interpreted as defined in RFC
+ 4627 [RFC4627].
+
+ This specification also uses the following defined terms:
+
+ schema A JSON Schema object.
+
+ instance Equivalent to "JSON value" as defined in RFC 4627
+ [RFC4627].
+
+ property Equivalent to "member" as defined in RFC 4627 [RFC4627].
+
+ item Equivalent to "element" as defined in RFC 4627 [RFC4627].
+
+ attribute A property of a JSON Schema object.
+
+3. Overview
+
+ JSON Schema defines the media type "application/schema+json". JSON
+ Schemas are also written in JSON and include facilities for
+ describing the structure of JSON data in terms of allowable values,
+ descriptions, and interpreting relations with other resources.
+
+ This document describes how JSON Schema can be used to define
+ hyperlinks on instance data, and to define how to interpret JSON data
+ as rich multimedia documents.
+
+ Just as with the core JSON schema attributes, all the attributes
+ described here are optional. Therefore, an empty object is a valid
+ (non-informative) schema, and essentially describes plain JSON.
+ Addition of attributes provides additive information for user agents.
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 3]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ An example JSON Schema defining hyperlinks, and providing hypermedia
+ interpretation for one of the properties is:
+
+
+ {
+ "title": "Written Article",
+ "properties": {
+ "id": {
+ "title": "Article Identifier",
+ "type": "number"
+ },
+ "title": {
+ "title": "Article Title",
+ "type": "string"
+ },
+ "author": {
+ "type": "integer"
+ },
+ "imgData": {
+ "title": "Article Illustration (small)",
+ "type": "string",
+ "media": {
+ "contentEncoding": "base64",
+ "mediaType": "image/png"
+ }
+ }
+ },
+ "required" : ["id", "title", "author"],
+ "links": [
+ {
+ "rel": "full",
+ "href": "{id}"
+ },
+ {
+ "rel": "author",
+ "href": "/user?id={author}"
+ }
+ ]
+ }
+
+
+ This schema defines the properties of the instance, as well as a
+ hypermedia interpretation for the "imgData" property. It also
+ defines link relations for the instance, with URIs incorporating
+ values from the instance.
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 4]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+3.1. Design Considerations
+
+ In addition to the design considerations for the core JSON Schema
+ specification:
+
+ This specification is protocol agnostic. The underlying protocol
+ (such as HTTP) should sufficiently define the semantics of the
+ client-server interface, the retrieval of resource representations
+ linked to by JSON representations, and modification of those
+ resources. The goal of this format is to sufficiently describe JSON
+ structures such that one can utilize existing information available
+ in existing JSON representations from a large variety of services
+ that leverage a representational state transfer architecture using
+ existing protocols.
+
+4. Keywords
+
+ The following properties are defined for JSON Schema objects:
+
+4.1. links
+
+ The property of schemas is used to associate Link Description Options
+ with instances. The value of this property MUST be an array, and the
+ items in the array must be Link Description Objects, as defined
+ below.
+
+ An example schema using the links keywords could be:
+
+
+ {
+ "title": "Schema defining links",
+ "links": [
+ {
+ "rel": "full",
+ "href": "{id}"
+ },
+ {
+ "rel": "parent",
+ "href": "{parent}"
+ }
+ ]
+ }
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 5]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+4.1.1. Link Description Object
+
+ A link description object is used to describe link relations. In the
+ context of a schema, it defines the link relations of the instances
+ of the schema, and can be parameterized by the instance values. The
+ link description format can be used without JSON Schema, and use of
+ this format can be declared by referencing the normative link
+ description schema as the schema for the data structure that uses the
+ links. The URI of the normative link description schema is:
+ http://json-schema.org/links (latest version) or
+ http://json-schema.org/draft-04/links (draft-04 version).
+
+4.1.1.1. href
+
+ The value of the "href" link description property indicates the
+ target URI of the related resource. The value of the instance
+ property SHOULD be resolved as a URI-Reference per RFC 3986 [RFC3986]
+ and MAY be a relative URI. The base URI to be used for relative
+ resolution SHOULD be the URI used to retrieve the instance object
+ (not the schema) when used within a schema. Also, when links are
+ used within a schema, the URI SHOULD be parametrized by the property
+ values of the instance object, if property values exist for the
+ corresponding variables in the template (otherwise they MAY be
+ provided from alternate sources, like user input).
+
+ Instance property values SHOULD be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute. The property name between the braces SHOULD be percent
+ encoded (FIXME reference?). In particular, the character for the
+ braces ('{' and '}') as well as the percent sign ('%') MUST be
+ encoded, such that decoding the text obtains the correct property
+ name.
+
+ For example, if an href value is defined:
+
+
+ http://somesite.com/{id}
+
+
+ Then it would be resolved by replace the value of the "id" property
+ value from the instance object.
+
+ If the value of the "id" property was "45", the expanded URI would
+ be:
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 6]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ http://somesite.com/45
+
+
+ If matching braces are found with the string "@" (no quotes) between
+ the braces, then the actual instance value SHOULD be used to replace
+ the braces, rather than a property value.
+
+4.1.1.1.1. Missing values
+
+ Values may only be used for substitution if they are of a scalar type
+ (string, boolean or number).
+
+ In cases where suitable values do not exist for substitution because
+ they are of an incorrect type, then they should be treated as if the
+ values were missing, and substitute values MAY be provided from
+ alternate sources, like user input.
+
+4.1.1.2. rel
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target SHOULD be
+ interpreted as specifically from the instance object that the schema
+ (or sub-schema) applies to, not just the top level resource that
+ contains the object within its hierarchy. If a resource JSON
+ representation contains a sub object with a property interpreted as a
+ link, that sub-object holds the relation with the target. A link
+ relation from the top level resource to a target MUST be indicated
+ with the schema describing the top level JSON representation.
+
+ Relationship definitions SHOULD NOT be media type dependent, and
+ users are encouraged to utilize existing accepted relation
+ definitions, including those in existing relation registries (see RFC
+ 4287 [RFC4287]). However, we define these relations here for clarity
+ of normative interpretation within the context of JSON Schema defined
+ relations:
+
+ self If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the specified
+ URI.
+
+ full This indicates that the target of the link is the full
+ representation for the instance object. The instance that
+ contains this link may not be the full representation.
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 7]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ describedBy This indicates the target of the link is a schema
+ describing the instance object. This MAY be used to specifically
+ denote the schemas of objects within a JSON object hierarchy,
+ facilitating polymorphic type data structures.
+
+ root This relation indicates that the target of the link SHOULD be
+ treated as the root or the body of the representation for the
+ purposes of user agent interaction or fragment resolution. All
+ other properties of the instance objects can be regarded as meta-
+ data descriptions for the data.
+
+ The following relations are applicable for schemas (the schema as the
+ "from" resource in the relation):
+
+ instances This indicates the target resource that represents a
+ collection of instances of a schema.
+
+ create This indicates a target to use for creating new instances of
+ a schema. This link definition SHOULD be a submission link with a
+ non-safe method (like POST).
+
+ Links defined in the schema using these relation values SHOULD not
+ require parameterization with data from the instance, as they
+ describe a link for the schema, not the instances.
+
+ For example, if a schema is defined:
+
+
+ {
+ "links": [{
+ "rel": "self",
+ "href": "{id}"
+ }, {
+ "rel": "up",
+ "href": "{upId}"
+ }, {
+ "rel": "children",
+ "href": "?upId={id}"
+ }]
+ }
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 8]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ And if a collection of instance resources were retrieved with JSON
+ representation:
+
+
+ GET /Resource/
+
+ [{
+ "id": "thing",
+ "upId": "parent"
+ }, {
+ "id": "thing2",
+ "upId": "parent"
+ }]
+
+
+ This would indicate that for the first item in the collection, its
+ own (self) URI would resolve to "/Resource/thing" and the first
+ item's "up" relation SHOULD be resolved to the resource at
+ "/Resource/parent". The "children" collection would be located at
+ "/Resource/?upId=thing".
+
+ Note that these relationship values are case-insensitive, consistent
+ with their use in HTML and the HTTP Link header
+ [I-D.nottingham-http-link-header].
+
+4.1.1.3. template
+
+ This property value is a string that defines the templating language
+ used in the "href" (Section 4.1.1.1) attribute. If no templating
+ language is defined, then the default Link Description Object
+ templating language (Section 4.1.1.1) is used.
+
+4.1.1.4. targetSchema
+
+ This property value is advisory only, and is a schema that defines
+ the expected structure of the JSON representation of the target of
+ the link, if the target of the link is returned using JSON
+ representation.
+
+4.1.1.5. mediaType
+
+ The value of this property is advisory only, and represents the media
+ type RFC 2046 [RFC2046], that is expected to be returned when
+ fetching this resource. This property value MAY be a media range
+ instead, using the same pattern defined in RFC 2161, section 14.1 -
+ HTTP "Accept" header [RFC2616].
+
+ This property is analogous to the "type" property of elements in HTML
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 9]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ 4.01 (advisory content type), or the "type" parameter in the HTTP
+ Link header [I-D.nottingham-http-link-header]. User agents MAY use
+ this information to inform the interface they present to the user
+ before the link is followed, but this information MUST NOT use this
+ information in the interpretation of the resulting data. When
+ deciding how to interpret data obtained through following this link,
+ the behaviour of user agents MUST be identical regardless of the
+ value of the this property.
+
+ If this property's value is specified, and the link's target is to be
+ obtained using any protocol that supports the HTTP/1.1 "Accept"
+ header RFC 2616, section 14.1 [RFC2616], then user agents MAY use the
+ value of this property to aid in the assembly of that header when
+ making the request to the server.
+
+ If this property's value is not specified, then the value should be
+ taken to be "application/json".
+
+ For example, if a schema is defined:
+
+
+ {
+ "links": [{
+ "rel": "self",
+ "href": "/{id}/json"
+ }, {
+ "rel": "alternate",
+ "href": "/{id}/html",
+ "mimeType": "text/html"
+ }, {
+ "rel": "alternate",
+ "href": "/{id}/rss",
+ "mimeType": "application/rss+xml"
+ }, {
+ "rel": "icon",
+ "href": "{id}/icon",
+ "mimeType": "image/*"
+ }]
+ }
+
+
+ A suitable instance described by this schema would have four links
+ defined. The link with a "rel" value of "self" would have an
+ expected MIME type of "application/json" (the default). The two
+ links with a "rel" value of "alternate" specify the locations of HTML
+ and RSS versions of the current item. The link with a "rel" value of
+ "icon" links to an image, but does not specify the exact format.
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 10]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ A visual user agent displaying the item from the above example might
+ present a button representing an RSS feed, which when pressed passes
+ the target URI (calculated "href" value) to an view more suited to
+ displaying it, such as a news feed aggregator tab.
+
+ Note that presenting the link in the above manner, or passing the URI
+ to a news feed aggregator view does not constitute interpretation of
+ the data, but an interpretation of the link. The interpretation of
+ the data itself is performed by the news feed aggregator, which
+ SHOULD reject any data that would not have also been interpreted as a
+ news feed, had it been displayed in the main view.
+
+4.1.1.6. invalidates
+
+ The value of this property is advisory only, and represents a URI or
+ set of URIs which may change in response to this link being followed.
+ Its value must be either a string or an array.
+
+ If this property value is a string, then when the link is followed,
+ this value should be filled out as a template and resolved to a full
+ URI using the same method as used for the "href (Section 4.1.1.1)"
+ property. Any stored data fetched from a URI matching this value MAY
+ then be considered out-of-date by the client, and removed from any
+ cache.
+
+ If this property is an array, then its entries MUST be strings, each
+ of which is treated according to the above behaviour.
+
+4.1.1.7. Submission Link Properties
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means
+ for submitting extra (often user supplied) information to send to a
+ server.
+
+4.1.1.7.1. method
+
+ This attribute defines which method can be used to access the target
+ resource. In an HTTP environment, this could be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+4.1.1.7.2. encType
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 11]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method).
+
+ For example, with the following schema:
+
+
+ {
+ "links": [{
+ "encType": "application/x-www-form-urlencoded",
+ "method": "GET",
+ "href": "/Product/",
+ "properties": {
+ "name": {
+ "description": "name of the product"
+ }
+ }
+ }]
+ }
+
+
+ This indicates that the client can query the server for instances
+ that have a specific name.
+
+ For example:
+
+
+ /Product/?name=Slinky
+
+
+ If no encType or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST,
+ "application/json" is the default media type.
+
+4.1.1.7.3. schema
+
+ This attribute contains a schema which defines the acceptable
+ structure of the submitted request. For a GET request, this schema
+ would define the properties for the query string and for a POST
+ request, this would define the body.
+
+4.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "json-pointer", which is defined below. Other
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 12]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ fragment resolution protocols MAY be used, but are not defined in
+ this document.
+
+ The fragment identifier is based on RFC 3986, Sec 5 [RFC3986], and
+ defines the mechanism for resolving references to entities within a
+ document.
+
+ Note that if the instance is described by a schema providing the a
+ link with "root" relation, or such a link is provided in using the
+ HTTP Link header, then all fragment resolution should be resolved
+ relative to the target of the root link. The only exception to this
+ is the resolution of "root" links themselves.
+
+4.2.1. json-pointer fragment resolution
+
+ The "json-pointer" fragment resolution protocol uses a JSON Pointer
+ [json-pointer] to resolve fragment identifiers in URIs within
+ instance representations.
+
+4.3. media
+
+ The value of this attribute MUST be an object. It MAY contain any of
+ the following properties:
+
+4.3.1. contentEncoding
+
+ The value of this property SHOULD be ignored for any instance that is
+ not a string. If the instance value is a string, this attribute
+ defines that the string SHOULD be interpreted as binary data and
+ decoded using the encoding named by this property. RFC 2045, Sec 6.1
+ [RFC2045] lists the possible values for this property.
+
+4.3.2. mediaType
+
+ The value of this property must be a media type RFC 2046 [RFC2046].
+ This attribute defines the media type of instances which this schema
+ defines.
+
+ If the "contentEncoding" property is not set, but the instance value
+ is a string, then the value of this property SHOULD specify a text
+ document, and the character set SHOULD be considered to be UTF-8.
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 13]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ For example:
+
+
+ {
+ "type": "string",
+ "media": {
+ "contentEncoding": "base64",
+ "mediaType": "image/png"
+ }
+ }
+
+
+ Instances described by this schema should be strings, and their
+ values should be interpretable as base64-encoded PNG images.
+
+ Another example:
+
+
+ {
+ "type": "string",
+ "media": {
+ "mediaType": "text/html"
+ }
+ }
+
+
+ Instances described by this schema should be strings containing HTML,
+ using the UTF-8 character set.
+
+4.4. pathStart
+
+ This attribute is a URI that defines what the instance's URI MUST
+ start with in order to validate. The value of the "pathStart"
+ attribute MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
+ relative to the instance's URI.
+
+ When multiple schemas have been referenced for an instance, the user
+ agent can determine if this schema is applicable for a particular
+ instance by determining if the URI of the instance begins with the
+ the value of the "pathStart" attribute. If the URI of the instance
+ does not start with this URI, or if another schema specifies a
+ starting URI that is longer and also matches the instance, this
+ schema SHOULD NOT be considered to describe the instance. Any schema
+ that does not have a pathStart attribute SHOULD be considered
+ applicable to all the instances for which it is referenced.
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 14]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+5. Security Considerations
+
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627
+ [RFC4627]. However, there are additional security concerns when
+ using the hyperlink definitions.
+
+5.1. "self" links
+
+ When link relation of "self" is used to denote a full representation
+ of an object, the user agent SHOULD NOT consider the representation
+ to be the authoritative representation of the resource denoted by the
+ target URI if the target URI is not equivalent to or a sub-path of
+ the the URI used to request the resource representation which
+ contains the target URI with the "self" link.
+
+ For example, if a hyper schema was defined:
+
+
+ {
+ "links": [{
+ "rel": "self",
+ "href": "{id}"
+ }]
+ }
+
+
+ And a resource was requested from somesite.com:
+
+
+ GET /foo/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 15]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ With a response of:
+
+
+ Content-Type: application/json; profile=/schema-for-this-data
+
+ [{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+ }, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+ }, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+ }]
+
+
+5.2. "mediaType" property of Link Description Objects
+
+ The "mediaType" property in link definitions defines the expected
+ format of the link's target. However, this is advisory only, and
+ MUST NOT be considered authoritative. User agents MAY use this
+ information to determine how they represent the link or where to
+ display it (for example hover-text, opening in a new tab). If user
+ agents decide to pass the link to an external program, they SHOULD
+ first verify that the data is of a type that would normally be passed
+ to that external program.
+
+ When choosing how to interpret data, the type information provided by
+ the server (or inferred from the filename, or any other usual method)
+ MUST be the only consideration, and the "mimeType" property of the
+ link MUST NOT be used.
+
+ This is to guard against situations where a source is providing data
+ that is safe when interpreted as the correct type (for example plain
+ text), but that could be damaging if a third party were allowed to
+ provide a different interpretation (such as client-side code).
+
+5.3. "targetSchema" property of Link Description Objects
+
+ Since, through the "media" keyword, schemas can provide
+ interpretations of string data, exactly the same considerations apply
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 16]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ for this keyword as for the "mediaType" keyword of Link Description
+ Objects.
+
+5.4. "invalidates" property of Link Description Objects
+
+ User agents also MUST NOT fetch the target of a link when the
+ resulting data is validated, unless the user has already explicitly
+ or implicitly indicated them to do so. If the user's intentions are
+ not known, then the user agent SHOULD NOT refetch the data unless the
+ target of the link is a sub-path of the URI being invalidated. (See
+ above for a discussion of how to determine if one path is a sub-path
+ of another.)
+
+ This is to guard against the possibility of tricking user agents into
+ making requests on behalf of the user, to track their behaviour.
+
+6. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is "application/
+ schema+json".
+
+ Type name: application
+
+ Subtype name: schema+json
+
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or
+ absolute) that refers to the schema used to define the structure of
+ this structure (the meta-schema). Normally the value would be
+ http://json-schema.org/draft-04/hyper-schema, but it is allowable to
+ use other schemas that extend the hyper schema's meta-schema.
+
+ Optional parameters: pretty
+
+ The value of the pretty parameter MAY be true or false to indicate if
+ additional whitespace has been included to make the JSON
+ representation easier to read.
+
+6.1. Registry of Link Relations
+
+ This registry is maintained by IANA per RFC 4287 [RFC4287] and this
+ specification adds four values: "full", "create", "instances",
+ "root". New assignments are subject to IESG Approval, as outlined in
+ RFC 5226 [RFC5226]. Requests should be made by email to IANA, which
+ will then forward the request to the IESG, requesting approval.
+
+7. References
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 17]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+7.1. Normative References
+
+ [RFC2045] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format
+ of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in
+ RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman,
+ "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC4287] Nottingham, M., Ed. and R. Sayre,
+ Ed., "The Atom Syndication
+ Format", RFC 4287, December 2005.
+
+ [json-pointer] Bryan, P. and K. Zyp, "JSON
+ Pointer", October 2011, .
+
+7.2. Informative References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul,
+ J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC4627] Crockford, D., "The application/
+ json Media Type for JavaScript
+ Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand,
+ "Guidelines for Writing an IANA
+ Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 18]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ [RFC2046] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media
+ Types", RFC 2046, November 1996.
+
+ [I-D.hammer-discovery] Hammer-Lahav, E., "LRDD: Link-
+ based Resource Descriptor
+ Discovery",
+ draft-hammer-discovery-06 (work in
+ progress), May 2010.
+
+ [I-D.gregorio-uritemplate] Gregorio, J., Fielding, R.,
+ Hadley, M., Nottingham, M., and D.
+ Orchard, "URI Template",
+ draft-gregorio-uritemplate-08
+ (work in progress), January 2012.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-10
+ (work in progress), May 2010.
+
+ [W3C.REC-html401-19991224] Hors, A., Raggett, D., and I.
+ Jacobs, "HTML 4.01 Specification",
+ World Wide Web Consortium Recommen
+ dation REC-html401-19991224,
+ December 1999, .
+
+ [W3C.CR-CSS21-20070719] Hickson, I., Lie, H., Celik, T.,
+ and B. Bos, "Cascading Style
+ Sheets Level 2 Revision 1 (CSS
+ 2.1) Specification", World Wide
+ Web Consortium CR CR-CSS21-
+ 20070719, July 2007, .
+
+Appendix A. Change Log
+
+ draft-04
+
+ * Split hyper-schema definition out from main schema.
+
+ * Removed "readonly"
+
+ * Capitalised the T in "encType"
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 19]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ * Moved "mediaType" and "contentEncoding" to the new "media"
+ property
+
+ * Added "mediaType" property to LDOs
+
+ * Added "invalidates" property to LDOs
+
+ * Replaced "slash-delimited" fragment resolution with "json-
+ pointer".
+
+ * Added "template" LDO attribute.
+
+ * Improved wording of sections.
+
+ draft-03
+
+ * Added example and verbiage to "extends" attribute.
+
+ * Defined slash-delimited to use a leading slash.
+
+ * Made "root" a relation instead of an attribute.
+
+ * Removed address values, and MIME media type from format to
+ reduce confusion (mediaType already exists, so it can be used
+ for MIME types).
+
+ * Added more explanation of nullability.
+
+ * Removed "alternate" attribute.
+
+ * Upper cased many normative usages of must, may, and should.
+
+ * Replaced the link submission "properties" attribute to "schema"
+ attribute.
+
+ * Replaced "optional" attribute with "required" attribute.
+
+ * Replaced "maximumCanEqual" attribute with "exclusiveMaximum"
+ attribute.
+
+ * Replaced "minimumCanEqual" attribute with "exclusiveMinimum"
+ attribute.
+
+ * Replaced "requires" attribute with "dependencies" attribute.
+
+ * Moved "contentEncoding" attribute to hyper schema.
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 20]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ * Added "additionalItems" attribute.
+
+ * Added "id" attribute.
+
+ * Switched self-referencing variable substitution from "-this" to
+ "@" to align with reserved characters in URI template.
+
+ * Added "patternProperties" attribute.
+
+ * Schema URIs are now namespace versioned.
+
+ * Added "$ref" and "$schema" attributes.
+
+ draft-02
+
+ * Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+
+ * Added slash-delimited fragment resolution protocol and made it
+ the default.
+
+ * Added language about using links outside of schemas by
+ referencing its normative URI.
+
+ * Added "uniqueItems" attribute.
+
+ * Added "targetSchema" attribute to link description object.
+
+ draft-01
+
+ * Fixed category and updates from template.
+
+ draft-00
+
+ * Initial draft.
+
+Authors' Addresses
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 21]
+
+Internet-Draft JSON Schema Media Type September 2012
+
+
+ Gary Court
+ Calgary, AB
+ Canada
+
+ EMail: gary.court@gmail.com
+
+
+ Geraint Luff
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires March 30, 2013 [Page 22]
+
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
new file mode 100644
index 00000000..22a8622f
--- /dev/null
+++ b/proposals/json-schema-hypermedia.xml
@@ -0,0 +1,838 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+ Hyperlinks and media for JSON Schema
+
+
+ SitePen (USA)
+
+
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ +1 650 968 8787
+ kris@sitepen.com
+
+
+
+
+
+
+
+ Calgary, AB
+ Canada
+
+ gary.court@gmail.com
+
+
+
+
+
+
+
+ Internet Engineering Task Force
+ JSON
+ Schema
+ JavaScript
+ Object
+ Notation
+ Hyper Schema
+ Hypermedia
+
+
+
+ JSON Schema is a JSON based format for defining the structure of JSON data.
+ This document specifies hyperlink- and hypermedia-related keywords for the JSON Schema format.
+
+
+
+
+
+
+
+ JSON Schema is a JSON based format for defining the structure of JSON data.
+ This document specifies hyperlink- and hypermedia-related keywords for the JSON Schema format.
+
+
+
+
+
+
+
+ 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.
+
+
+
+ The terms "JSON", "JSON text", "JSON value", "member", "element", "object", "array",
+ "number", "string", "boolean", "true", "false", and "null" in this document are to
+ be interpreted as defined in RFC 4627.
+
+
+
+ This specification also uses the following defined terms:
+
+
+ A JSON Schema object.
+ Equivalent to "JSON value" as defined in RFC 4627.
+ Equivalent to "member" as defined in RFC 4627.
+ Equivalent to "element" as defined in RFC 4627.
+ A property of a JSON Schema object.
+
+
+
+
+
+
+ JSON Schema defines the media type "application/schema+json".
+ JSON Schemas are also written in JSON and include facilities for describing the structure of JSON data in terms of allowable values, descriptions, and interpreting relations with other resources.
+
+
+ This document describes how JSON Schema can be used to define hyperlinks on instance data, and to define how to interpret JSON data as rich multimedia documents.
+
+
+ Just as with the core JSON schema attributes, all the attributes described here are optional.
+ Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
+ Addition of attributes provides additive information for user agents.
+
+
+ An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
+
+
+
+
+ This schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property.
+ It also defines link relations for the instance, with URIs incorporating values from the instance.
+
+
+
+
+
+ In addition to the design considerations for the core JSON Schema specification:
+
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the semantics of the client-server interface, the retrieval of resource representations linked to by JSON representations, and modification of those resources.
+ The goal of this format is to sufficiently describe JSON structures such that one can utilize existing information available in existing JSON representations from a large variety of services that leverage a representational state transfer architecture using existing protocols.
+
+
+
+
+
+
+ The following properties are defined for JSON Schema objects:
+
+
+
+
+ The links property of schemas is used to associate Link Description Options with instances. The value of this property MUST be an array, and the items in the array must be Link Description Objects, as defined below.
+
+
+
+ An example schema using the links keywords could be:
+
+
+
+
+
+
+
+ A link description object is used to describe link relations.
+ In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
+ The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
+ The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
+
+
+
+
+ The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative URI.
+ The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
+ Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
+ Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
+ The property name between the braces SHOULD be percent encoded (FIXME reference?).
+ In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
+
+
+ For example, if an href value is defined:
+
+
+
+ Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+
+
+ If the value of the "id" property was "45", the expanded URI would be:
+
+
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
+
+
+ Values may only be used for substitution if they are of a scalar type (string, boolean or number).
+ In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
+
+
+
+
+
+ The value of the "rel" property indicates the name of the relation to the target resource.
+ The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
+ If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
+ A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287).
+ However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
+
+
+
+ If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
+
+
+
+ This indicates that the target of the link is the full representation for the instance object.
+ The instance that contains this link may not be the full representation.
+
+
+
+ This indicates the target of the link is a schema describing the instance object.
+ This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
+ This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
+ All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+
+ This indicates the target resource that represents a collection of instances of a schema.
+
+
+ This indicates a target to use for creating new instances of a schema.
+ This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+ Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
+
+
+
+
+ For example, if a schema is defined:
+
+
+
+
+
+
+ And if a collection of instance resources were retrieved with JSON representation:
+
+
+
+
+
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+
+ Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header.
+
+
+
+
+ This property value is a string that defines the templating language used in the "href" attribute.
+ If no templating language is defined, then the default Link Description Object templating language is used.
+
+
+
+
+
+ This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
+
+
+
+
+
+ The value of this property is advisory only, and represents the media type RFC 2046, that is expected to be returned when fetching this resource.
+ This property value MAY be a media range instead, using the same pattern defined in RFC 2161, section 14.1 - HTTP "Accept" header.
+
+
+
+ This property is analogous to the "type" property of <a elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header.
+ User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
+ When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
+
+
+
+ If this property's value is specified, and the link's target is to be obtained using any protocol that supports the HTTP/1.1 "Accept" header RFC 2616, section 14.1, then user agents MAY use the value of this property to aid in the assembly of that header when making the request to the server.
+
+
+
+ If this property's value is not specified, then the value should be taken to be "application/json".
+
+
+
+
+ For example, if a schema is defined:
+
+
+
+
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+
+
+ A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
+
+
+
+ Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
+ The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
+
+
+
+
+
+ The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
+
+
+
+ If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href" property.
+ Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
+
+
+
+ If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
+
+
+
+
+
+ The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
+
+
+
+
+ If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
+ The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
+
+
+ For example, with the following schema:
+
+
+
+ This indicates that the client can query the server for instances that have a specific name.
+
+
+
+ For example:
+
+
+
+
+
+ If no encType or method is specified, only the single URI specified by the href property is defined.
+ If the method is POST, "application/json" is the default media type.
+
+
+
+
+
+ This attribute contains a schema which defines the acceptable structure of the submitted request.
+ For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
+
+
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for resolving fragment identifiers in URIs within the instance representations.
+ This applies to the instance object URIs and all children of the instance object's URIs.
+ The default fragment resolution protocol is "json-pointer", which is defined below.
+ Other fragment resolution protocols MAY be used, but are not defined in this document.
+
+
+
+ The fragment identifier is based on RFC 3986, Sec 5, and defines the mechanism for resolving references to entities within a document.
+
+
+
+ Note that if the instance is described by a schema providing the a link with "root" relation, or such a link is provided in using the HTTP Link header, then all fragment resolution should be resolved relative to the target of the root link.
+ The only exception to this is the resolution of "root" links themselves.
+
+
+
+
+ The "json-pointer" fragment resolution protocol uses a JSON Pointer to resolve fragment identifiers in URIs within instance representations.
+
+
+
+
+
+
+ The value of this attribute MUST be an object. It MAY contain any of the following properties:
+
+
+
+
+ The value of this property SHOULD be ignored for any instance that is not a string.
+ If the instance value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
+ RFC 2045, Sec 6.1 lists the possible values for this property.
+
+
+
+
+
+ The value of this property must be a media type RFC 2046.
+ This attribute defines the media type of instances which this schema defines.
+
+
+
+ If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
+
+
+
+
+
+ For example:
+
+
+
+ Instances described by this schema should be strings, and their values should be interpretable as base64-encoded PNG images.
+
+
+
+ Another example:
+
+
+
+ Instances described by this schema should be strings containing HTML, using the UTF-8 character set.
+
+
+
+
+
+
+ This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
+ The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5, and is relative to the instance's URI.
+
+
+
+ When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
+ If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
+ Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
+
+
+
+
+
+
+ This specification is a sub-type of the JSON format, and consequently the security considerations are generally the same as RFC 4627.
+ However, there are additional security concerns when using the hyperlink definitions.
+
+
+
+
+ When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
+
+
+ For example, if a hyper schema was defined:
+
+
+
+
+
+
+ And a resource was requested from somesite.com:
+
+
+
+
+
+
+ With a response of:
+
+
+
+
+
+
+
+
+
+ The "mediaType" property in link definitions defines the expected format of the link's target.
+ However, this is advisory only, and MUST NOT be considered authoritative.
+ User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
+ If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
+
+
+
+ When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mimeType" property of the link MUST NOT be used.
+
+
+
+ This is to guard against situations where a source is providing data that is safe when interpreted as the correct type (for example plain text), but that could be damaging if a third party were allowed to provide a different interpretation (such as client-side code).
+
+
+
+
+
+ Since, through the "media" keyword, schemas can provide interpretations of string data, exactly the same considerations apply for this keyword as for the "mediaType" keyword of Link Description Objects.
+
+
+
+
+
+ User agents also MUST NOT fetch the target of a link when the resulting data is validated, unless the user has already explicitly or implicitly indicated them to do so.
+ If the user's intentions are not known, then the user agent SHOULD NOT refetch the data unless the target of the link is a sub-path of the URI being invalidated.
+ (See above for a discussion of how to determine if one path is a sub-path of another.)
+
+
+
+ This is to guard against the possibility of tricking user agents into making requests on behalf of the user, to track their behaviour.
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is "application/schema+json".
+ Type name: application
+ Subtype name: schema+json
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or absolute) that refers to the schema used to define the structure of this structure (the meta-schema).
+ Normally the value would be http://json-schema.org/draft-04/hyper-schema, but it is allowable to use other schemas that extend the hyper schema's meta-schema.
+
+ Optional parameters: pretty
+ The value of the pretty parameter MAY be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+ This registry is maintained by IANA per RFC 4287 and this specification adds four values: "full", "create", "instances", "root".
+ New assignments are subject to IESG Approval, as outlined in RFC 5226.
+ Requests should be made by email to IANA, which will then forward the request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+ &rfc2045;
+ &rfc2119;
+ &rfc3339;
+ &rfc3986;
+ &rfc4287;
+
+
+ JSON Pointer
+
+ ForgeRock US, Inc.
+
+
+ SitePen (USA)
+
+
+
+
+
+
+ &rfc2616;
+ &rfc4627;
+ &rfc5226;
+ &rfc2046;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+ &css21;
+
+
+
+
+
+
+
+ Split hyper-schema definition out from main schema.
+ Removed "readonly"
+ Capitalised the T in "encType"
+ Moved "mediaType" and "contentEncoding" to the new "media" property
+ Added "mediaType" property to LDOs
+ Added "invalidates" property to LDOs
+ Replaced "slash-delimited" fragment resolution with
+ "json-pointer".
+ Added "template" LDO attribute.
+ Improved wording of sections.
+
+
+
+
+
+ Added example and verbiage to "extends" attribute.
+ Defined slash-delimited to use a leading slash.
+ Made "root" a relation instead of an attribute.
+ Removed address values, and MIME media type from format to reduce
+ confusion (mediaType already exists, so it can be used for MIME
+ types).
+ Added more explanation of nullability.
+ Removed "alternate" attribute.
+ Upper cased many normative usages of must, may, and should.
+ Replaced the link submission "properties" attribute to "schema"
+ attribute.
+ Replaced "optional" attribute with "required" attribute.
+ Replaced "maximumCanEqual" attribute with "exclusiveMaximum"
+ attribute.
+ Replaced "minimumCanEqual" attribute with "exclusiveMinimum"
+ attribute.
+ Replaced "requires" attribute with "dependencies" attribute.
+ Moved "contentEncoding" attribute to hyper schema.
+ Added "additionalItems" attribute.
+ Added "id" attribute.
+ Switched self-referencing variable substitution from "-this" to "@"
+ to align with reserved characters in URI template.
+ Added "patternProperties" attribute.
+ Schema URIs are now namespace versioned.
+ Added "$ref" and "$schema" attributes.
+
+
+
+
+
+ Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+ Added slash-delimited fragment resolution protocol and made it the
+ default.
+ Added language about using links outside of schemas by referencing
+ its normative URI.
+ Added "uniqueItems" attribute.
+ Added "targetSchema" attribute to link description object.
+
+
+
+
+
+ Fixed category and updates from template.
+
+
+
+
+
+ Initial draft.
+
+
+
+
+
+
+
From af848abac233a0ed9497ac96c39eb6b563151690 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Sat, 15 Dec 2012 20:10:10 +0100
Subject: [PATCH 0124/1659] Changes to json-schema-core
* Reintroduce "property" and "item" definition.
* The Link header is defined by RFC 5988, add link.
* Some wording changes for "$schema".
---
proposals/json-schema-core.txt | 354 ++++++++++++++++-----------------
proposals/json-schema-core.xml | 135 +++++++------
2 files changed, 249 insertions(+), 240 deletions(-)
diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt
index b5796846..d1481423 100644
--- a/proposals/json-schema-core.txt
+++ b/proposals/json-schema-core.txt
@@ -2,9 +2,9 @@
Internet Engineering Task Force fge. Galiegue
-Internet-Draft September 26, 2012
+Internet-Draft November 23, 2012
Intended status: Informational
-Expires: March 30, 2013
+Expires: May 27, 2013
JSON Schema: core definitions and purposes
@@ -34,7 +34,7 @@ Status of This Memo
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 March 30, 2013.
+ This Internet-Draft will expire on May 27, 2013.
Copyright Notice
@@ -52,9 +52,9 @@ Copyright Notice
-Galiegue Expires March 30, 2013 [Page 1]
+Galiegue Expires May 27, 2013 [Page 1]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema November 2012
described in the Simplified BSD License.
@@ -64,42 +64,42 @@ Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3
- 3.1. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
- 3.2. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
- 3.3. JSON Schema primitive types . . . . . . . . . . . . . . . 4
- 3.4. JSON value equality . . . . . . . . . . . . . . . . . . . 4
- 3.5. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Property, item . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3
+ 3.3. Root schema, subschema . . . . . . . . . . . . . . . . . . 3
+ 3.4. JSON Schema primitive types . . . . . . . . . . . . . . . 4
+ 3.5. JSON value equality . . . . . . . . . . . . . . . . . . . 4
+ 3.6. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5
- 4.2. Hypermedia and linking . . . . . . . . . . . . . . . . . . 5
- 5. General considerations . . . . . . . . . . . . . . . . . . . . 5
- 5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Hypermedia and linking . . . . . . . . . . . . . . . . . . 6
+ 5. General considerations . . . . . . . . . . . . . . . . . . . . 6
+ 5.1. Valid instances . . . . . . . . . . . . . . . . . . . . . 6
5.2. Protocol and programming language independence . . . . . . 6
5.3. Integer numeric instances . . . . . . . . . . . . . . . . 6
5.4. JSON Schema extension . . . . . . . . . . . . . . . . . . 6
- 5.5. Security considerations . . . . . . . . . . . . . . . . . 6
- 6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 6
- 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 6.2. Valid values . . . . . . . . . . . . . . . . . . . . . . . 7
- 6.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 7. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 7
- 7.1. Addressing mechanisms . . . . . . . . . . . . . . . . . . 7
- 7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 7
+ 5.5. Security considerations . . . . . . . . . . . . . . . . . 7
+ 6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 7
+ 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6.2. Customization . . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Schema addressing . . . . . . . . . . . . . . . . . . . . . . 8
+ 7.1. Addressing mechanisms . . . . . . . . . . . . . . . . . . 8
+ 7.2. URI of a root schema . . . . . . . . . . . . . . . . . . . 8
7.3. Canonical addressing . . . . . . . . . . . . . . . . . . . 8
7.4. Inline addressing . . . . . . . . . . . . . . . . . . . . 8
7.4.1. JSON Reference extension . . . . . . . . . . . . . . . 9
- 7.5. Security considerations . . . . . . . . . . . . . . . . . 9
- 8. Schema/Instance Association . . . . . . . . . . . . . . . . . 9
- 8.1. Purpose of this section . . . . . . . . . . . . . . . . . 9
+ 7.5. Security considerations . . . . . . . . . . . . . . . . . 10
+ 8. Schema/Instance Association . . . . . . . . . . . . . . . . . 10
+ 8.1. Purpose of this section . . . . . . . . . . . . . . . . . 10
8.2. Recommended correlation mechanisms for use with the
HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 10
8.2.1. Correlation by means of the "Content-Type" header . . 10
- 8.2.2. Correlation by means of the "Link" header . . . . . . 10
+ 8.2.2. Correlation by means of the "Link" header . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
- Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 11
+ Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 12
@@ -108,9 +108,9 @@ Table of Contents
-Galiegue Expires March 30, 2013 [Page 2]
+Galiegue Expires May 27, 2013 [Page 2]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema November 2012
1. Introduction
@@ -139,7 +139,15 @@ Internet-Draft JSON Schema September 2012
3. Core terminology of JSON Schema
-3.1. JSON Schema, keywords
+3.1. Property, item
+
+ A property of a JSON object is equivalent to a member, as defined by
+ RFC 4627.
+
+ An item of a JSON array is equivalent to an element, as defined by
+ RFC 4627.
+
+3.2. JSON Schema, keywords
A JSON Schema is a JSON document, and that document MUST be an
object. Object members of a JSON Schema are called keywords, or
@@ -147,32 +155,42 @@ Internet-Draft JSON Schema September 2012
A JSON Schema MAY be empty.
-3.2. Root schema, subschema
+3.3. Root schema, subschema
+
+ This is a simple example of a JSON Schema, with no nested schemas:
+
+
+ {
+
+
+
+Galiegue Expires May 27, 2013 [Page 3]
+
+Internet-Draft JSON Schema November 2012
+
+
+ "title": "root"
+ }
- JSON Schemas can be nested, as in this example:
+
+ JSON Schemas can also be nested, as in this example:
{
"title": "root",
- "otherschema": {
+ "otherSchema": {
"title": "nested",
- "anotherschema": {
- "title": "alsonested"
+ "anotherSchema": {
+ "title": "alsoNested"
}
}
}
-
-Galiegue Expires March 30, 2013 [Page 3]
-
-Internet-Draft JSON Schema September 2012
-
-
- In this example, "nested" and "alsonested" are subschemas, and "root"
+ In this example, "nested" and "alsoNested" are subschemas, and "root"
is a root schema.
-3.3. JSON Schema primitive types
+3.4. JSON Schema primitive types
JSON Schema defines seven primitive types for JSON values:
@@ -181,7 +199,7 @@ Internet-Draft JSON Schema September 2012
boolean A JSON boolean.
integer A JSON number without a fraction or exponent part (see RFC
- 4627, section 2.4) [RFC4627].
+ 4627, section 2.4 [RFC4627]).
number Any JSON number. Number includes integer.
@@ -191,7 +209,7 @@ Internet-Draft JSON Schema September 2012
string A JSON string.
-3.4. JSON value equality
+3.5. JSON value equality
Two JSON values are said to be equal if and only if:
@@ -199,11 +217,17 @@ Internet-Draft JSON Schema September 2012
both are booleans, and have the same value; or
- both are strings, and have the same value; or
- both are integers, and have the same value; or
- both are numbers, and have the same value; or
+
+Galiegue Expires May 27, 2013 [Page 4]
+
+Internet-Draft JSON Schema November 2012
+
+
+ both are strings, and have the same value; or
+
+ both are numbers, and have the same mathematical value; or
both are arrays, and:
@@ -216,30 +240,22 @@ Internet-Draft JSON Schema September 2012
have the same set of members; and
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 4]
-
-Internet-Draft JSON Schema September 2012
-
-
values for a same member are equal according to this
definition.
-3.5. Instance
+3.6. Instance
- An instance is any JSON value being processed by a JSON Schema. The
- specification may also refer to an instance as a JSON instance.
+ An instance is any JSON value, which may be defined by one or more
+ JSON Schemas. The specification may also refer to an instance as a
+ JSON instance.
4. Overview
- JSON Schema defines the media type "application/schema+json" for
- describing the structure of JSON instances. JSON Schemas are
- themselves written in JSON and include facilities for describing the
- structure of JSON in terms of allowable values, descriptions, and
- interpreting relations with other resources.
+ This document proposes a new media type "application/schema+json" to
+ identify JSON Schema for describing the structure of JSON instances.
+ JSON Schemas are themselves written in JSON and include facilities
+ for describing the structure of JSON in terms of allowable values,
+ descriptions, and interpreting relations with other resources.
JSON Schema serves different purposes, which are summarized below.
Each purpose has a defined set of keywords which is described in its
@@ -255,6 +271,16 @@ Internet-Draft JSON Schema September 2012
interface in order to collect user input, and check the correctness
of said input.
+
+
+
+
+
+Galiegue Expires May 27, 2013 [Page 5]
+
+Internet-Draft JSON Schema November 2012
+
+
4.2. Hypermedia and linking
JSON Schema provides a method for defining link relations from
@@ -272,14 +298,7 @@ Internet-Draft JSON Schema September 2012
an instance be of a particular type: JSON Schema can process any JSON
value, including null. It is the domain of JSON Schema validation to
add useful constraints to the structure and, optionally, semantics,
- of the JSON instance being processed.
-
-
-
-Galiegue Expires March 30, 2013 [Page 5]
-
-Internet-Draft JSON Schema September 2012
-
+ of the JSON instance being described.
5.2. Protocol and programming language independence
@@ -309,60 +328,70 @@ Internet-Draft JSON Schema September 2012
these additional keywords to be supported by peer implementations.
Implementations SHOULD ignore keywords they do not support.
-5.5. Security considerations
- Both schemas and instances are JSON values. As such, all security
- considerations defined in [RFC4627] apply.
- JSON Schema does not define an internal security mechanism. It is up
- to applications to determine the level of trust placed into JSON data
- coming from external sources (whether this data be an instance or a
- schema), using any mechanism at their disposal.
-6. The "$schema" keyword
-6.1. Purpose
+Galiegue Expires May 27, 2013 [Page 6]
+
+Internet-Draft JSON Schema November 2012
- The "$schema" keyword plays two roles in JSON Schema:
- it defines the version of the schema which a particular JSON
- Schema is valid against;
+5.5. Security considerations
+ Both schemas and instances are JSON values. As such, all security
+ considerations defined in RFC 4627 [RFC4627] apply.
+6. The "$schema" keyword
+6.1. Purpose
+ 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.
-Galiegue Expires March 30, 2013 [Page 6]
-
-Internet-Draft JSON Schema September 2012
+ This keyword MUST be located at the root of a JSON Schema. The value
+ of this keyword MUST be a URI, and this URI MUST be both absolute and
+ normalized. The resource located at this URI MUST successfully
+ describe itself. It is RECOMMENDED that schema authors include this
+ keyword in their schemas.
+ The following values are predefined:
- it is a URI which is a location to a JSON Schema which validates
- any schema written for this version.
+ "http://json-schema.org/schema#" (JSON Schema written against the
+ current version of the specification);
- Any of these schemas also validate themselves successfully.
+ "http://json-schema.org/schema#" (JSON Schema written against the
+ current version of the specification);
-6.2. Valid values
+ "http://json-schema.org/draft-04/schema#" (JSON Schema written
+ against JSON Schema, draft v4);
- The value of this keyword MUST be one of the following string values:
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
+ hyperschema written against JSON Schema, draft v4);
- "http://json-schema.org/draft-03/schema#" (core JSON Schema
- written against JSON Schema, draft v3 [json-schema-03]);
+ "http://json-schema.org/draft-03/schema#" (JSON Schema written
+ against JSON Schema, draft v3 [json-schema-03]);
"http://json-schema.org/draft-03/hyper-schema#" (JSON Schema
hyperschema written against JSON Schema, draft v3
- [json-schema-03]);
+ [json-schema-03]).
+
+6.2. Customization
- "http://json-schema.org/current/schema-core.json#" (schema written
- against the current version of the specification -- this one).
+ When extending JSON Schema with custom keywords, schema authors MAY
+ define a custom URI and the associated resource, and SHOULD use the
+ "$schema" keyword for any schema written with these custom keywords.
+ The chosen URI MUST NOT be one of the predefined values.
-6.3. Usage
- It is RECOMMENDED that schema authors include this keyword in their
- schemas. This keyword MUST be located at the root of a schema.
- It is RECOMMENDED that implementations not supporting a particular
- schema version fail JSON Schema processing.
+
+Galiegue Expires May 27, 2013 [Page 7]
+
+Internet-Draft JSON Schema November 2012
+
7. Schema addressing
@@ -373,9 +402,9 @@ Internet-Draft JSON Schema September 2012
Implementations MUST support canonical addressing, and MAY support
inline addressing.
- Inline addressing is done by the means of the "id" keyword. The
- value of this keyword MUST be a string; this string MUST be a valid
- URI, and SHOULD be normalized.
+ Inline addressing is done by the means of the "id" keyword. When
+ present, the value of this keyword MUST be a string; this string MUST
+ be a valid URI, and SHOULD be normalized.
7.2. URI of a root schema
@@ -386,13 +415,6 @@ Internet-Draft JSON Schema September 2012
if "id" is present in the root schema, its value MAY be considered
to be the schema URI;
-
-
-Galiegue Expires March 30, 2013 [Page 7]
-
-Internet-Draft JSON Schema September 2012
-
-
otherwise, it is RECOMMENDED that implementations consider that
the URI of the schema is either the empty URI, or a URN.
@@ -416,6 +438,17 @@ Internet-Draft JSON Schema September 2012
This schema will be taken as an example:
+
+
+
+
+
+
+Galiegue Expires May 27, 2013 [Page 8]
+
+Internet-Draft JSON Schema November 2012
+
+
{
"id": "http://x.y.z/rootschema.json#",
"schema1": {
@@ -439,16 +472,6 @@ Internet-Draft JSON Schema September 2012
Subschemas at the following URI-encoded JSON Pointer [json-pointer]s
(starting from the root schema) have the following URIs:
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 8]
-
-Internet-Draft JSON Schema September 2012
-
-
# (document root) http://x.y.z/rootschema.json#
#/schema1 http://x.y.z/rootschema.json#foo
@@ -475,6 +498,13 @@ Internet-Draft JSON Schema September 2012
}
+
+
+Galiegue Expires May 27, 2013 [Page 9]
+
+Internet-Draft JSON Schema November 2012
+
+
An implementation choosing to support inline addressing SHOULD
support this extension to JSON Reference.
@@ -498,13 +528,6 @@ Internet-Draft JSON Schema September 2012
Schemas. This correlation MAY be embodied within existing protocol
headers.
-
-
-Galiegue Expires March 30, 2013 [Page 9]
-
-Internet-Draft JSON Schema September 2012
-
-
In addition, if the protocol also carries media type information (by
means, for instance, of a "Content-Type" header), an instance MUST be
one of "application/json" or any other subtype.
@@ -530,35 +553,28 @@ Internet-Draft JSON Schema September 2012
An example of such a header would be:
- Content-Type: application/my-media-type+json;
- profile=http://example.com/my-hyper-schema
-8.2.2. Correlation by means of the "Link" header
-
- When using the "Link" header, it is RECOMMENDED that a relationship
- by the name "describedBy" be used, as defined by RFC 2048, section
- 19.6.2.4 [RFC2048]. Note: it should be remembered that relationship
- values are case insensitive, so "describedBy" is just as valid a
- relationship as "DESCRIBEDBY".
- The target URI of the "Link" header SHOULD be a valid JSON Schema.
-
- An example of such a header would be:
-
-
- Link: ; rel="describedBy"
+Galiegue Expires May 27, 2013 [Page 10]
+
+Internet-Draft JSON Schema November 2012
+ Content-Type: application/my-media-type+json;
+ profile=http://example.com/my-hyper-schema
+8.2.2. Correlation by means of the "Link" header
+ When using the "Link" header, the relation type used MUST be
+ "describedBy", as defined by RFC 5988, section 5.3 [RFC5988]. The
+ target URI of the "Link" header SHOULD be a valid JSON Schema.
+ An example of such a header would be:
-Galiegue Expires March 30, 2013 [Page 10]
-
-Internet-Draft JSON Schema September 2012
+ Link: ; rel="describedBy"
9. IANA Considerations
@@ -578,23 +594,29 @@ Internet-Draft JSON Schema September 2012
10.2. Informative References
- [RFC2048] Freed, N., Klensin, J., and J. Postel,
- "Multipurpose Internet Mail Extensions (MIME) Part
- Four: Registration Procedures", BCP 13, RFC 2048,
- November 1996.
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic
+ Syntax", STD 66, RFC 3986, January 2005.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
July 2006.
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
- "Uniform Resource Identifier (URI): Generic
- Syntax", STD 66, RFC 3986, January 2005.
+ [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
+ October 2010.
[json-reference] Bryan, P. and K. Zyp, "JSON Reference",
September 2012, .
+
+
+
+Galiegue Expires May 27, 2013 [Page 11]
+
+Internet-Draft JSON Schema November 2012
+
+
[json-pointer] Bryan, P. and K. Zyp, "JSON Pointer",
September 2012, .
@@ -607,16 +629,6 @@ Appendix A. ChangeLog
TODO
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 11]
-
-Internet-Draft JSON Schema September 2012
-
-
Author's Address
Francis Galiegue
@@ -656,17 +668,5 @@ Author's Address
-
-
-
-
-
-
-
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 12]
+Galiegue Expires May 27, 2013 [Page 12]
diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml
index 1d4f8416..c36e0382 100644
--- a/proposals/json-schema-core.xml
+++ b/proposals/json-schema-core.xml
@@ -1,9 +1,9 @@
+
]>
@@ -75,6 +75,16 @@
+
+
+ A property of a JSON object is equivalent to a member, as defined by RFC 4627.
+
+
+
+ An item of a JSON array is equivalent to an element, as defined by RFC 4627.
+
+
+
A JSON Schema is a JSON document, and that document MUST be an object. Object
@@ -88,17 +98,30 @@
- JSON Schemas can be nested, as in this example:
+ This is a simple example of a JSON Schema, with no nested schemas:
+
+
+
+
+
+
+
+
+ JSON Schemas can also be nested, as in this example:
- In this example, "nested" and "alsonested" are subschemas, and "root" is a root
+ In this example, "nested" and "alsoNested" are subschemas, and "root" is a root
schema.
@@ -119,7 +142,7 @@
A JSON array.A JSON boolean.A JSON number without a fraction or exponent part (see
- RFC 4627, section 2.4).
+ RFC 4627, section 2.4).Any JSON number. Number includes integer.The JSON null value.A JSON object.
@@ -136,8 +159,7 @@
both are nulls; orboth are booleans, and have the same value; orboth are strings, and have the same value; or
- both are integers, and have the same value; or
- both are numbers, and have the same value; or
+ both are numbers, and have the same mathematical value; orboth are arrays, and:
have the same number of elements; and
@@ -158,8 +180,8 @@
- An instance is any JSON value being processed by a JSON Schema. The
- specification may also refer to an instance as a JSON instance.
+ An instance is any JSON value, which may be defined by one or more JSON Schemas.
+ The specification may also refer to an instance as a JSON instance.
@@ -167,10 +189,10 @@
- JSON Schema defines the media type "application/schema+json" for describing the
- structure of JSON instances. JSON Schemas are themselves written in JSON and include
- facilities for describing the structure of JSON in terms of allowable values,
- descriptions, and interpreting relations with other resources.
+ This document proposes a new media type "application/schema+json" to identify JSON
+ Schema for describing the structure of JSON instances. JSON Schemas are themselves
+ written in JSON and include facilities for describing the structure of JSON in terms
+ of allowable values, descriptions, and interpreting relations with other resources.
@@ -208,7 +230,7 @@
instance be of a particular type: JSON Schema can process any JSON value,
including null. It is the domain of JSON Schema validation to add useful
constraints to the structure and, optionally, semantics, of the JSON instance
- being processed.
+ being described.
@@ -249,61 +271,54 @@
Both schemas and instances are JSON values. As such, all security considerations
- defined in apply.
-
-
-
- JSON Schema does not define an internal security mechanism. It is up to
- applications to determine the level of trust placed into JSON data coming from
- external sources (whether this data be an instance or a schema), using any
- mechanism at their disposal.
+ defined in RFC 4627 apply.
+
- The "$schema" keyword plays two roles in JSON Schema:
-
-
- it defines the version of the schema which a particular JSON Schema is
- valid against;
- it is a URI which is a location to a JSON Schema which validates any
- schema written for this version.
-
+ 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.
- Any of these schemas also validate themselves successfully.
+ This keyword MUST be located at the root of a JSON Schema. The value of this
+ keyword MUST be a URI, and this URI MUST be both absolute and normalized. The
+ resource located at this URI MUST successfully describe itself. It is
+ RECOMMENDED that schema authors include this keyword in their schemas.
-
-
- The value of this keyword MUST be one of the following string values:
+ The following values are predefined:
- "http://json-schema.org/draft-03/schema#" (core JSON Schema written
+ "http://json-schema.org/schema#" (JSON Schema written
+ against the current version of the specification);
+ "http://json-schema.org/schema#" (JSON Schema written
+ against the current version of the specification);
+ "http://json-schema.org/draft-04/schema#" (JSON Schema written
+ against JSON Schema, draft v4);
+ "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema hyperschema
+ written against JSON Schema, draft v4);
+ "http://json-schema.org/draft-03/schema#" (JSON Schema written
against JSON Schema, draft v3);"http://json-schema.org/draft-03/hyper-schema#" (JSON Schema hyperschema
written against JSON Schema, draft
- v3);
- "http://json-schema.org/current/schema-core.json#" (schema written
- against the current version of the specification -- this one).
+ v3).
-
+
- It is RECOMMENDED that schema authors include this keyword in their schemas.
- This keyword MUST be located at the root of a schema.
-
-
-
- It is RECOMMENDED that implementations not supporting a particular schema
- version fail JSON Schema processing.
+ When extending JSON Schema with custom keywords, schema authors MAY define a
+ custom URI and the associated resource, and SHOULD use the "$schema" keyword for
+ any schema written with these custom keywords. The chosen URI MUST NOT be one of
+ the predefined values.
@@ -319,9 +334,9 @@
- Inline addressing is done by the means of the "id" keyword. The value of this
- keyword MUST be a string; this string MUST be a valid URI, and SHOULD be
- normalized.
+ Inline addressing is done by the means of the "id" keyword. When present, the
+ value of this keyword MUST be a string; this string MUST be a valid URI, and
+ SHOULD be normalized.
@@ -502,15 +517,9 @@ Content-Type: application/my-media-type+json;
- When using the "Link" header, it is RECOMMENDED that a relationship by the
- name "describedBy" be used, as defined by RFC 2048,
- section 19.6.2.4. Note: it should be remembered that relationship
- values are case insensitive, so "describedBy" is just as valid a
- relationship as "DESCRIBEDBY".
-
-
-
- The target URI of the "Link" header SHOULD be a valid JSON Schema.
+ When using the "Link" header, the relation type used MUST be "describedBy",
+ as defined by RFC 5988, section 5.3. The
+ target URI of the "Link" header SHOULD be a valid JSON Schema.
@@ -520,7 +529,7 @@ Content-Type: application/my-media-type+json;
; rel="describedBy"
+Link: ; rel="describedBy"
]]>
@@ -549,9 +558,9 @@ Link: ; rel="describedBy"
&RFC2119;
- &RFC2048;
- &RFC4627;
&RFC3986;
+ &RFC4627;
+ &RFC5988;
From e2fabfb3930f222eb30e7681467349bbd7ad0be5 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Dec 2012 12:46:04 +0100
Subject: [PATCH 0125/1659] Revise json-schema-validation draft
* Reintroduce property dependencies but only in array form, and with at least
one element.
* Reintroduce multiple single types in "type".
---
proposals/json-schema-validation.txt | 284 +++++++++++++--------------
proposals/json-schema-validation.xml | 56 ++++--
proposals/schema-core.json | 40 ++--
3 files changed, 212 insertions(+), 168 deletions(-)
diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt
index 6293b150..0eb5d791 100644
--- a/proposals/json-schema-validation.txt
+++ b/proposals/json-schema-validation.txt
@@ -2,9 +2,9 @@
Internet Engineering Task Force fge. Galiegue
-Internet-Draft September 26, 2012
+Internet-Draft December 17, 2012
Intended status: Informational
-Expires: March 30, 2013
+Expires: June 20, 2013
JSON Schema: interactive and non interactive validation
@@ -35,7 +35,7 @@ Status of This Memo
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 March 30, 2013.
+ This Internet-Draft will expire on June 20, 2013.
Copyright Notice
@@ -52,9 +52,9 @@ Copyright Notice
-Galiegue Expires March 30, 2013 [Page 1]
+Galiegue Expires June 20, 2013 [Page 1]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
the Trust Legal Provisions and are provided without warranty as
@@ -98,45 +98,45 @@ Table of Contents
5.5. Validation keywords for any instance type . . . . . . . . 15
5.5.1. enum . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.5.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.5.3. allOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 17
6.1. "title" and "description" . . . . . . . . . . . . . . . . 17
6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
-Galiegue Expires March 30, 2013 [Page 2]
+Galiegue Expires June 20, 2013 [Page 2]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
6.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17
- 6.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17
- 7. Semantic validation with "format" . . . . . . . . . . . . . . 17
- 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6.2.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7. Semantic validation with "format" . . . . . . . . . . . . . . 18
+ 7.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Implementation requirements . . . . . . . . . . . . . . . 18
7.3. Defined attributes . . . . . . . . . . . . . . . . . . . . 18
7.3.1. date-time . . . . . . . . . . . . . . . . . . . . . . 18
- 7.3.2. email . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.3.2. email . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.5. ipv6 . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.3.6. uri . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Calculating child instances' schema(s) . . . . . . . . . . . . 20
8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 20
8.2.1. Defining characteristic . . . . . . . . . . . . . . . 20
- 8.2.2. Implied keywords and default values. . . . . . . . . . 20
- 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 20
+ 8.2.2. Implied keywords and default values. . . . . . . . . . 21
+ 8.2.3. Calculation . . . . . . . . . . . . . . . . . . . . . 21
8.3. Object values . . . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Defining characteristic . . . . . . . . . . . . . . . 21
8.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 21
- 8.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 21
+ 8.3.3. Calculation . . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
@@ -164,9 +164,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 3]
+Galiegue Expires June 20, 2013 [Page 3]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
1. Introduction
@@ -220,9 +220,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 4]
+Galiegue Expires June 20, 2013 [Page 4]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
3.3. Regular expressions
@@ -276,9 +276,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 5]
+Galiegue Expires June 20, 2013 [Page 5]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
succeed.
@@ -332,9 +332,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 6]
+Galiegue Expires June 20, 2013 [Page 6]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
5.1.2. maximum and exclusiveMaximum
@@ -388,9 +388,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 7]
+Galiegue Expires June 20, 2013 [Page 7]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
5.1.3.3. Default value
@@ -444,9 +444,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 8]
+Galiegue Expires June 20, 2013 [Page 8]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
expression dialect.
@@ -500,9 +500,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 9]
+Galiegue Expires June 20, 2013 [Page 9]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
This is an example schema:
@@ -556,9 +556,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 10]
+Galiegue Expires June 20, 2013 [Page 10]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
5.3.3.2. Conditions for successful validation
@@ -612,9 +612,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 11]
+Galiegue Expires June 20, 2013 [Page 11]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
5.4.2.1. Valid values
@@ -668,9 +668,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 12]
+Galiegue Expires June 20, 2013 [Page 12]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
5.4.4.2. Conditions for successful validation
@@ -724,9 +724,9 @@ Internet-Draft JSON Schema September 2012
-Galiegue Expires March 30, 2013 [Page 13]
+Galiegue Expires June 20, 2013 [Page 13]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
{
@@ -755,11 +755,11 @@ Internet-Draft JSON Schema September 2012
The three sets are:
- s { "p1", "p2", "a32&o", "", "finance", "apple" }
+ s [ "p1", "p2", "a32&o", "", "finance", "apple" ]
- p { "p1" }
+ p [ "p1" ]
- pp { "p", "[0-9]" }
+ pp [ "p", "[0-9]" ]
Applying the two steps of the algorithm:
@@ -776,24 +776,39 @@ Internet-Draft JSON Schema September 2012
5.4.5.1. Valid values
This keyword's value MUST be an object. Each value of this object
- MUST be an object, and MUST be a valid JSON Schema.
+ MUST be either an object or an array.
-Galiegue Expires March 30, 2013 [Page 14]
+Galiegue Expires June 20, 2013 [Page 14]
-Internet-Draft JSON Schema September 2012
+Internet-Draft JSON Schema December 2012
+ 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.
+
5.4.5.2. Conditions for successful validation
- For each element in the object instance's key set, if "dependencies"
- contains a key by the same name, the object instance must validate
- successfully against the matching schema in "dependencies".
+5.4.5.2.1. Schema dependencies
+
+ For each schema dependency, if the object instance to validate has a
+ property by the same name, then it must also be valid by the schema
+ value.
Note that this is the object instance itself which must validate
successfully, not the value associated with that key.
+5.4.5.2.2. Property dependencies
+
+ For each property dependency, if the object instance to validate has
+ a property by the same name, then it must also have properties with
+ the same name as each of the property dependency value.
+
5.5. Validation keywords for any instance type
5.5.1. enum
@@ -815,14 +830,25 @@ Internet-Draft JSON Schema September 2012
5.5.2.1. Valid values
- The value of this keyword MUST be a string. The value of this string
- MUST be one of the seven primitive types defined by FIXME_LINK.
+ 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.
+
+
+
+Galiegue Expires June 20, 2013 [Page 15]
+
+Internet-Draft JSON Schema December 2012
+
+
+ The values of the string or of each element of the array MUST be one
+ of the seven primitive types defined by FIXME_LINK.
5.5.2.2. Conditions for successful validation
An instance matches successfully if and only if its primitive type is
- the one defined by the value of this keyword. Recall: "number"
- includes "integer".
+ one of the types defined by keyword. Recall: "number" includes
+ "integer".
5.5.3. allOf
@@ -834,13 +860,6 @@ Internet-Draft JSON Schema September 2012
Elements of the array MUST be objects. Each object MUST be a valid
JSON Schema.
-
-
-Galiegue Expires March 30, 2013 [Page 15]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5.3.2. Conditions for successful validation
An instance validates successfully against this keyword if and only
@@ -870,6 +889,14 @@ Internet-Draft JSON Schema September 2012
This keyword's value MUST be an array. This array MUST have at least
one element.
+
+
+
+Galiegue Expires June 20, 2013 [Page 16]
+
+Internet-Draft JSON Schema December 2012
+
+
Elements of the array MUST be objects. Each object MUST be a valid
JSON Schema.
@@ -886,17 +913,6 @@ Internet-Draft JSON Schema September 2012
This keyword's value MUST be an object. This object MUST be a valid
JSON Schema.
-
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 16]
-
-Internet-Draft JSON Schema September 2012
-
-
5.5.6.2. Conditions for successful validation
An instance is valid against this keyword if and only if it fails to
@@ -927,6 +943,16 @@ Internet-Draft JSON Schema September 2012
There are no restrictions placed on the value of this keyword.
+
+
+
+
+
+Galiegue Expires June 20, 2013 [Page 17]
+
+Internet-Draft JSON Schema December 2012
+
+
6.2.2. Purpose
This keyword can be used to substitute a default value for the
@@ -946,13 +972,6 @@ Internet-Draft JSON Schema September 2012
authoritative resources, be they RFCs or other external
specifications.
-
-
-Galiegue Expires March 30, 2013 [Page 17]
-
-Internet-Draft JSON Schema September 2012
-
-
The value of this keyword MUST be a string. This value is called a
format attribute. A format attribute can generally only validate a
given set of instance types. If the type of the instance to validate
@@ -980,6 +999,16 @@ Internet-Draft JSON Schema September 2012
This attribute applies to string instances.
+
+
+
+
+
+Galiegue Expires June 20, 2013 [Page 18]
+
+Internet-Draft JSON Schema December 2012
+
+
7.3.1.2. Validation
A string instance is valid against this attribute if and only if it
@@ -998,17 +1027,6 @@ Internet-Draft JSON Schema September 2012
is a valid Internet email address as defined by RFC 5322, section
3.4.1 [RFC5322].
-
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 18]
-
-Internet-Draft JSON Schema September 2012
-
-
7.3.3. hostname
7.3.3.1. Applicability
@@ -1036,6 +1054,17 @@ Internet-Draft JSON Schema September 2012
7.3.5. ipv6
+
+
+
+
+
+
+Galiegue Expires June 20, 2013 [Page 19]
+
+Internet-Draft JSON Schema December 2012
+
+
7.3.5.1. Applicability
This attribute applies to string instances.
@@ -1057,14 +1086,6 @@ Internet-Draft JSON Schema September 2012
A string instance is valid against this attribute if and only if it
is a valid URI, according to [RFC3986].
-
-
-
-Galiegue Expires March 30, 2013 [Page 19]
-
-Internet-Draft JSON Schema September 2012
-
-
8. Calculating child instances' schema(s)
8.1. Foreword
@@ -1090,6 +1111,16 @@ Internet-Draft JSON Schema September 2012
The defining characteristic of the child instance is this instance's
index in the array instance. Recall: array indices start at 0.
+
+
+
+
+
+Galiegue Expires June 20, 2013 [Page 20]
+
+Internet-Draft JSON Schema December 2012
+
+
8.2.2. Implied keywords and default values.
The two implied keywords in this calculation are "items" and
@@ -1112,15 +1143,6 @@ Internet-Draft JSON Schema September 2012
In this situation, the schema depends on the index of the child
instance:
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 20]
-
-Internet-Draft JSON Schema September 2012
-
-
if the index is less than, or equal to, the maximum index in the
"items" array, then the child instance must be valid against the
corresponding schema in the "items" array;
@@ -1148,6 +1170,13 @@ Internet-Draft JSON Schema September 2012
empty schema as a value. In addition, boolean value true is
considered equivalent to an empty schema.
+
+
+Galiegue Expires June 20, 2013 [Page 21]
+
+Internet-Draft JSON Schema December 2012
+
+
8.3.3. Calculation
8.3.3.1. Names used in this calculation
@@ -1168,15 +1197,6 @@ Internet-Draft JSON Schema September 2012
If set "p" contains value "m", then the corresponding schema in
"properties" is added to "s".
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 21]
-
-Internet-Draft JSON Schema September 2012
-
-
8.3.3.3. Second step: schemas in "patternProperties"
For each regex in "pp", if it matches "m" successfully, the
@@ -1206,6 +1226,13 @@ Internet-Draft JSON Schema September 2012
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
+
+
+Galiegue Expires June 20, 2013 [Page 22]
+
+Internet-Draft JSON Schema December 2012
+
+
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
RFC 2673, August 1999.
@@ -1226,13 +1253,6 @@ Internet-Draft JSON Schema September 2012
www.ecma-international.org/publications/files/ECMA-ST/
Ecma-262.pdf>.
-
-
-Galiegue Expires March 30, 2013 [Page 22]
-
-Internet-Draft JSON Schema September 2012
-
-
Appendix A. ChangeLog
TODO
@@ -1264,25 +1284,5 @@ Author's Address
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Galiegue Expires March 30, 2013 [Page 23]
+Galiegue Expires June 20, 2013 [Page 23]
diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml
index ff0cf033..ebeee8a4 100644
--- a/proposals/json-schema-validation.xml
+++ b/proposals/json-schema-validation.xml
@@ -739,10 +739,10 @@
The three sets are:
- { "p1", "p2", "a32&o", "", "finance", "apple"
- }
- { "p1" }
- { "p", "[0-9]" }
+ [ "p1", "p2", "a32&o", "", "finance", "apple"
+ ]
+ [ "p1" ]
+ [ "p", "[0-9]" ]
@@ -770,23 +770,45 @@
This keyword's value MUST be an object. Each value of this object MUST
- be an object, and MUST be a valid JSON Schema.
+ be either an object or an array.
-
-
- For each element in the object instance's key set, if "dependencies"
- contains a key by the same name, the object instance must validate
- successfully against the matching schema in "dependencies".
+ If the value is an object, it MUST be a valid JSON Schema. This is
+ called a schema dependency.
- Note that this is the object instance itself which must validate
- successfully, not the value associated with that key.
+ 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 each schema dependency, if the object instance to validate has a
+ property by the same name, then it must also be valid by the schema
+ value.
+
+
+
+ Note that this is the object instance itself which must validate
+ successfully, not the value associated with that key.
+
+
+
+
+
+ For each property dependency, if the object instance to validate has
+ a property by the same name, then it must also have properties with
+ the same name as each of the property dependency value.
+
+
+
+
+
@@ -819,15 +841,19 @@
- The value of this keyword MUST be a string. The value of this string
- MUST be one of the seven primitive types defined by FIXME_LINK.
+ 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.
+
+
+ The values of the string or of each element of the array MUST be one of
+ the seven primitive types defined by FIXME_LINK.
An instance matches successfully if and only if its primitive type is
- the one defined by the value of this keyword. Recall: "number" includes
+ one of the types defined by keyword. Recall: "number" includes
"integer".
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 8db26487..4a8dddc2 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -15,6 +15,15 @@
"positiveIntegerDefault0": {
"allOf": [ { "$ref": "#/common/positiveInteger" }, { "default": 0 } ]
}
+ "simpleTypes": {
+ "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ]
+ },
+ "stringArray": {
+ "type": "array",
+ "items": { "type": "string" },
+ "minItems": 1,
+ "uniqueItems": true
+ }
},
"type": "object",
"properties": {
@@ -55,7 +64,8 @@
"maxLength": { "$ref": "#/common/positiveInteger" },
"minLength": { "$ref": "#/common/positiveIntegerDefault0" },
"pattern": {
- "type": "string"
+ "type": "string",
+ "format": "regex"
},
"additionalItems": {
"anyOf": [
@@ -79,12 +89,7 @@
},
"maxProperties": { "$ref": "#/common/positiveInteger" },
"minProperties": { "$ref": "#/common/positiveIntegerDefault0" },
- "required": {
- "type": "array",
- "minItems": 1,
- "items": { "type": "string" },
- "uniqueItems": true
- }
+ "required": { "$ref": "#/common/stringArray" },
"additionalProperties": {
"anyOf": [
{ "type": "boolean" },
@@ -104,7 +109,12 @@
},
"dependencies": {
"type": "object",
- "additionalProperties": { "$ref": "#" }
+ "additionalProperties": {
+ "anyOf": [
+ { "$ref": "#" },
+ { "$ref": "#/common/stringArray"
+ ]
+ }
},
"enum": {
"type": "array",
@@ -112,7 +122,15 @@
"uniqueItems": true
},
"type": {
- "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ]
+ "anyOf": [
+ { "$ref": "#/common/simpleTypes" },
+ {
+ "type": "array",
+ "items": { "$ref": "#/common/simpleTypes" },
+ "minItems": 1,
+ "uniqueItems": true
+ }
+ ]
},
"allOf": { "$ref": "#/common/schemaArray" },
"anyOf": { "$ref": "#/common/schemaArray" },
@@ -120,8 +138,8 @@
"not": { "$ref": "#" }
},
"dependencies": {
- "exclusiveMaximum": { "required": [ "maximum" ] },
- "exclusiveMinimum": { "required": [ "minimum" ] }
+ "exclusiveMaximum": [ "maximum" ],
+ "exclusiveMinimum": [ "minimum" ]
},
"default": {}
}
From 041898f1258eecf902172d582aeba7647af1a59b Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Dec 2012 13:19:11 +0100
Subject: [PATCH 0126/1659] Fix schema-core.json
---
proposals/schema-core.json | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 4a8dddc2..30e411b5 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -1,6 +1,6 @@
{
- "id": "http://json-schema.org/current/schema-core.json#",
- "$schema": "http://json-schema.org/current/schema-core.json#",
+ "id": "http://json-schema.org/draft-04/schema#",
+ "$schema": "http://json-schema.org/draft-04/schema#",
"description": "Core schema meta-schema",
"common": {
"schemaArray": {
@@ -112,7 +112,7 @@
"additionalProperties": {
"anyOf": [
{ "$ref": "#" },
- { "$ref": "#/common/stringArray"
+ { "$ref": "#/common/stringArray" }
]
}
},
From 174d127922697764d3d3d730aa9bb29d2d6588f5 Mon Sep 17 00:00:00 2001
From: Francis Galiegue
Date: Mon, 17 Dec 2012 13:19:11 +0100
Subject: [PATCH 0127/1659] Fix schema-core.json, again
---
proposals/schema-core.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/proposals/schema-core.json b/proposals/schema-core.json
index 30e411b5..f7ecbf12 100644
--- a/proposals/schema-core.json
+++ b/proposals/schema-core.json
@@ -14,7 +14,7 @@
},
"positiveIntegerDefault0": {
"allOf": [ { "$ref": "#/common/positiveInteger" }, { "default": 0 } ]
- }
+ },
"simpleTypes": {
"enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ]
},
From 750b7e5ccac730665c64394ffac99ebb45411bdf Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 20:31:28 +0000
Subject: [PATCH 0128/1659] Re-organisation - move LDO section to root level
---
proposals/json-schema-hypermedia.html | 566 ++++++++++++------------
proposals/json-schema-hypermedia.txt | 548 +++++++++++-------------
proposals/json-schema-hypermedia.xml | 593 +++++++++++++-------------
3 files changed, 837 insertions(+), 870 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index 718d19bc..a477d466 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -145,8 +145,8 @@
Internet Engineering Task Force
K. Zyp, Ed.
Internet-Draft
SitePen (USA)
Intended status: Informational
G. Court
-
Expires: March 30, 2013
G. Luff
-
September 26, 2012
+
Expires: June 21, 2013
G. Luff
+
December 18, 2012
Hyperlinks and media for JSON Schema draft-zyp-json-hyper-schema-04
@@ -172,7 +172,7 @@
Status of This Memo
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 March 30, 2013.
+This Internet-Draft will expire on June 21, 2013.
+ This property indicates the fragment resolution protocol to use for resolving fragment identifiers in URIs within the instance representations.
+ This applies to the instance object URIs and all children of the instance object's URIs.
+ The default fragment resolution protocol is "json-pointer", which is defined below.
+ Other fragment resolution protocols MAY be used, but are not defined in this document.
+
+
+ Note that if the instance is described by a schema providing the a link with "root" relation, or such a link is provided in using the HTTP Link header, then all fragment resolution should be resolved relative to the target of the root link.
+ The only exception to this is the resolution of "root" links themselves.
+
+
- A link description object is used to describe link relations.
- In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
- The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
- The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
+ The value of this attribute MUST be an object. It MAY contain any of the following properties:
+
+
+ If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
+
+
+ When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
+ If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
+ Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
+
+
+ A link description object is used to describe link relations.
+ In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
+ The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
+ The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
+
- The value of the "href" link description property indicates the target URI of the related resource.
- The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] and MAY be a relative URI.
- The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
- Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
-
+ The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] and MAY be a relative URI.
+ The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
+ Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+
- Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
- Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
- The property name between the braces SHOULD be percent encoded (FIXME reference?).
- In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
+ Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
+ Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
+ The property name between the braces SHOULD be percent encoded (FIXME reference?).
+ In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
-
+
For example, if an href value is defined:
@@ -450,7 +585,7 @@
Table of Contents
Then it would be resolved by replace the value of the "id" property value from the instance object.
-
+
If the value of the "id" property was "45", the expanded URI would be:
@@ -458,85 +593,85 @@
Table of Contents
- If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
-
+ If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
+
-
+
Values may only be used for substitution if they are of a scalar type (string, boolean or number).
In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
- The value of the "rel" property indicates the name of the relation to the target resource.
- The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
- If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
- A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
-
+ The value of the "rel" property indicates the name of the relation to the target resource.
+ The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
+ If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
+ A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
+
- Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287 (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287]).
- However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287 (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287]).
+ However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
-
+
self
- If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
-
+ If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
+
full
- This indicates that the target of the link is the full representation for the instance object.
- The instance that contains this link may not be the full representation.
-
+ This indicates that the target of the link is the full representation for the instance object.
+ The instance that contains this link may not be the full representation.
+
describedBy
- This indicates the target of the link is a schema describing the instance object.
- This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
+ This indicates the target of the link is a schema describing the instance object.
+ This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
root
- This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
- All other properties of the instance objects can be regarded as meta-data descriptions for the data.
-
+ This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
+ All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+
-
+
- The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
-
+
instances
- This indicates the target resource that represents a collection of instances of a schema.
-
+ This indicates the target resource that represents a collection of instances of a schema.
+
create
- This indicates a target to use for creating new instances of a schema.
- This link definition SHOULD be a submission link with a non-safe method (like POST).
-
+ This indicates a target to use for creating new instances of a schema.
+ This link definition SHOULD be a submission link with a non-safe method (like POST).
+
-
- Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
-
+
+ Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
+
-
+
For example, if a schema is defined:
@@ -555,7 +690,7 @@
Table of Contents
-
+
And if a collection of instance resources were retrieved with JSON representation:
@@ -571,57 +706,57 @@
Table of Contents
- This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
- The "children" collection would be located at "/Resource/?upId=thing".
-
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+
- This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
-
+ This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
+
- This property is analogous to the "type" property of elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].
- User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
- When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
-
+ This property is analogous to the "type" property of elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].
+ User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
+ When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
+
- If this property's value is not specified, then the value should be taken to be "application/json".
-
+ If this property's value is not specified, then the value should be taken to be "application/json".
+
-
+
For example, if a schema is defined:
@@ -645,70 +780,70 @@
Table of Contents
}
-
- A suitable instance described by this schema would have four links defined.
- The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
- The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
- The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
-
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
- A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
-
+ A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
+
- Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
- The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
+ Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
+ The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
+
- The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
-
+ The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
+
- If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href (href)" property.
- Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
-
+ If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href (href)" property.
+ Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
+
- If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
-
+ If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
+
- The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
-
+ The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
+
- This attribute defines which method can be used to access the target resource.
- In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
- This defaults to "GET".
-
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
- If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
- The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
+ If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
+ The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
-
+
For example, with the following schema:
@@ -729,7 +864,7 @@
Table of Contents
This indicates that the client can query the server for instances that have a specific name.
-
+
For example:
@@ -737,136 +872,23 @@
Table of Contents
- If no encType or method is specified, only the single URI specified by the href property is defined.
- If the method is POST, "application/json" is the default media type.
-
-
-
-
- This attribute contains a schema which defines the acceptable structure of the submitted request.
- For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
-
-
- This property indicates the fragment resolution protocol to use for resolving fragment identifiers in URIs within the instance representations.
- This applies to the instance object URIs and all children of the instance object's URIs.
- The default fragment resolution protocol is "json-pointer", which is defined below.
- Other fragment resolution protocols MAY be used, but are not defined in this document.
-
-
- Note that if the instance is described by a schema providing the a link with "root" relation, or such a link is provided in using the HTTP Link header, then all fragment resolution should be resolved relative to the target of the root link.
- The only exception to this is the resolution of "root" links themselves.
-
-
- If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
-
-
Instances described by this schema should be strings containing HTML, using the UTF-8 character set.
-
-
+ If no encType or method is specified, only the single URI specified by the href property is defined.
+ If the method is POST, "application/json" is the default media type.
+
- When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
- If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
- Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
-
+ This attribute contains a schema which defines the acceptable structure of the submitted request.
+ For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
+
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 358e36cb..8f47ef8f 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -4,8 +4,8 @@
Internet Engineering Task Force K. Zyp, Ed.
Internet-Draft SitePen (USA)
Intended status: Informational G. Court
-Expires: March 30, 2013 G. Luff
- September 26, 2012
+Expires: June 21, 2013 G. Luff
+ December 18, 2012
Hyperlinks and media for JSON Schema
@@ -32,7 +32,7 @@ Status of This Memo
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 March 30, 2013.
+ This Internet-Draft will expire on June 21, 2013.
Copyright Notice
@@ -52,9 +52,9 @@ Copyright Notice
-Zyp, et al. Expires March 30, 2013 [Page 1]
+Zyp, et al. Expires June 21, 2013 [Page 1]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
Table of Contents
@@ -63,25 +63,36 @@ Table of Contents
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
- 4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Schema keywords . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1.1. Link Description Object . . . . . . . . . . . . . . . 6
- 4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 12
- 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 13
- 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 13
- 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 13
- 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 14
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 5.1. "self" links . . . . . . . . . . . . . . . . . . . . . . . 15
- 5.2. "mediaType" property of Link Description Objects . . . . . 16
- 5.3. "targetSchema" property of Link Description Objects . . . 16
- 5.4. "invalidates" property of Link Description Objects . . . . 17
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 17
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
- 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
+ 4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 6
+ 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 6
+ 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 6
+ 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Link Description Object . . . . . . . . . . . . . . . . . . . 8
+ 5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1.1. Missing values . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.3. template . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.5. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.6. invalidates . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.7. Submission Link Properties . . . . . . . . . . . . . . . . 13
+ 5.7.1. method . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.7.2. encType . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.7.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 6.1. "self" links . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.2. "mediaType" property of Link Description Objects . . . . . 16
+ 6.3. "targetSchema" property of Link Description Objects . . . 16
+ 6.4. "invalidates" property of Link Description Objects . . . . 16
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
+ 7.1. Registry of Link Relations . . . . . . . . . . . . . . . . 17
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
@@ -97,20 +108,9 @@ Table of Contents
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 2]
+Zyp, et al. Expires June 21, 2013 [Page 2]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
1. Introduction
@@ -164,9 +164,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 3]
+Zyp, et al. Expires June 21, 2013 [Page 3]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
An example JSON Schema defining hyperlinks, and providing hypermedia
@@ -220,9 +220,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 4]
+Zyp, et al. Expires June 21, 2013 [Page 4]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
3.1. Design Considerations
@@ -240,7 +240,7 @@ Internet-Draft JSON Schema Media Type September 2012
that leverage a representational state transfer architecture using
existing protocols.
-4. Keywords
+4. Schema keywords
The following properties are defined for JSON Schema objects:
@@ -276,12 +276,124 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 5]
+Zyp, et al. Expires June 21, 2013 [Page 5]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+4.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "json-pointer", which is defined below. Other
+ fragment resolution protocols MAY be used, but are not defined in
+ this document.
+
+ The fragment identifier is based on RFC 3986, Sec 5 [RFC3986], and
+ defines the mechanism for resolving references to entities within a
+ document.
+
+ Note that if the instance is described by a schema providing the a
+ link with "root" relation, or such a link is provided in using the
+ HTTP Link header, then all fragment resolution should be resolved
+ relative to the target of the root link. The only exception to this
+ is the resolution of "root" links themselves.
+
+4.2.1. json-pointer fragment resolution
+
+ The "json-pointer" fragment resolution protocol uses a JSON Pointer
+ [json-pointer] to resolve fragment identifiers in URIs within
+ instance representations.
+
+4.3. media
+
+ The value of this attribute MUST be an object. It MAY contain any of
+ the following properties:
+
+4.3.1. contentEncoding
+
+ The value of this property SHOULD be ignored for any instance that is
+ not a string. If the instance value is a string, this attribute
+ defines that the string SHOULD be interpreted as binary data and
+ decoded using the encoding named by this property. RFC 2045, Sec 6.1
+ [RFC2045] lists the possible values for this property.
+
+4.3.2. mediaType
+
+ The value of this property must be a media type RFC 2046 [RFC2046].
+ This attribute defines the media type of instances which this schema
+ defines.
+
+ If the "contentEncoding" property is not set, but the instance value
+ is a string, then the value of this property SHOULD specify a text
+ document, and the character set SHOULD be considered to be UTF-8.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 6]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ For example:
+
+
+ {
+ "type": "string",
+ "media": {
+ "contentEncoding": "base64",
+ "mediaType": "image/png"
+ }
+ }
+
+
+ Instances described by this schema should be strings, and their
+ values should be interpretable as base64-encoded PNG images.
+
+ Another example:
+
+
+ {
+ "type": "string",
+ "media": {
+ "mediaType": "text/html"
+ }
+ }
+
+
+ Instances described by this schema should be strings containing HTML,
+ using the UTF-8 character set.
+
+4.4. pathStart
+
+ This attribute is a URI that defines what the instance's URI MUST
+ start with in order to validate. The value of the "pathStart"
+ attribute MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
+ relative to the instance's URI.
+
+ When multiple schemas have been referenced for an instance, the user
+ agent can determine if this schema is applicable for a particular
+ instance by determining if the URI of the instance begins with the
+ the value of the "pathStart" attribute. If the URI of the instance
+ does not start with this URI, or if another schema specifies a
+ starting URI that is longer and also matches the instance, this
+ schema SHOULD NOT be considered to describe the instance. Any schema
+ that does not have a pathStart attribute SHOULD be considered
+ applicable to all the instances for which it is referenced.
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 7]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
-4.1.1. Link Description Object
+5. Link Description Object
A link description object is used to describe link relations. In the
context of a schema, it defines the link relations of the instances
@@ -293,7 +405,7 @@ Internet-Draft JSON Schema Media Type September 2012
http://json-schema.org/links (latest version) or
http://json-schema.org/draft-04/links (draft-04 version).
-4.1.1.1. href
+5.1. href
The value of the "href" link description property indicates the
target URI of the related resource. The value of the instance
@@ -332,9 +444,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 6]
+Zyp, et al. Expires June 21, 2013 [Page 8]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
http://somesite.com/45
@@ -344,7 +456,7 @@ Internet-Draft JSON Schema Media Type September 2012
the braces, then the actual instance value SHOULD be used to replace
the braces, rather than a property value.
-4.1.1.1.1. Missing values
+5.1.1. Missing values
Values may only be used for substitution if they are of a scalar type
(string, boolean or number).
@@ -354,7 +466,7 @@ Internet-Draft JSON Schema Media Type September 2012
values were missing, and substitute values MAY be provided from
alternate sources, like user input.
-4.1.1.2. rel
+5.2. rel
The value of the "rel" property indicates the name of the relation to
the target resource. The relation to the target SHOULD be
@@ -388,9 +500,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 7]
+Zyp, et al. Expires June 21, 2013 [Page 9]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
describedBy This indicates the target of the link is a schema
@@ -444,9 +556,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 8]
+Zyp, et al. Expires June 21, 2013 [Page 10]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
And if a collection of instance resources were retrieved with JSON
@@ -474,21 +586,21 @@ Internet-Draft JSON Schema Media Type September 2012
with their use in HTML and the HTTP Link header
[I-D.nottingham-http-link-header].
-4.1.1.3. template
+5.3. template
This property value is a string that defines the templating language
- used in the "href" (Section 4.1.1.1) attribute. If no templating
+ used in the "href" (Section 5.1) attribute. If no templating
language is defined, then the default Link Description Object
- templating language (Section 4.1.1.1) is used.
+ templating language (Section 5.1) is used.
-4.1.1.4. targetSchema
+5.4. targetSchema
This property value is advisory only, and is a schema that defines
the expected structure of the JSON representation of the target of
the link, if the target of the link is returned using JSON
representation.
-4.1.1.5. mediaType
+5.5. mediaType
The value of this property is advisory only, and represents the media
type RFC 2046 [RFC2046], that is expected to be returned when
@@ -500,9 +612,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 9]
+Zyp, et al. Expires June 21, 2013 [Page 11]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
4.01 (advisory content type), or the "type" parameter in the HTTP
@@ -556,9 +668,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 10]
+Zyp, et al. Expires June 21, 2013 [Page 12]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
A visual user agent displaying the item from the above example might
@@ -573,7 +685,7 @@ Internet-Draft JSON Schema Media Type September 2012
SHOULD reject any data that would not have also been interpreted as a
news feed, had it been displayed in the main view.
-4.1.1.6. invalidates
+5.6. invalidates
The value of this property is advisory only, and represents a URI or
set of URIs which may change in response to this link being followed.
@@ -581,7 +693,7 @@ Internet-Draft JSON Schema Media Type September 2012
If this property value is a string, then when the link is followed,
this value should be filled out as a template and resolved to a full
- URI using the same method as used for the "href (Section 4.1.1.1)"
+ URI using the same method as used for the "href (Section 5.1)"
property. Any stored data fetched from a URI matching this value MAY
then be considered out-of-date by the client, and removed from any
cache.
@@ -589,14 +701,14 @@ Internet-Draft JSON Schema Media Type September 2012
If this property is an array, then its entries MUST be strings, each
of which is treated according to the above behaviour.
-4.1.1.7. Submission Link Properties
+5.7. Submission Link Properties
The following properties also apply to link definition objects, and
provide functionality analogous to HTML forms, in providing a means
for submitting extra (often user supplied) information to send to a
server.
-4.1.1.7.1. method
+5.7.1. method
This attribute defines which method can be used to access the target
resource. In an HTTP environment, this could be "GET" or "POST"
@@ -604,7 +716,7 @@ Internet-Draft JSON Schema Media Type September 2012
are clearly implied by accessed resources, and do not need to be
defined here). This defaults to "GET".
-4.1.1.7.2. encType
+5.7.2. encType
If present, this property indicates a query media type format that
the server supports for querying or posting to the collection of
@@ -612,9 +724,9 @@ Internet-Draft JSON Schema Media Type September 2012
-Zyp, et al. Expires March 30, 2013 [Page 11]
+Zyp, et al. Expires June 21, 2013 [Page 13]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
target URI to query the collection with property-based constraints on
@@ -651,148 +763,29 @@ Internet-Draft JSON Schema Media Type September 2012
by the href property is defined. If the method is POST,
"application/json" is the default media type.
-4.1.1.7.3. schema
+5.7.3. schema
This attribute contains a schema which defines the acceptable
structure of the submitted request. For a GET request, this schema
would define the properties for the query string and for a POST
request, this would define the body.
-4.2. fragmentResolution
-
- This property indicates the fragment resolution protocol to use for
- resolving fragment identifiers in URIs within the instance
- representations. This applies to the instance object URIs and all
- children of the instance object's URIs. The default fragment
- resolution protocol is "json-pointer", which is defined below. Other
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 12]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
- fragment resolution protocols MAY be used, but are not defined in
- this document.
-
- The fragment identifier is based on RFC 3986, Sec 5 [RFC3986], and
- defines the mechanism for resolving references to entities within a
- document.
-
- Note that if the instance is described by a schema providing the a
- link with "root" relation, or such a link is provided in using the
- HTTP Link header, then all fragment resolution should be resolved
- relative to the target of the root link. The only exception to this
- is the resolution of "root" links themselves.
-
-4.2.1. json-pointer fragment resolution
-
- The "json-pointer" fragment resolution protocol uses a JSON Pointer
- [json-pointer] to resolve fragment identifiers in URIs within
- instance representations.
-
-4.3. media
-
- The value of this attribute MUST be an object. It MAY contain any of
- the following properties:
-
-4.3.1. contentEncoding
-
- The value of this property SHOULD be ignored for any instance that is
- not a string. If the instance value is a string, this attribute
- defines that the string SHOULD be interpreted as binary data and
- decoded using the encoding named by this property. RFC 2045, Sec 6.1
- [RFC2045] lists the possible values for this property.
-
-4.3.2. mediaType
-
- The value of this property must be a media type RFC 2046 [RFC2046].
- This attribute defines the media type of instances which this schema
- defines.
-
- If the "contentEncoding" property is not set, but the instance value
- is a string, then the value of this property SHOULD specify a text
- document, and the character set SHOULD be considered to be UTF-8.
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 13]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
- For example:
-
-
- {
- "type": "string",
- "media": {
- "contentEncoding": "base64",
- "mediaType": "image/png"
- }
- }
-
-
- Instances described by this schema should be strings, and their
- values should be interpretable as base64-encoded PNG images.
-
- Another example:
-
-
- {
- "type": "string",
- "media": {
- "mediaType": "text/html"
- }
- }
-
-
- Instances described by this schema should be strings containing HTML,
- using the UTF-8 character set.
-
-4.4. pathStart
-
- This attribute is a URI that defines what the instance's URI MUST
- start with in order to validate. The value of the "pathStart"
- attribute MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
- relative to the instance's URI.
-
- When multiple schemas have been referenced for an instance, the user
- agent can determine if this schema is applicable for a particular
- instance by determining if the URI of the instance begins with the
- the value of the "pathStart" attribute. If the URI of the instance
- does not start with this URI, or if another schema specifies a
- starting URI that is longer and also matches the instance, this
- schema SHOULD NOT be considered to describe the instance. Any schema
- that does not have a pathStart attribute SHOULD be considered
- applicable to all the instances for which it is referenced.
-
+6. Security Considerations
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627
+ [RFC4627]. However, there are additional security concerns when
+ using the hyperlink definitions.
-Zyp, et al. Expires March 30, 2013 [Page 14]
+Zyp, et al. Expires June 21, 2013 [Page 14]
-Internet-Draft JSON Schema Media Type September 2012
+Internet-Draft JSON Schema Media Type December 2012
-5. Security Considerations
-
- This specification is a sub-type of the JSON format, and consequently
- the security considerations are generally the same as RFC 4627
- [RFC4627]. However, there are additional security concerns when
- using the hyperlink definitions.
-
-5.1. "self" links
+6.1. "self" links
When link relation of "self" is used to denote a full representation
of an object, the user agent SHOULD NOT consider the representation
@@ -818,29 +811,6 @@ Internet-Draft JSON Schema Media Type September 2012
GET /foo/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 15]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
With a response of:
@@ -864,7 +834,14 @@ Internet-Draft JSON Schema Media Type September 2012
}]
-5.2. "mediaType" property of Link Description Objects
+
+
+Zyp, et al. Expires June 21, 2013 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+6.2. "mediaType" property of Link Description Objects
The "mediaType" property in link definitions defines the expected
format of the link's target. However, this is advisory only, and
@@ -885,22 +862,14 @@ Internet-Draft JSON Schema Media Type September 2012
text), but that could be damaging if a third party were allowed to
provide a different interpretation (such as client-side code).
-5.3. "targetSchema" property of Link Description Objects
+6.3. "targetSchema" property of Link Description Objects
Since, through the "media" keyword, schemas can provide
interpretations of string data, exactly the same considerations apply
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 16]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
for this keyword as for the "mediaType" keyword of Link Description
Objects.
-5.4. "invalidates" property of Link Description Objects
+6.4. "invalidates" property of Link Description Objects
User agents also MUST NOT fetch the target of a link when the
resulting data is validated, unless the user has already explicitly
@@ -913,13 +882,21 @@ Internet-Draft JSON Schema Media Type September 2012
This is to guard against the possibility of tricking user agents into
making requests on behalf of the user, to track their behaviour.
-6. IANA Considerations
+7. IANA Considerations
The proposed MIME media type for JSON Schema is "application/
schema+json".
Type name: application
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 16]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
Subtype name: schema+json
Required parameters: profile
@@ -936,7 +913,7 @@ Internet-Draft JSON Schema Media Type September 2012
additional whitespace has been included to make the JSON
representation easier to read.
-6.1. Registry of Link Relations
+7.1. Registry of Link Relations
This registry is maintained by IANA per RFC 4287 [RFC4287] and this
specification adds four values: "full", "create", "instances",
@@ -944,16 +921,9 @@ Internet-Draft JSON Schema Media Type September 2012
RFC 5226 [RFC5226]. Requests should be made by email to IANA, which
will then forward the request to the IESG, requesting approval.
-7. References
-
+8. References
-
-Zyp, et al. Expires March 30, 2013 [Page 17]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
-7.1. Normative References
+8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail
@@ -975,6 +945,14 @@ Internet-Draft JSON Schema Media Type September 2012
Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 17]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
[RFC4287] Nottingham, M., Ed. and R. Sayre,
Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
@@ -984,7 +962,7 @@ Internet-Draft JSON Schema Media Type September 2012
tools.ietf.org/html/
draft-pbryan-zyp-json-pointer-02>.
-7.2. Informative References
+8.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul,
J., Frystyk, H., Masinter, L.,
@@ -1002,13 +980,6 @@ Internet-Draft JSON Schema Media Type September 2012
Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
-
-
-Zyp, et al. Expires March 30, 2013 [Page 18]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
[RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail
Extensions (MIME) Part Two: Media
@@ -1030,6 +1001,14 @@ Internet-Draft JSON Schema Media Type September 2012
ft-nottingham-http-link-header-10
(work in progress), May 2010.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 18]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I.
Jacobs, "HTML 4.01 Specification",
World Wide Web Consortium Recommen
@@ -1056,15 +1035,6 @@ Appendix A. Change Log
* Capitalised the T in "encType"
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 19]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
* Moved "mediaType" and "contentEncoding" to the new "media"
property
@@ -1087,6 +1057,14 @@ Internet-Draft JSON Schema Media Type September 2012
* Made "root" a relation instead of an attribute.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 19]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
* Removed address values, and MIME media type from format to
reduce confusion (mediaType already exists, so it can be used
for MIME types).
@@ -1112,15 +1090,6 @@ Internet-Draft JSON Schema Media Type September 2012
* Moved "contentEncoding" attribute to hyper schema.
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 20]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
* Added "additionalItems" attribute.
* Added "id" attribute.
@@ -1144,6 +1113,14 @@ Internet-Draft JSON Schema Media Type September 2012
* Added language about using links outside of schemas by
referencing its normative URI.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 20]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
* Added "uniqueItems" attribute.
* Added "targetSchema" attribute to link description object.
@@ -1168,15 +1145,6 @@ Authors' Addresses
EMail: kris@sitepen.com
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 21]
-
-Internet-Draft JSON Schema Media Type September 2012
-
-
Gary Court
Calgary, AB
Canada
@@ -1204,29 +1172,5 @@ Internet-Draft JSON Schema Media Type September 2012
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires March 30, 2013 [Page 22]
+Zyp, et al. Expires June 21, 2013 [Page 21]
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index 22a8622f..c2e65009 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -183,7 +183,7 @@
-
+
The following properties are defined for JSON Schema objects:
@@ -214,301 +214,6 @@
-
-
- A link description object is used to describe link relations.
- In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
- The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
- The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
-
-
-
-
- The value of the "href" link description property indicates the target URI of the related resource.
- The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative URI.
- The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
- Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
-
-
-
- Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
- Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
- The property name between the braces SHOULD be percent encoded (FIXME reference?).
- In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
-
-
- For example, if an href value is defined:
-
-
-
- Then it would be resolved by replace the value of the "id" property value from the instance object.
-
-
-
- If the value of the "id" property was "45", the expanded URI would be:
-
-
-
-
-
- If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
-
-
- Values may only be used for substitution if they are of a scalar type (string, boolean or number).
- In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
-
-
-
-
-
- The value of the "rel" property indicates the name of the relation to the target resource.
- The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
- If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
- A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
-
-
-
- Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287).
- However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
-
-
-
- If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
-
-
-
- This indicates that the target of the link is the full representation for the instance object.
- The instance that contains this link may not be the full representation.
-
-
-
- This indicates the target of the link is a schema describing the instance object.
- This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
-
-
-
- This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
- All other properties of the instance objects can be regarded as meta-data descriptions for the data.
-
-
-
-
-
- The following relations are applicable for schemas (the schema as the "from" resource in the relation):
-
-
-
- This indicates the target resource that represents a collection of instances of a schema.
-
-
- This indicates a target to use for creating new instances of a schema.
- This link definition SHOULD be a submission link with a non-safe method (like POST).
-
-
-
- Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
-
-
-
-
- For example, if a schema is defined:
-
-
-
-
-
-
- And if a collection of instance resources were retrieved with JSON representation:
-
-
-
-
-
- This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
- The "children" collection would be located at "/Resource/?upId=thing".
-
- Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header.
-
-
-
-
- This property value is a string that defines the templating language used in the "href" attribute.
- If no templating language is defined, then the default Link Description Object templating language is used.
-
-
-
-
-
- This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
-
-
-
-
-
- The value of this property is advisory only, and represents the media type RFC 2046, that is expected to be returned when fetching this resource.
- This property value MAY be a media range instead, using the same pattern defined in RFC 2161, section 14.1 - HTTP "Accept" header.
-
-
-
- This property is analogous to the "type" property of <a elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header.
- User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
- When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
-
-
-
- If this property's value is specified, and the link's target is to be obtained using any protocol that supports the HTTP/1.1 "Accept" header RFC 2616, section 14.1, then user agents MAY use the value of this property to aid in the assembly of that header when making the request to the server.
-
-
-
- If this property's value is not specified, then the value should be taken to be "application/json".
-
-
-
-
- For example, if a schema is defined:
-
-
-
-
-
- A suitable instance described by this schema would have four links defined.
- The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
- The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
- The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
-
-
-
- A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
-
-
-
- Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
- The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
-
-
-
-
- The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
-
-
-
- If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href" property.
- Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
-
-
-
- If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
-
-
-
-
-
- The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
-
-
-
-
- This attribute defines which method can be used to access the target resource.
- In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
- This defaults to "GET".
-
-
-
-
-
- If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
- The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
-
-
- For example, with the following schema:
-
-
-
- This indicates that the client can query the server for instances that have a specific name.
-
-
-
- For example:
-
-
-
-
-
- If no encType or method is specified, only the single URI specified by the href property is defined.
- If the method is POST, "application/json" is the default media type.
-
-
-
-
-
- This attribute contains a schema which defines the acceptable structure of the submitted request.
- For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
-
-
-
-
@@ -607,6 +312,302 @@ GET /Resource/
+
+
+ A link description object is used to describe link relations.
+ In the context of a schema, it defines the link relations of the instances of the schema, and can be parameterized by the instance values.
+ The link description format can be used without JSON Schema, and use of this format can be declared by referencing the normative link description schema as the schema for the data structure that uses the links.
+ The URI of the normative link description schema is: http://json-schema.org/links (latest version) or http://json-schema.org/draft-04/links (draft-04 version).
+
+
+
+
+ The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative URI.
+ The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
+ Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+
+
+
+ Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
+ Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
+ The property name between the braces SHOULD be percent encoded (FIXME reference?).
+ In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
+
+
+ For example, if an href value is defined:
+
+
+
+ Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+
+
+ If the value of the "id" property was "45", the expanded URI would be:
+
+
+
+
+
+ If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
+
+
+ Values may only be used for substitution if they are of a scalar type (string, boolean or number).
+ In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
+
+
+
+
+
+ The value of the "rel" property indicates the name of the relation to the target resource.
+ The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
+ If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
+ A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
+
+
+
+ Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see RFC 4287).
+ However, we define these relations here for clarity of normative interpretation within the context of JSON Schema defined relations:
+
+
+
+ If the relation value is "self", when this property is encountered in the instance object, the object represents a resource and the instance object is treated as a full representation of the target resource identified by the specified URI.
+
+
+
+ This indicates that the target of the link is the full representation for the instance object.
+ The instance that contains this link may not be the full representation.
+
+
+
+ This indicates the target of the link is a schema describing the instance object.
+ This MAY be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
+ This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
+ All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+
+
+
+
+
+ The following relations are applicable for schemas (the schema as the "from" resource in the relation):
+
+
+
+ This indicates the target resource that represents a collection of instances of a schema.
+
+
+ This indicates a target to use for creating new instances of a schema.
+ This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+ Links defined in the schema using these relation values SHOULD not require parameterization with data from the instance, as they describe a link for the schema, not the instances.
+
+
+
+
+ For example, if a schema is defined:
+
+
+
+
+
+
+ And if a collection of instance resources were retrieved with JSON representation:
+
+
+
+
+
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+
+ Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header.
+
+
+
+
+ This property value is a string that defines the templating language used in the "href" attribute.
+ If no templating language is defined, then the default Link Description Object templating language is used.
+
+
+
+
+
+ This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
+
+
+
+
+
+ The value of this property is advisory only, and represents the media type RFC 2046, that is expected to be returned when fetching this resource.
+ This property value MAY be a media range instead, using the same pattern defined in RFC 2161, section 14.1 - HTTP "Accept" header.
+
+
+
+ This property is analogous to the "type" property of <a elements in HTML 4.01 (advisory content type), or the "type" parameter in the HTTP Link header.
+ User agents MAY use this information to inform the interface they present to the user before the link is followed, but this information MUST NOT use this information in the interpretation of the resulting data.
+ When deciding how to interpret data obtained through following this link, the behaviour of user agents MUST be identical regardless of the value of the this property.
+
+
+
+ If this property's value is specified, and the link's target is to be obtained using any protocol that supports the HTTP/1.1 "Accept" header RFC 2616, section 14.1, then user agents MAY use the value of this property to aid in the assembly of that header when making the request to the server.
+
+
+
+ If this property's value is not specified, then the value should be taken to be "application/json".
+
+
+
+
+ For example, if a schema is defined:
+
+
+
+
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+
+
+ A visual user agent displaying the item from the above example might present a button representing an RSS feed, which when pressed passes the target URI (calculated "href" value) to an view more suited to displaying it, such as a news feed aggregator tab.
+
+
+
+ Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
+ The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
+
+
+
+
+
+ The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
+
+
+
+ If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href" property.
+ Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
+
+
+
+ If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
+
+
+
+
+
+ The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+ This attribute defines which method can be used to access the target resource.
+ In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
+ This defaults to "GET".
+
+
+
+
+
+ If present, this property indicates a query media type format that the server supports for querying or posting to the collection of instances at the target resource.
+ The query can be suffixed to the target URI to query the collection with property-based constraints on the resources that SHOULD be returned from the server or used to post data to the resource (depending on the method).
+
+
+ For example, with the following schema:
+
+
+
+ This indicates that the client can query the server for instances that have a specific name.
+
+
+
+ For example:
+
+
+
+
+
+ If no encType or method is specified, only the single URI specified by the href property is defined.
+ If the method is POST, "application/json" is the default media type.
+
+
+
+
+
+ This attribute contains a schema which defines the acceptable structure of the submitted request.
+ For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
+
+
+
+
+
This specification is a sub-type of the JSON format, and consequently the security considerations are generally the same as RFC 4627.
From b7a388b11c709ac112e75cebfb1a791dae94c701 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 20:34:02 +0000
Subject: [PATCH 0129/1659] Removed use/definition of "attribute" in favour of
"property"/"keyword"
---
proposals/json-schema-hypermedia.html | 27 +++++++++----------
proposals/json-schema-hypermedia.txt | 38 +++++++++++++--------------
proposals/json-schema-hypermedia.xml | 25 +++++++++---------
3 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index a477d466..283e0f3d 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -310,9 +310,6 @@
- Just as with the core JSON schema attributes, all the attributes described here are optional.
+ Just as with the core JSON schema keywords, all the properties described in the "Schema Keywords" section are optional.
Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
- Addition of attributes provides additive information for user agents.
+ Addition of properties provides additive information for user agents.
An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
@@ -468,7 +465,7 @@
Table of Contents
media
- The value of this attribute MUST be an object. It MAY contain any of the following properties:
+ The value of this properties MUST be an object. It MAY contain any of the following properties:
@@ -478,7 +475,7 @@
Table of Contents
The value of this property SHOULD be ignored for any instance that is not a string.
- If the instance value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
+ If the instance value is a string, this property defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
RFC 2045, Sec 6.1 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] lists the possible values for this property.
- When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
+ When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" property.
If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
- Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
+ Any schema that does not have a pathStart property SHOULD be considered applicable to all the instances for which it is referenced.
@@ -718,7 +715,7 @@
Table of Contents
template
- This property value is a string that defines the templating language used in the "href" (href) attribute.
+ This property value is a string that defines the templating language used in the "href" (href) property.
If no templating language is defined, then the default Link Description Object templating language (href) is used.
@@ -829,7 +826,7 @@
Table of Contents
method
- This attribute defines which method can be used to access the target resource.
+ This property defines which method can be used to access the target resource.
In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
This defaults to "GET".
@@ -882,7 +879,7 @@
Table of Contents
schema
- This attribute contains a schema which defines the acceptable structure of the submitted request.
+ This property contains a schema which defines the acceptable structure of the submitted request.
For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 8f47ef8f..1118e2ca 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -141,8 +141,6 @@ Internet-Draft JSON Schema Media Type December 2012
item Equivalent to "element" as defined in RFC 4627 [RFC4627].
- attribute A property of a JSON Schema object.
-
3. Overview
JSON Schema defines the media type "application/schema+json". JSON
@@ -154,10 +152,12 @@ Internet-Draft JSON Schema Media Type December 2012
hyperlinks on instance data, and to define how to interpret JSON data
as rich multimedia documents.
- Just as with the core JSON schema attributes, all the attributes
- described here are optional. Therefore, an empty object is a valid
- (non-informative) schema, and essentially describes plain JSON.
- Addition of attributes provides additive information for user agents.
+ Just as with the core JSON schema keywords, all the properties
+ described in the "Schema Keywords" section are optional. Therefore,
+ an empty object is a valid (non-informative) schema, and essentially
+ describes plain JSON. Addition of properties provides additive
+ information for user agents.
+
@@ -309,13 +309,13 @@ Internet-Draft JSON Schema Media Type December 2012
4.3. media
- The value of this attribute MUST be an object. It MAY contain any of
- the following properties:
+ The value of this properties MUST be an object. It MAY contain any
+ of the following properties:
4.3.1. contentEncoding
The value of this property SHOULD be ignored for any instance that is
- not a string. If the instance value is a string, this attribute
+ not a string. If the instance value is a string, this property
defines that the string SHOULD be interpreted as binary data and
decoded using the encoding named by this property. RFC 2045, Sec 6.1
[RFC2045] lists the possible values for this property.
@@ -323,7 +323,7 @@ Internet-Draft JSON Schema Media Type December 2012
4.3.2. mediaType
The value of this property must be a media type RFC 2046 [RFC2046].
- This attribute defines the media type of instances which this schema
+ This property defines the media type of instances which this schema
defines.
If the "contentEncoding" property is not set, but the instance value
@@ -368,19 +368,19 @@ Internet-Draft JSON Schema Media Type December 2012
4.4. pathStart
- This attribute is a URI that defines what the instance's URI MUST
+ This property is a URI that defines what the instance's URI MUST
start with in order to validate. The value of the "pathStart"
- attribute MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
+ property MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
relative to the instance's URI.
When multiple schemas have been referenced for an instance, the user
agent can determine if this schema is applicable for a particular
instance by determining if the URI of the instance begins with the
- the value of the "pathStart" attribute. If the URI of the instance
+ the value of the "pathStart" property. If the URI of the instance
does not start with this URI, or if another schema specifies a
starting URI that is longer and also matches the instance, this
schema SHOULD NOT be considered to describe the instance. Any schema
- that does not have a pathStart attribute SHOULD be considered
+ that does not have a pathStart property SHOULD be considered
applicable to all the instances for which it is referenced.
@@ -589,9 +589,9 @@ Internet-Draft JSON Schema Media Type December 2012
5.3. template
This property value is a string that defines the templating language
- used in the "href" (Section 5.1) attribute. If no templating
- language is defined, then the default Link Description Object
- templating language (Section 5.1) is used.
+ used in the "href" (Section 5.1) property. If no templating language
+ is defined, then the default Link Description Object templating
+ language (Section 5.1) is used.
5.4. targetSchema
@@ -710,7 +710,7 @@ Internet-Draft JSON Schema Media Type December 2012
5.7.1. method
- This attribute defines which method can be used to access the target
+ This property defines which method can be used to access the target
resource. In an HTTP environment, this could be "GET" or "POST"
(other HTTP methods such as "PUT" and "DELETE" have semantics that
are clearly implied by accessed resources, and do not need to be
@@ -765,7 +765,7 @@ Internet-Draft JSON Schema Media Type December 2012
5.7.3. schema
- This attribute contains a schema which defines the acceptable
+ This property contains a schema which defines the acceptable
structure of the submitted request. For a GET request, this schema
would define the properties for the query string and for a POST
request, this would define the body.
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index c2e65009..c28b482f 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -106,7 +106,6 @@
target="RFC4627">RFC 4627.Equivalent to "element" as defined in RFC 4627.
- A property of a JSON Schema object.
@@ -120,9 +119,9 @@
This document describes how JSON Schema can be used to define hyperlinks on instance data, and to define how to interpret JSON data as rich multimedia documents.
- Just as with the core JSON schema attributes, all the attributes described here are optional.
+ Just as with the core JSON schema keywords, all the properties described in the "Schema Keywords" section are optional.
Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
- Addition of attributes provides additive information for user agents.
+ Addition of properties provides additive information for user agents.
An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
@@ -242,13 +241,13 @@
- The value of this attribute MUST be an object. It MAY contain any of the following properties:
+ The value of this properties MUST be an object. It MAY contain any of the following properties:
The value of this property SHOULD be ignored for any instance that is not a string.
- If the instance value is a string, this attribute defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
+ If the instance value is a string, this property defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
RFC 2045, Sec 6.1 lists the possible values for this property.
@@ -256,7 +255,7 @@
The value of this property must be a media type RFC 2046.
- This attribute defines the media type of instances which this schema defines.
+ This property defines the media type of instances which this schema defines.
@@ -300,14 +299,14 @@
- This attribute is a URI that defines what the instance's URI MUST start with in order to validate.
- The value of the "pathStart" attribute MUST be resolved as per RFC 3986, Sec 5, and is relative to the instance's URI.
+ This property is a URI that defines what the instance's URI MUST start with in order to validate.
+ The value of the "pathStart" property MUST be resolved as per RFC 3986, Sec 5, and is relative to the instance's URI.
- When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" attribute.
+ When multiple schemas have been referenced for an instance, the user agent can determine if this schema is applicable for a particular instance by determining if the URI of the instance begins with the the value of the "pathStart" property.
If the URI of the instance does not start with this URI, or if another schema specifies a starting URI that is longer and also matches the instance, this schema SHOULD NOT be considered to describe the instance.
- Any schema that does not have a pathStart attribute SHOULD be considered applicable to all the instances for which it is referenced.
+ Any schema that does not have a pathStart property SHOULD be considered applicable to all the instances for which it is referenced.
@@ -457,7 +456,7 @@ GET /Resource/
- This property value is a string that defines the templating language used in the "href" attribute.
+ This property value is a string that defines the templating language used in the "href" property.
If no templating language is defined, then the default Link Description Object templating language is used.
@@ -553,7 +552,7 @@ GET /Resource/
- This attribute defines which method can be used to access the target resource.
+ This property defines which method can be used to access the target resource.
In an HTTP environment, this could be "GET" or "POST" (other HTTP methods such as "PUT" and "DELETE" have semantics that are clearly implied by accessed resources, and do not need to be defined here).
This defaults to "GET".
@@ -601,7 +600,7 @@ GET /Resource/
- This attribute contains a schema which defines the acceptable structure of the submitted request.
+ This property contains a schema which defines the acceptable structure of the submitted request.
For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
From 68aea9a4584aad6c6121af2f9abee3706169b5c5 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 20:37:23 +0000
Subject: [PATCH 0130/1659] Remove definitions in favour of referencing other
specifications.
---
proposals/json-schema-hypermedia.html | 18 +-----------------
proposals/json-schema-hypermedia.txt | 20 ++++++++++----------
proposals/json-schema-hypermedia.xml | 12 +-----------
3 files changed, 12 insertions(+), 38 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index 283e0f3d..808b9e05 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -294,23 +294,7 @@
Table of Contents
- This specification also uses the following defined terms:
-
-
+ The terms "schema", "instance", "property" and "item" are to be interpreted as defined in the JSON Schema core definition [FIXME_LINK].
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 1118e2ca..bc358d6e 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -130,16 +130,9 @@ Internet-Draft JSON Schema Media Type December 2012
and "null" in this document are to be interpreted as defined in RFC
4627 [RFC4627].
- This specification also uses the following defined terms:
-
- schema A JSON Schema object.
-
- instance Equivalent to "JSON value" as defined in RFC 4627
- [RFC4627].
-
- property Equivalent to "member" as defined in RFC 4627 [RFC4627].
-
- item Equivalent to "element" as defined in RFC 4627 [RFC4627].
+ The terms "schema", "instance", "property" and "item" are to be
+ interpreted as defined in the JSON Schema core definition
+ [FIXME_LINK].
3. Overview
@@ -164,6 +157,13 @@ Internet-Draft JSON Schema Media Type December 2012
+
+
+
+
+
+
+
Zyp, et al. Expires June 21, 2013 [Page 3]
Internet-Draft JSON Schema Media Type December 2012
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index c28b482f..cb0aaede 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -96,17 +96,7 @@
- This specification also uses the following defined terms:
-
-
- A JSON Schema object.
- Equivalent to "JSON value" as defined in RFC 4627.
- Equivalent to "member" as defined in RFC 4627.
- Equivalent to "element" as defined in RFC 4627.
-
+ The terms "schema", "instance", "property" and "item" are to be interpreted as defined in the JSON Schema core definition [FIXME_LINK].
From cf028d40d8e3c0cf74fbc3a0f477d3aaa4a872a5 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 21:25:04 +0000
Subject: [PATCH 0131/1659] Re-worded "Overview".
---
proposals/json-schema-hypermedia.html | 175 +++++++------
proposals/json-schema-hypermedia.txt | 354 +++++++++++++++-----------
proposals/json-schema-hypermedia.xml | 60 +++--
3 files changed, 349 insertions(+), 240 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index 808b9e05..e3d68e67 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -199,59 +199,63 @@
- JSON Schema defines the media type "application/schema+json".
- JSON Schemas are also written in JSON and include facilities for describing the structure of JSON data in terms of allowable values, descriptions, and interpreting relations with other resources.
-
-
-
- This document describes how JSON Schema can be used to define hyperlinks on instance data, and to define how to interpret JSON data as rich multimedia documents.
+ This document describes how JSON Schema can be used to define hyperlinks on instance data. It also defines how to provide additional information required to interpret JSON data as rich multimedia documents.
Just as with the core JSON schema keywords, all the properties described in the "Schema Keywords" section are optional.
- Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
- Addition of properties provides additive information for user agents.
+ However, some of the properties of Link Description Objects are not optional.
An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
@@ -331,7 +329,7 @@
- This schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property.
+ This example schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property, specifically that it should be base64-decoded and the resulting binary data treated as a PNG image.
It also defines link relations for the instance, with URIs incorporating values from the instance.
+
+
An example of data following the above schema might be:
+
- In addition to the design considerations for the core JSON Schema specification:
-
+ There are useful conventions when designing APIs, such as representational state transfer (REST), that make them flexible and easy to understand.
+ They use appropriate methods of the protocol to perform actions (for instance, HTTP POST for creating new items), making large portions of the API guessable.
+
- This specification is protocol agnostic.
- The underlying protocol (such as HTTP) should sufficiently define the semantics of the client-server interface, the retrieval of resource representations linked to by JSON representations, and modification of those resources.
- The goal of this format is to sufficiently describe JSON structures such that one can utilize existing information available in existing JSON representations from a large variety of services that leverage a representational state transfer architecture using existing protocols.
-
+ However, if URIs for links are included in the data, the client still needs to know which parts of the data represent links, as opposed to content that merely happens to be in URI form.
+ Also, for some actions (such as a search, or tagging a picture), the parameters that need to be supplied need to be explicitly described, so that clients can be written to supply the correct information.
+
-
+
+ The hyper-schema keywords in this document provide a means of precisely documenting the parameters required, in a machine-readable (and fairly human-friendly) way.
+ This could be used to generate documentation, or even used directly by the client to present interactive options to the user.
+
+
+ This specification also provides a vocabulary to describe JSON data as rich documents containing more than one media type.
+ For instance, an API may be using JSON as a container format, with binary data being transported using base-64 or some other encoding.
+
+
If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
-
+
In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
-
+
The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
+
The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
-
+
6.2.
"mediaType" property of Link Description Objects
@@ -952,7 +983,7 @@
Table of Contents
This is to guard against situations where a source is providing data that is safe when interpreted as the correct type (for example plain text), but that could be damaging if a third party were allowed to provide a different interpretation (such as client-side code).
-
+
6.3.
"targetSchema" property of Link Description Objects
@@ -961,7 +992,7 @@
Table of Contents
Since, through the "media" keyword, schemas can provide interpretations of string data, exactly the same considerations apply for this keyword as for the "mediaType" keyword of Link Description Objects.
-
+
The value of the pretty parameter MAY be true or false to indicate if additional
whitespace has been included to make the JSON representation easier to read.
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index bc358d6e..538d9f1b 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -63,39 +63,39 @@ Table of Contents
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Design Considerations . . . . . . . . . . . . . . . . . . 5
+ 3.1.1. Describing interaction . . . . . . . . . . . . . . . . 5
+ 3.1.2. Hypermedia interpretation . . . . . . . . . . . . . . 5
4. Schema keywords . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 6
- 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 6
- 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 6
- 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 6
- 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 7
+ 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 7
+ 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Link Description Object . . . . . . . . . . . . . . . . . . . 8
5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Missing values . . . . . . . . . . . . . . . . . . . . 9
- 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 5.3. template . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.4. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.5. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.3. template . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.5. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. invalidates . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.7. Submission Link Properties . . . . . . . . . . . . . . . . 13
- 5.7.1. method . . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.7.2. encType . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.7.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 14
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 5.7. Submission Link Properties . . . . . . . . . . . . . . . . 14
+ 5.7.1. method . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.7.2. encType . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.7.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6.1. "self" links . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.2. "mediaType" property of Link Description Objects . . . . . 16
- 6.3. "targetSchema" property of Link Description Objects . . . 16
- 6.4. "invalidates" property of Link Description Objects . . . . 16
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 7.1. Registry of Link Relations . . . . . . . . . . . . . . . . 17
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
- Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
-
-
+ 6.2. "mediaType" property of Link Description Objects . . . . . 17
+ 6.3. "targetSchema" property of Link Description Objects . . . 17
+ 6.4. "invalidates" property of Link Description Objects . . . . 17
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 7.1. Registry of Link Relations . . . . . . . . . . . . . . . . 18
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
@@ -136,20 +136,20 @@ Internet-Draft JSON Schema Media Type December 2012
3. Overview
- JSON Schema defines the media type "application/schema+json". JSON
- Schemas are also written in JSON and include facilities for
- describing the structure of JSON data in terms of allowable values,
- descriptions, and interpreting relations with other resources.
-
This document describes how JSON Schema can be used to define
- hyperlinks on instance data, and to define how to interpret JSON data
- as rich multimedia documents.
+ hyperlinks on instance data. It also defines how to provide
+ additional information required to interpret JSON data as rich
+ multimedia documents.
Just as with the core JSON schema keywords, all the properties
- described in the "Schema Keywords" section are optional. Therefore,
- an empty object is a valid (non-informative) schema, and essentially
- describes plain JSON. Addition of properties provides additive
- information for user agents.
+ described in the "Schema Keywords" section are optional. However,
+ some of the properties of Link Description Objects are not optional.
+
+
+
+
+
+
@@ -184,7 +184,7 @@ Internet-Draft JSON Schema Media Type December 2012
"title": "Article Title",
"type": "string"
},
- "author": {
+ "authorId": {
"type": "integer"
},
"imgData": {
@@ -196,7 +196,7 @@ Internet-Draft JSON Schema Media Type December 2012
}
}
},
- "required" : ["id", "title", "author"],
+ "required" : ["id", "title", "authorId"],
"links": [
{
"rel": "full",
@@ -204,17 +204,17 @@ Internet-Draft JSON Schema Media Type December 2012
},
{
"rel": "author",
- "href": "/user?id={author}"
+ "href": "/user?id={authorId}"
}
]
}
- This schema defines the properties of the instance, as well as a
- hypermedia interpretation for the "imgData" property. It also
- defines link relations for the instance, with URIs incorporating
- values from the instance.
-
+ This example schema defines the properties of the instance, as well
+ as a hypermedia interpretation for the "imgData" property,
+ specifically that it should be base64-decoded and the resulting
+ binary data treated as a PNG image. It also defines link relations
+ for the instance, with URIs incorporating values from the instance.
@@ -225,25 +225,62 @@ Zyp, et al. Expires June 21, 2013 [Page 4]
Internet-Draft JSON Schema Media Type December 2012
+ An example of data following the above schema might be:
+
+
+ {
+ "id": 15,
+ "title": "Example data",
+ "authorId": 105,
+ "imgData": "iVBORw...kJggg=="
+ }
+
+
+ The base-64 data has been abbreviated for readability.
+
3.1. Design Considerations
- In addition to the design considerations for the core JSON Schema
- specification:
+3.1.1. Describing interaction
+
+ There are useful conventions when designing APIs, such as
+ representational state transfer (REST), that make them flexible and
+ easy to understand. They use appropriate methods of the protocol to
+ perform actions (for instance, HTTP POST for creating new items),
+ making large portions of the API guessable.
+
+ However, if URIs for links are included in the data, the client still
+ needs to know which parts of the data represent links, as opposed to
+ content that merely happens to be in URI form. Also, for some
+ actions (such as a search, or tagging a picture), the parameters that
+ need to be supplied need to be explicitly described, so that clients
+ can be written to supply the correct information.
- This specification is protocol agnostic. The underlying protocol
- (such as HTTP) should sufficiently define the semantics of the
- client-server interface, the retrieval of resource representations
- linked to by JSON representations, and modification of those
- resources. The goal of this format is to sufficiently describe JSON
- structures such that one can utilize existing information available
- in existing JSON representations from a large variety of services
- that leverage a representational state transfer architecture using
- existing protocols.
+ The hyper-schema keywords in this document provide a means of
+ precisely documenting the parameters required, in a machine-readable
+ (and fairly human-friendly) way. This could be used to generate
+ documentation, or even used directly by the client to present
+ interactive options to the user.
+
+3.1.2. Hypermedia interpretation
+
+ This specification also provides a vocabulary to describe JSON data
+ as rich documents containing more than one media type. For instance,
+ an API may be using JSON as a container format, with binary data
+ being transported using base-64 or some other encoding.
4. Schema keywords
The following properties are defined for JSON Schema objects:
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 5]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
4.1. links
The property of schemas is used to associate Link Description Options
@@ -269,18 +306,6 @@ Internet-Draft JSON Schema Media Type December 2012
}
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 5]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
4.2. fragmentResolution
This property indicates the fragment resolution protocol to use for
@@ -301,6 +326,17 @@ Internet-Draft JSON Schema Media Type December 2012
relative to the target of the root link. The only exception to this
is the resolution of "root" links themselves.
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 6]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
4.2.1. json-pointer fragment resolution
The "json-pointer" fragment resolution protocol uses a JSON Pointer
@@ -330,13 +366,6 @@ Internet-Draft JSON Schema Media Type December 2012
is a string, then the value of this property SHOULD specify a text
document, and the character set SHOULD be considered to be UTF-8.
-
-
-Zyp, et al. Expires June 21, 2013 [Page 6]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example:
@@ -352,6 +381,18 @@ Internet-Draft JSON Schema Media Type December 2012
Instances described by this schema should be strings, and their
values should be interpretable as base64-encoded PNG images.
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 7]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
Another example:
@@ -383,16 +424,6 @@ Internet-Draft JSON Schema Media Type December 2012
that does not have a pathStart property SHOULD be considered
applicable to all the instances for which it is referenced.
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 7]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
5. Link Description Object
A link description object is used to describe link relations. In the
@@ -410,6 +441,14 @@ Internet-Draft JSON Schema Media Type December 2012
The value of the "href" link description property indicates the
target URI of the related resource. The value of the instance
property SHOULD be resolved as a URI-Reference per RFC 3986 [RFC3986]
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 8]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
and MAY be a relative URI. The base URI to be used for relative
resolution SHOULD be the URI used to retrieve the instance object
(not the schema) when used within a schema. Also, when links are
@@ -442,13 +481,6 @@ Internet-Draft JSON Schema Media Type December 2012
be:
-
-
-Zyp, et al. Expires June 21, 2013 [Page 8]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
http://somesite.com/45
@@ -466,6 +498,13 @@ Internet-Draft JSON Schema Media Type December 2012
values were missing, and substitute values MAY be provided from
alternate sources, like user input.
+
+
+Zyp, et al. Expires June 21, 2013 [Page 9]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
5.2. rel
The value of the "rel" property indicates the name of the relation to
@@ -495,16 +534,6 @@ Internet-Draft JSON Schema Media Type December 2012
representation for the instance object. The instance that
contains this link may not be the full representation.
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 9]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
describedBy This indicates the target of the link is a schema
describing the instance object. This MAY be used to specifically
denote the schemas of objects within a JSON object hierarchy,
@@ -522,6 +551,16 @@ Internet-Draft JSON Schema Media Type December 2012
instances This indicates the target resource that represents a
collection of instances of a schema.
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 10]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
create This indicates a target to use for creating new instances of
a schema. This link definition SHOULD be a submission link with a
non-safe method (like POST).
@@ -547,20 +586,6 @@ Internet-Draft JSON Schema Media Type December 2012
}
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 10]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
And if a collection of instance resources were retrieved with JSON
representation:
@@ -584,6 +609,14 @@ Internet-Draft JSON Schema Media Type December 2012
Note that these relationship values are case-insensitive, consistent
with their use in HTML and the HTTP Link header
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 11]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
[I-D.nottingham-http-link-header].
5.3. template
@@ -609,14 +642,6 @@ Internet-Draft JSON Schema Media Type December 2012
HTTP "Accept" header [RFC2616].
This property is analogous to the "type" property of elements in HTML
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 11]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
4.01 (advisory content type), or the "type" parameter in the HTTP
Link header [I-D.nottingham-http-link-header]. User agents MAY use
this information to inform the interface they present to the user
@@ -635,6 +660,19 @@ Internet-Draft JSON Schema Media Type December 2012
If this property's value is not specified, then the value should be
taken to be "application/json".
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
For example, if a schema is defined:
@@ -665,14 +703,6 @@ Internet-Draft JSON Schema Media Type December 2012
and RSS versions of the current item. The link with a "rel" value of
"icon" links to an image, but does not specify the exact format.
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 12]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
A visual user agent displaying the item from the above example might
present a button representing an RSS feed, which when pressed passes
the target URI (calculated "href" value) to an view more suited to
@@ -691,6 +721,14 @@ Internet-Draft JSON Schema Media Type December 2012
set of URIs which may change in response to this link being followed.
Its value must be either a string or an array.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
If this property value is a string, then when the link is followed,
this value should be filled out as a template and resolved to a full
URI using the same method as used for the "href (Section 5.1)"
@@ -721,18 +759,32 @@ Internet-Draft JSON Schema Media Type December 2012
If present, this property indicates a query media type format that
the server supports for querying or posting to the collection of
instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method).
-Zyp, et al. Expires June 21, 2013 [Page 13]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 14]
Internet-Draft JSON Schema Media Type December 2012
- target URI to query the collection with property-based constraints on
- the resources that SHOULD be returned from the server or used to post
- data to the resource (depending on the method).
-
For example, with the following schema:
@@ -777,18 +829,18 @@ Internet-Draft JSON Schema Media Type December 2012
[RFC4627]. However, there are additional security concerns when
using the hyperlink definitions.
+6.1. "self" links
+
+ When link relation of "self" is used to denote a full representation
+ of an object, the user agent SHOULD NOT consider the representation
-Zyp, et al. Expires June 21, 2013 [Page 14]
+Zyp, et al. Expires June 21, 2013 [Page 15]
Internet-Draft JSON Schema Media Type December 2012
-6.1. "self" links
-
- When link relation of "self" is used to denote a full representation
- of an object, the user agent SHOULD NOT consider the representation
to be the authoritative representation of the resource denoted by the
target URI if the target URI is not equivalent to or a sub-path of
the the URI used to request the resource representation which
@@ -836,7 +888,11 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 15]
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 16]
Internet-Draft JSON Schema Media Type December 2012
@@ -892,7 +948,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 16]
+Zyp, et al. Expires June 21, 2013 [Page 17]
Internet-Draft JSON Schema Media Type December 2012
@@ -948,7 +1004,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 17]
+Zyp, et al. Expires June 21, 2013 [Page 18]
Internet-Draft JSON Schema Media Type December 2012
@@ -1004,7 +1060,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 18]
+Zyp, et al. Expires June 21, 2013 [Page 19]
Internet-Draft JSON Schema Media Type December 2012
@@ -1060,7 +1116,7 @@ Appendix A. Change Log
-Zyp, et al. Expires June 21, 2013 [Page 19]
+Zyp, et al. Expires June 21, 2013 [Page 20]
Internet-Draft JSON Schema Media Type December 2012
@@ -1116,7 +1172,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 20]
+Zyp, et al. Expires June 21, 2013 [Page 21]
Internet-Draft JSON Schema Media Type December 2012
@@ -1172,5 +1228,5 @@ Authors' Addresses
-Zyp, et al. Expires June 21, 2013 [Page 21]
+Zyp, et al. Expires June 21, 2013 [Page 22]
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index cb0aaede..46c70192 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -102,16 +102,11 @@
- JSON Schema defines the media type "application/schema+json".
- JSON Schemas are also written in JSON and include facilities for describing the structure of JSON data in terms of allowable values, descriptions, and interpreting relations with other resources.
-
-
- This document describes how JSON Schema can be used to define hyperlinks on instance data, and to define how to interpret JSON data as rich multimedia documents.
+ This document describes how JSON Schema can be used to define hyperlinks on instance data. It also defines how to provide additional information required to interpret JSON data as rich multimedia documents.
Just as with the core JSON schema keywords, all the properties described in the "Schema Keywords" section are optional.
- Therefore, an empty object is a valid (non-informative) schema, and essentially describes plain JSON.
- Addition of properties provides additive information for user agents.
+ However, some of the properties of Link Description Objects are not optional.
An example JSON Schema defining hyperlinks, and providing hypermedia interpretation for one of the properties is:
@@ -128,7 +123,7 @@
"title": "Article Title",
"type": "string"
},
- "author": {
+ "authorId": {
"type": "integer"
},
"imgData": {
@@ -140,7 +135,7 @@
}
}
},
- "required" : ["id", "title", "author"],
+ "required" : ["id", "title", "authorId"],
"links": [
{
"rel": "full",
@@ -148,27 +143,54 @@
},
{
"rel": "author",
- "href": "/user?id={author}"
+ "href": "/user?id={authorId}"
}
]
}
]]>
- This schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property.
+ This example schema defines the properties of the instance, as well as a hypermedia interpretation for the "imgData" property, specifically that it should be base64-decoded and the resulting binary data treated as a PNG image.
It also defines link relations for the instance, with URIs incorporating values from the instance.
+
+
+ An example of data following the above schema might be:
+
+
+
+ The base-64 data has been abbreviated for readability.
+
-
- In addition to the design considerations for the core JSON Schema specification:
-
-
- This specification is protocol agnostic.
- The underlying protocol (such as HTTP) should sufficiently define the semantics of the client-server interface, the retrieval of resource representations linked to by JSON representations, and modification of those resources.
- The goal of this format is to sufficiently describe JSON structures such that one can utilize existing information available in existing JSON representations from a large variety of services that leverage a representational state transfer architecture using existing protocols.
-
+
+
+ There are useful conventions when designing APIs, such as representational state transfer (REST), that make them flexible and easy to understand.
+ They use appropriate methods of the protocol to perform actions (for instance, HTTP POST for creating new items), making large portions of the API guessable.
+
+
+ However, if URIs for links are included in the data, the client still needs to know which parts of the data represent links, as opposed to content that merely happens to be in URI form.
+ Also, for some actions (such as a search, or tagging a picture), the parameters that need to be supplied need to be explicitly described, so that clients can be written to supply the correct information.
+
+
+ The hyper-schema keywords in this document provide a means of precisely documenting the parameters required, in a machine-readable (and fairly human-friendly) way.
+ This could be used to generate documentation, or even used directly by the client to present interactive options to the user.
+
+
+
+
+ This specification also provides a vocabulary to describe JSON data as rich documents containing more than one media type.
+ For instance, an API may be using JSON as a container format, with binary data being transported using base-64 or some other encoding.
+
+
From c63da7c937f34964f6915b9d00e2cef741754bc1 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 22:51:27 +0000
Subject: [PATCH 0132/1659] Re-wrote some sections, split Security
Considerations up, removed "invalidates"
---
proposals/json-schema-hypermedia.html | 352 +++++++++---------
proposals/json-schema-hypermedia.txt | 498 +++++++++++++-------------
proposals/json-schema-hypermedia.xml | 261 +++++++-------
3 files changed, 556 insertions(+), 555 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index e3d68e67..d953be0c 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -216,7 +216,7 @@
+ When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
+
+
+
+
+Content-Type: application/json; profile=/schema-for-this-data
+
+[{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+}, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+}, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+}]
+
+
5.3.1.
+Security Considerations for "targetSchema"
+
+
+ This property has similar security concerns to that of "mediaType".
+ Clients MUST NOT use the value of this property to aid in the interpretation of the data received in response to following the link, as this leaves "safe" data open to re-interpretation.
+
+
+
+
+
+ For example, suppose two programmers are having a discussion about web security using a text-only message board.
+ Here is some data from that conversation, with a URI of: http://forum.example.com/topics/152/comments/13
+
+
+{
+ "topicId": 152,
+ "commentId": 13,
+ "from": {
+ "name": "Jane",
+ "id": 5
+ },
+ "to": {
+ "name": "Jason",
+ "id": 8
+ },
+ "message": "It's easy, you just add some HTML like this: <script>doSomethingEvil()</script>"
+}
+
+
+
+
+ A third party might then write provide the following Link Description Object at another location:
+
+ If the client used this "targetSchema" value when interpreting the above data, then it might display the contents of "message" as HTML.
+ At this point, the JavaScript embedded in the message might be executed (in the context of the "forum.example.com" domain).
+
+
}, {
"rel": "alternate",
"href": "/{id}/html",
- "mimeType": "text/html"
+ "mediaType": "text/html"
}, {
"rel": "alternate",
"href": "/{id}/rss",
- "mimeType": "application/rss+xml"
+ "mediaType": "application/rss+xml"
}, {
"rel": "icon",
"href": "{id}/icon",
- "mimeType": "image/*"
+ "mediaType": "image/*"
}]
}
- A suitable instance described by this schema would have four links defined.
- The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
- The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
- The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+
@@ -808,36 +909,38 @@
Table of Contents
The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
+
- The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
-
+ The "mediaType" property in link definitions defines the expected format of the link's target.
+ However, this is advisory only, and MUST NOT be considered authoritative.
+
- If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href (href)" property.
- Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
-
+ When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mediaType" property of the link MUST NOT be used.
+ User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
+ If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
+
- If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
-
+ This is to guard against re-interpretation of "safe" data, similar to the precautions for "targetSchema".
+
The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
This property contains a schema which defines the acceptable structure of the submitted request.
For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
-
- When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
-
-
-
-
-Content-Type: application/json; profile=/schema-for-this-data
-
-[{
- "id": "bar",
- "name": "This representation can be safely treated \
- as authoritative "
-}, {
- "id": "/baz",
- "name": "This representation should not be treated as \
- authoritative the user agent should make request the resource\
- from '/baz' to ensure it has the authoritative representation"
-}, {
- "id": "http://othersite.com/something",
- "name": "This representation\
- should also not be treated as authoritative and the target\
- resource representation should be retrieved for the\
- authoritative representation"
-}]
-
-
6.2.
-"mediaType" property of Link Description Objects
-
-
- The "mediaType" property in link definitions defines the expected format of the link's target.
- However, this is advisory only, and MUST NOT be considered authoritative.
- User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
- If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
-
-
-
- When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mimeType" property of the link MUST NOT be used.
-
-
-
- This is to guard against situations where a source is providing data that is safe when interpreted as the correct type (for example plain text), but that could be damaging if a third party were allowed to provide a different interpretation (such as client-side code).
-
-
6.3.
-"targetSchema" property of Link Description Objects
-
-
- Since, through the "media" keyword, schemas can provide interpretations of string data, exactly the same considerations apply for this keyword as for the "mediaType" keyword of Link Description Objects.
-
-
6.4.
-"invalidates" property of Link Description Objects
-
-
- User agents also MUST NOT fetch the target of a link when the resulting data is validated, unless the user has already explicitly or implicitly indicated them to do so.
- If the user's intentions are not known, then the user agent SHOULD NOT refetch the data unless the target of the link is a sub-path of the URI being invalidated.
- (See above for a discussion of how to determine if one path is a sub-path of another.)
-
-
-
- This is to guard against the possibility of tricking user agents into making requests on behalf of the user, to track their behaviour.
-
-
The proposed MIME media type for JSON Schema is "application/schema+json".
@@ -1030,9 +1024,9 @@
Table of Contents
The value of the pretty parameter MAY be true or false to indicate if additional
whitespace has been included to make the JSON representation easier to read.
Replaced "slash-delimited" fragment resolution with
"json-pointer".
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 538d9f1b..8d348aaa 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -71,30 +71,26 @@ Table of Contents
4.2.1. json-pointer fragment resolution . . . . . . . . . . . 7
4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 7
- 4.3.2. mediaType . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.3.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Link Description Object . . . . . . . . . . . . . . . . . . . 8
5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. Missing values . . . . . . . . . . . . . . . . . . . . 9
5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.3. template . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.4. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.5. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.6. invalidates . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.7. Submission Link Properties . . . . . . . . . . . . . . . . 14
- 5.7.1. method . . . . . . . . . . . . . . . . . . . . . . . . 14
- 5.7.2. encType . . . . . . . . . . . . . . . . . . . . . . . 14
- 5.7.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 15
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 6.1. "self" links . . . . . . . . . . . . . . . . . . . . . . . 15
- 6.2. "mediaType" property of Link Description Objects . . . . . 17
- 6.3. "targetSchema" property of Link Description Objects . . . 17
- 6.4. "invalidates" property of Link Description Objects . . . . 17
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 7.1. Registry of Link Relations . . . . . . . . . . . . . . . . 18
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
+ 5.2.1. Security Considerations for "self" links . . . . . . . 12
+ 5.3. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.3.1. Security Considerations for "targetSchema" . . . . . . 13
+ 5.4. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.4.1. Security concerns for "mediaType" . . . . . . . . . . 16
+ 5.5. Submission Link Properties . . . . . . . . . . . . . . . . 16
+ 5.5.1. method . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.5.2. encType . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.5.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 18
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
@@ -108,6 +104,10 @@ Table of Contents
+
+
+
+
Zyp, et al. Expires June 21, 2013 [Page 2]
Internet-Draft JSON Schema Media Type December 2012
@@ -192,7 +192,7 @@ Internet-Draft JSON Schema Media Type December 2012
"type": "string",
"media": {
"contentEncoding": "base64",
- "mediaType": "image/png"
+ "type": "image/png"
}
}
},
@@ -356,7 +356,7 @@ Internet-Draft JSON Schema Media Type December 2012
decoded using the encoding named by this property. RFC 2045, Sec 6.1
[RFC2045] lists the possible values for this property.
-4.3.2. mediaType
+4.3.2. type
The value of this property must be a media type RFC 2046 [RFC2046].
This property defines the media type of instances which this schema
@@ -619,26 +619,172 @@ Internet-Draft JSON Schema Media Type December 2012
[I-D.nottingham-http-link-header].
-5.3. template
+5.2.1. Security Considerations for "self" links
+
+ When link relation of "self" is used to denote a full representation
+ of an object, the user agent SHOULD NOT consider the representation
+ to be the authoritative representation of the resource denoted by the
+ target URI if the target URI is not equivalent to or a sub-path of
+ the the URI used to request the resource representation which
+ contains the target URI with the "self" link.
+
+ For example, if a hyper schema was defined:
+
+
+ {
+ "links": [{
+ "rel": "self",
+ "href": "{id}"
+ }]
+ }
+
+
+ And a resource was requested from somesite.com:
+
+
+ GET /foo/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- This property value is a string that defines the templating language
- used in the "href" (Section 5.1) property. If no templating language
- is defined, then the default Link Description Object templating
- language (Section 5.1) is used.
-5.4. targetSchema
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ With a response of:
+
+
+ Content-Type: application/json; profile=/schema-for-this-data
+
+ [{
+ "id": "bar",
+ "name": "This representation can be safely treated \
+ as authoritative "
+ }, {
+ "id": "/baz",
+ "name": "This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from '/baz' to ensure it has the authoritative representation"
+ }, {
+ "id": "http://othersite.com/something",
+ "name": "This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"
+ }]
+
+
+5.3. targetSchema
This property value is advisory only, and is a schema that defines
the expected structure of the JSON representation of the target of
the link, if the target of the link is returned using JSON
representation.
-5.5. mediaType
+5.3.1. Security Considerations for "targetSchema"
+
+ This property has similar security concerns to that of "mediaType".
+ Clients MUST NOT use the value of this property to aid in the
+ interpretation of the data received in response to following the
+ link, as this leaves "safe" data open to re-interpretation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ For example, suppose two programmers are having a discussion about
+ web security using a text-only message board. Here is some data from
+ that conversation, with a URI of:
+ http://forum.example.com/topics/152/comments/13
+
+{
+ "topicId": 152,
+ "commentId": 13,
+ "from": {
+ "name": "Jane",
+ "id": 5
+ },
+ "to": {
+ "name": "Jason",
+ "id": 8
+ },
+ "message": "It's easy, you just add some HTML like this: "
+}
+
+ A third party might then write provide the following Link Description
+ Object at another location:
+
+ {
+ "rel": "evil-attack",
+ "href": "http://forum.example.com/topics/152/comments/13",
+ "targetSchema": {
+ "properties": {
+ "message": {
+ "description": "Re-interpret the message text as HTML",
+ "media": {
+ "type": "text/html"
+ }
+ }
+ }
+ }
+ }
+
+ If the client used this "targetSchema" value when interpreting the
+ above data, then it might display the contents of "message" as HTML.
+ At this point, the JavaScript embedded in the message might be
+ executed (in the context of the "forum.example.com" domain).
+
+5.4. mediaType
The value of this property is advisory only, and represents the media
type RFC 2046 [RFC2046], that is expected to be returned when
fetching this resource. This property value MAY be a media range
instead, using the same pattern defined in RFC 2161, section 14.1 -
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 14]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
HTTP "Accept" header [RFC2616].
This property is analogous to the "type" property of elements in HTML
@@ -660,19 +806,6 @@ Internet-Draft JSON Schema Media Type December 2012
If this property's value is not specified, then the value should be
taken to be "application/json".
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 12]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, if a schema is defined:
@@ -683,15 +816,15 @@ Internet-Draft JSON Schema Media Type December 2012
}, {
"rel": "alternate",
"href": "/{id}/html",
- "mimeType": "text/html"
+ "mediaType": "text/html"
}, {
"rel": "alternate",
"href": "/{id}/rss",
- "mimeType": "application/rss+xml"
+ "mediaType": "application/rss+xml"
}, {
"rel": "icon",
"href": "{id}/icon",
- "mimeType": "image/*"
+ "mediaType": "image/*"
}]
}
@@ -700,6 +833,14 @@ Internet-Draft JSON Schema Media Type December 2012
defined. The link with a "rel" value of "self" would have an
expected MIME type of "application/json" (the default). The two
links with a "rel" value of "alternate" specify the locations of HTML
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
and RSS versions of the current item. The link with a "rel" value of
"icon" links to an image, but does not specify the exact format.
@@ -715,38 +856,33 @@ Internet-Draft JSON Schema Media Type December 2012
SHOULD reject any data that would not have also been interpreted as a
news feed, had it been displayed in the main view.
-5.6. invalidates
-
- The value of this property is advisory only, and represents a URI or
- set of URIs which may change in response to this link being followed.
- Its value must be either a string or an array.
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 13]
-
-Internet-Draft JSON Schema Media Type December 2012
+5.4.1. Security concerns for "mediaType"
+ The "mediaType" property in link definitions defines the expected
+ format of the link's target. However, this is advisory only, and
+ MUST NOT be considered authoritative.
- If this property value is a string, then when the link is followed,
- this value should be filled out as a template and resolved to a full
- URI using the same method as used for the "href (Section 5.1)"
- property. Any stored data fetched from a URI matching this value MAY
- then be considered out-of-date by the client, and removed from any
- cache.
+ When choosing how to interpret data, the type information provided by
+ the server (or inferred from the filename, or any other usual method)
+ MUST be the only consideration, and the "mediaType" property of the
+ link MUST NOT be used. User agents MAY use this information to
+ determine how they represent the link or where to display it (for
+ example hover-text, opening in a new tab). If user agents decide to
+ pass the link to an external program, they SHOULD first verify that
+ the data is of a type that would normally be passed to that external
+ program.
- If this property is an array, then its entries MUST be strings, each
- of which is treated according to the above behaviour.
+ This is to guard against re-interpretation of "safe" data, similar to
+ the precautions for "targetSchema".
-5.7. Submission Link Properties
+5.5. Submission Link Properties
The following properties also apply to link definition objects, and
provide functionality analogous to HTML forms, in providing a means
for submitting extra (often user supplied) information to send to a
server.
-5.7.1. method
+5.5.1. method
This property defines which method can be used to access the target
resource. In an HTTP environment, this could be "GET" or "POST"
@@ -754,7 +890,14 @@ Internet-Draft JSON Schema Media Type December 2012
are clearly implied by accessed resources, and do not need to be
defined here). This defaults to "GET".
-5.7.2. encType
+
+
+Zyp, et al. Expires June 21, 2013 [Page 16]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+5.5.2. encType
If present, this property indicates a query media type format that
the server supports for querying or posting to the collection of
@@ -763,28 +906,6 @@ Internet-Draft JSON Schema Media Type December 2012
the resources that SHOULD be returned from the server or used to post
data to the resource (depending on the method).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 14]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, with the following schema:
@@ -815,144 +936,30 @@ Internet-Draft JSON Schema Media Type December 2012
by the href property is defined. If the method is POST,
"application/json" is the default media type.
-5.7.3. schema
+5.5.3. schema
This property contains a schema which defines the acceptable
structure of the submitted request. For a GET request, this schema
would define the properties for the query string and for a POST
request, this would define the body.
-6. Security Considerations
-
- This specification is a sub-type of the JSON format, and consequently
- the security considerations are generally the same as RFC 4627
- [RFC4627]. However, there are additional security concerns when
- using the hyperlink definitions.
-
-6.1. "self" links
-
- When link relation of "self" is used to denote a full representation
- of an object, the user agent SHOULD NOT consider the representation
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 15]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
- to be the authoritative representation of the resource denoted by the
- target URI if the target URI is not equivalent to or a sub-path of
- the the URI used to request the resource representation which
- contains the target URI with the "self" link.
-
- For example, if a hyper schema was defined:
-
-
- {
- "links": [{
- "rel": "self",
- "href": "{id}"
- }]
- }
-
-
- And a resource was requested from somesite.com:
-
-
- GET /foo/
- With a response of:
-
- Content-Type: application/json; profile=/schema-for-this-data
- [{
- "id": "bar",
- "name": "This representation can be safely treated \
- as authoritative "
- }, {
- "id": "/baz",
- "name": "This representation should not be treated as \
- authoritative the user agent should make request the resource\
- from '/baz' to ensure it has the authoritative representation"
- }, {
- "id": "http://othersite.com/something",
- "name": "This representation\
- should also not be treated as authoritative and the target\
- resource representation should be retrieved for the\
- authoritative representation"
- }]
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 16]
+Zyp, et al. Expires June 21, 2013 [Page 17]
Internet-Draft JSON Schema Media Type December 2012
-6.2. "mediaType" property of Link Description Objects
-
- The "mediaType" property in link definitions defines the expected
- format of the link's target. However, this is advisory only, and
- MUST NOT be considered authoritative. User agents MAY use this
- information to determine how they represent the link or where to
- display it (for example hover-text, opening in a new tab). If user
- agents decide to pass the link to an external program, they SHOULD
- first verify that the data is of a type that would normally be passed
- to that external program.
-
- When choosing how to interpret data, the type information provided by
- the server (or inferred from the filename, or any other usual method)
- MUST be the only consideration, and the "mimeType" property of the
- link MUST NOT be used.
-
- This is to guard against situations where a source is providing data
- that is safe when interpreted as the correct type (for example plain
- text), but that could be damaging if a third party were allowed to
- provide a different interpretation (such as client-side code).
-
-6.3. "targetSchema" property of Link Description Objects
-
- Since, through the "media" keyword, schemas can provide
- interpretations of string data, exactly the same considerations apply
- for this keyword as for the "mediaType" keyword of Link Description
- Objects.
-
-6.4. "invalidates" property of Link Description Objects
-
- User agents also MUST NOT fetch the target of a link when the
- resulting data is validated, unless the user has already explicitly
- or implicitly indicated them to do so. If the user's intentions are
- not known, then the user agent SHOULD NOT refetch the data unless the
- target of the link is a sub-path of the URI being invalidated. (See
- above for a discussion of how to determine if one path is a sub-path
- of another.)
-
- This is to guard against the possibility of tricking user agents into
- making requests on behalf of the user, to track their behaviour.
-
-7. IANA Considerations
+6. IANA Considerations
The proposed MIME media type for JSON Schema is "application/
schema+json".
Type name: application
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 17]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
Subtype name: schema+json
Required parameters: profile
@@ -969,7 +976,7 @@ Internet-Draft JSON Schema Media Type December 2012
additional whitespace has been included to make the JSON
representation easier to read.
-7.1. Registry of Link Relations
+6.1. Registry of Link Relations
This registry is maintained by IANA per RFC 4287 [RFC4287] and this
specification adds four values: "full", "create", "instances",
@@ -977,9 +984,9 @@ Internet-Draft JSON Schema Media Type December 2012
RFC 5226 [RFC5226]. Requests should be made by email to IANA, which
will then forward the request to the IESG, requesting approval.
-8. References
+7. References
-8.1. Normative References
+7.1. Normative References
[RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail
@@ -994,13 +1001,6 @@ Internet-Draft JSON Schema Media Type December 2012
[RFC3339] Klyne, G., Ed. and C. Newman,
"Date and Time on the Internet:
- Timestamps", RFC 3339, July 2002.
-
- [RFC3986] Berners-Lee, T., Fielding, R., and
- L. Masinter, "Uniform Resource
- Identifier (URI): Generic Syntax",
- STD 66, RFC 3986, January 2005.
-
@@ -1009,6 +1009,13 @@ Zyp, et al. Expires June 21, 2013 [Page 18]
Internet-Draft JSON Schema Media Type December 2012
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
[RFC4287] Nottingham, M., Ed. and R. Sayre,
Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
@@ -1018,7 +1025,7 @@ Internet-Draft JSON Schema Media Type December 2012
tools.ietf.org/html/
draft-pbryan-zyp-json-pointer-02>.
-8.2. Informative References
+7.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul,
J., Frystyk, H., Masinter, L.,
@@ -1050,13 +1057,6 @@ Internet-Draft JSON Schema Media Type December 2012
[I-D.gregorio-uritemplate] Gregorio, J., Fielding, R.,
Hadley, M., Nottingham, M., and D.
Orchard, "URI Template",
- draft-gregorio-uritemplate-08
- (work in progress), January 2012.
-
- [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
- ft-nottingham-http-link-header-10
- (work in progress), May 2010.
-
@@ -1065,6 +1065,13 @@ Zyp, et al. Expires June 21, 2013 [Page 19]
Internet-Draft JSON Schema Media Type December 2012
+ draft-gregorio-uritemplate-08
+ (work in progress), January 2012.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-10
+ (work in progress), May 2010.
+
[W3C.REC-html401-19991224] Hors, A., Raggett, D., and I.
Jacobs, "HTML 4.01 Specification",
World Wide Web Consortium Recommen
@@ -1096,8 +1103,6 @@ Appendix A. Change Log
* Added "mediaType" property to LDOs
- * Added "invalidates" property to LDOs
-
* Replaced "slash-delimited" fragment resolution with "json-
pointer".
@@ -1105,13 +1110,8 @@ Appendix A. Change Log
* Improved wording of sections.
- draft-03
- * Added example and verbiage to "extends" attribute.
-
- * Defined slash-delimited to use a leading slash.
- * Made "root" a relation instead of an attribute.
@@ -1121,6 +1121,14 @@ Zyp, et al. Expires June 21, 2013 [Page 20]
Internet-Draft JSON Schema Media Type December 2012
+ draft-03
+
+ * Added example and verbiage to "extends" attribute.
+
+ * Defined slash-delimited to use a leading slash.
+
+ * Made "root" a relation instead of an attribute.
+
* Removed address values, and MIME media type from format to
reduce confusion (mediaType already exists, so it can be used
for MIME types).
@@ -1159,15 +1167,7 @@ Internet-Draft JSON Schema Media Type December 2012
* Added "$ref" and "$schema" attributes.
- draft-02
-
- * Replaced "maxDecimal" attribute with "divisibleBy" attribute.
- * Added slash-delimited fragment resolution protocol and made it
- the default.
-
- * Added language about using links outside of schemas by
- referencing its normative URI.
@@ -1177,6 +1177,16 @@ Zyp, et al. Expires June 21, 2013 [Page 21]
Internet-Draft JSON Schema Media Type December 2012
+ draft-02
+
+ * Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+
+ * Added slash-delimited fragment resolution protocol and made it
+ the default.
+
+ * Added language about using links outside of schemas by
+ referencing its normative URI.
+
* Added "uniqueItems" attribute.
* Added "targetSchema" attribute to link description object.
@@ -1218,15 +1228,5 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
Zyp, et al. Expires June 21, 2013 [Page 22]
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index 46c70192..66e0af7b 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -131,7 +131,7 @@
"type": "string",
"media": {
"contentEncoding": "base64",
- "mediaType": "image/png"
+ "type": "image/png"
}
}
},
@@ -264,7 +264,7 @@
-
+
The value of this property must be a media type RFC 2046.
This property defines the media type of instances which this schema defines.
@@ -464,19 +464,122 @@ GET /Resource/
The "children" collection would be located at "/Resource/?upId=thing".
Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header.
-
-
-
- This property value is a string that defines the templating language used in the "href" property.
- If no templating language is defined, then the default Link Description Object templating language is used.
-
+
+
+ When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
+
+
+ For example, if a hyper schema was defined:
+
+
+
+
+
+
+ And a resource was requested from somesite.com:
+
+
+
+
+
+
+ With a response of:
+
+
+
+
+
+
This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
+
+
+
+ This property has similar security concerns to that of "mediaType".
+ Clients MUST NOT use the value of this property to aid in the interpretation of the data received in response to following the link, as this leaves "safe" data open to re-interpretation.
+
+
+
+
+ For example, suppose two programmers are having a discussion about web security using a text-only message board.
+ Here is some data from that conversation, with a URI of: http://forum.example.com/topics/152/comments/13
+
+
+doSomethingEvil()"
+}]]>
+
+
+
+
+ A third party might then write provide the following Link Description Object at another location:
+
+
+
+
+
+ If the client used this "targetSchema" value when interpreting the above data, then it might display the contents of "message" as HTML.
+ At this point, the JavaScript embedded in the message might be executed (in the context of the "forum.example.com" domain).
+
+
+
+
@@ -511,25 +614,27 @@ GET /Resource/
}, {
"rel": "alternate",
"href": "/{id}/html",
- "mimeType": "text/html"
+ "mediaType": "text/html"
}, {
"rel": "alternate",
"href": "/{id}/rss",
- "mimeType": "application/rss+xml"
+ "mediaType": "application/rss+xml"
}, {
"rel": "icon",
"href": "{id}/icon",
- "mimeType": "image/*"
+ "mediaType": "image/*"
}]
}
]]>
- A suitable instance described by this schema would have four links defined.
- The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
- The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
- The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
+ A suitable instance described by this schema would have four links defined.
+ The link with a "rel" value of "self" would have an expected MIME type of "application/json" (the default).
+ The two links with a "rel" value of "alternate" specify the locations of HTML and RSS versions of the current item.
+ The link with a "rel" value of "icon" links to an image, but does not specify the exact format.
+
@@ -540,21 +645,23 @@ GET /Resource/
Note that presenting the link in the above manner, or passing the URI to a news feed aggregator view does not constitute interpretation of the data, but an interpretation of the link.
The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
-
-
- The value of this property is advisory only, and represents a URI or set of URIs which may change in response to this link being followed. Its value must be either a string or an array.
-
-
-
- If this property value is a string, then when the link is followed, this value should be filled out as a template and resolved to a full URI using the same method as used for the "href" property.
- Any stored data fetched from a URI matching this value MAY then be considered out-of-date by the client, and removed from any cache.
-
+
+
+ The "mediaType" property in link definitions defines the expected format of the link's target.
+ However, this is advisory only, and MUST NOT be considered authoritative.
+
-
- If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.
-
+
+ When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mediaType" property of the link MUST NOT be used.
+ User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
+ If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
+
+
+
+ This is to guard against re-interpretation of "safe" data, similar to the precautions for "targetSchema".
+
+
@@ -619,103 +726,6 @@ GET /Resource/
-
-
- This specification is a sub-type of the JSON format, and consequently the security considerations are generally the same as RFC 4627.
- However, there are additional security concerns when using the hyperlink definitions.
-
-
-
-
- When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
-
-
- For example, if a hyper schema was defined:
-
-
-
-
-
-
- And a resource was requested from somesite.com:
-
-
-
-
-
-
- With a response of:
-
-
-
-
-
-
-
-
-
- The "mediaType" property in link definitions defines the expected format of the link's target.
- However, this is advisory only, and MUST NOT be considered authoritative.
- User agents MAY use this information to determine how they represent the link or where to display it (for example hover-text, opening in a new tab).
- If user agents decide to pass the link to an external program, they SHOULD first verify that the data is of a type that would normally be passed to that external program.
-
-
-
- When choosing how to interpret data, the type information provided by the server (or inferred from the filename, or any other usual method) MUST be the only consideration, and the "mimeType" property of the link MUST NOT be used.
-
-
-
- This is to guard against situations where a source is providing data that is safe when interpreted as the correct type (for example plain text), but that could be damaging if a third party were allowed to provide a different interpretation (such as client-side code).
-
-
-
-
-
- Since, through the "media" keyword, schemas can provide interpretations of string data, exactly the same considerations apply for this keyword as for the "mediaType" keyword of Link Description Objects.
-
-
-
-
-
- User agents also MUST NOT fetch the target of a link when the resulting data is validated, unless the user has already explicitly or implicitly indicated them to do so.
- If the user's intentions are not known, then the user agent SHOULD NOT refetch the data unless the target of the link is a sub-path of the URI being invalidated.
- (See above for a discussion of how to determine if one path is a sub-path of another.)
-
-
-
- This is to guard against the possibility of tricking user agents into making requests on behalf of the user, to track their behaviour.
-
-
-
-
The proposed MIME media type for JSON Schema is "application/schema+json".Type name: application
@@ -782,7 +792,6 @@ Content-Type: application/json; profile=/schema-for-this-data
Capitalised the T in "encType"Moved "mediaType" and "contentEncoding" to the new "media" propertyAdded "mediaType" property to LDOs
- Added "invalidates" property to LDOsReplaced "slash-delimited" fragment resolution with
"json-pointer".Added "template" LDO attribute.
From 896d933d379ec874cf1a02aa02e771ae3091a1c6 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Tue, 18 Dec 2012 23:43:55 +0000
Subject: [PATCH 0133/1659] Added description of "href" templating (uses RFC
6570 now)
---
proposals/json-schema-hypermedia.html | 214 ++++++++---
proposals/json-schema-hypermedia.txt | 502 ++++++++++++++++----------
proposals/json-schema-hypermedia.xml | 141 ++++++--
3 files changed, 577 insertions(+), 280 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index d953be0c..b54f83ce 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -224,30 +224,30 @@
- The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the "href" link description property is a template used to determine the target URI of the related resource.
The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] and MAY be a relative URI.
- The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
- Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+ The base URI to be used for relative URI resolution SHOULD be the URI used to retrieve the instance object (not the schema).
-
- Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
- Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
- The property name between the braces SHOULD be percent encoded (FIXME reference?).
- In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
+
Then it would be resolved by replace the value of the "id" property value from the instance object.
+
+ For any text that is:
+
+
+
Surrounded by a pair of rounded brackets: ( )
+
+
The closing rounded bracket is not immediately followed by another closing bracket
+
+
The closing rounded bracket is not immediately preceded by an odd number of closing brackets
+
+
The surrounding rounded brackets are themselves contained within a pair of curly brackets: { }
+
+
+
+
+
+ Before using "href" as a template, that section of the text MUST be replaced, according to the following rules:
+
+
+
If the brackets contained no text (the empty string), then they MUST be replaced with "%65mpty" (which is "empty" with a percent-encoded "e")
+
+
Otherwise, the text should be replaced with its percent-encoded equivalent, such that the result is a valid RFC 6570 variable name (note that this includes encoding characters such as "*" and "!")
+
If the value of the "id" property was "45", the expanded URI would be:
+
+ After the above substitutions, if the character "$" (dollar sign) appears within a pair of curly brackets, then it MUST be replaced with the text "%73elf" (which is "self" with a percent-encoded "s").
+
+
+ Note that in the final example, because the "+" was outside the brackets, it remained unescaped, whereas in the fourth example the "+" was escaped.
+
+
+
- If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
-
+
+
+ After pre-processing, the template is filled out using data from the instance.
+ For a given variable name, the value to use is determined as follows:
+
+
+
If the variable name is "%73elf", then the instance value itself MUST be used.
+
+
If the variable name is "%65mpty", then the instances's empty-string ("") property MUST be used (if it exists).
+
+
If the instance is an array, and the variable name is a representation of a positive integer, then the value at the corresponding array index MUST be used (if it exists).
+
+
Otherwise, the variable name should be percent-decoded, and the corresponding object property MUST be used (if it exists).
+
+ When any value referenced by the URI template is null, a boolean or a number, then it should first be converted into a string as follows:
+
+
+
null values SHOULD be replaced by the text "null"
+
+
boolean values SHOULD be replaced by their lower-case equivalents: "true" or "false"
+
+
numbers SHOULD be replaced with their original JSON representation.
+
+
+
+
+
+ In some software environments the original JSON representation of a number will not be available (there is no way to tell the difference between 1.0 and 1), so any reasonable representation should be used.
+ Schema and API authors should bear this in mind, and use other types (such as string or boolean) if the exact representation is important.
+
+
Values may only be used for substitution if they are of a scalar type (string, boolean or number).
+
+ Sometimes, the appropriate values will not be available.
+ For example, the template might specify the use of object properties, but the instance is an array or a string.
+
-
In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
+
+ If any of the values required for the template are not present in the JSON instance, then substitute values MAY be provided from another source (such as default values).
+ Otherwise, the link definition SHOULD be considered not to apply to the instance.
+
This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
-
+
The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
+
The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
-
+
The value of the pretty parameter MAY be true or false to indicate if additional
whitespace has been included to make the JSON representation easier to read.
Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” draft-gregorio-uritemplate-08 (work in progress), January 2012 (TXT).
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 8d348aaa..c21cc8ed 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -75,23 +75,23 @@ Table of Contents
4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Link Description Object . . . . . . . . . . . . . . . . . . . 8
5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.1.1. Missing values . . . . . . . . . . . . . . . . . . . . 9
- 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5.2.1. Security Considerations for "self" links . . . . . . . 12
- 5.3. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.3.1. Security Considerations for "targetSchema" . . . . . . 13
- 5.4. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 14
- 5.4.1. Security concerns for "mediaType" . . . . . . . . . . 16
- 5.5. Submission Link Properties . . . . . . . . . . . . . . . . 16
- 5.5.1. method . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.5.2. encType . . . . . . . . . . . . . . . . . . . . . . . 17
- 5.5.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 18
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
- 7.2. Informative References . . . . . . . . . . . . . . . . . . 19
- Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20
+ 5.1.1. URI Templating . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.2.1. Security Considerations for "self" links . . . . . . . 13
+ 5.3. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.3.1. Security Considerations for "targetSchema" . . . . . . 15
+ 5.4. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.4.1. Security concerns for "mediaType" . . . . . . . . . . 17
+ 5.5. Submission Link Properties . . . . . . . . . . . . . . . . 18
+ 5.5.1. method . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.5.2. encType . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.5.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 20
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
@@ -438,9 +438,9 @@ Internet-Draft JSON Schema Media Type December 2012
5.1. href
- The value of the "href" link description property indicates the
- target URI of the related resource. The value of the instance
- property SHOULD be resolved as a URI-Reference per RFC 3986 [RFC3986]
+ The value of the "href" link description property is a template used
+ to determine the target URI of the related resource. The value of
+ the instance property SHOULD be resolved as a URI-Reference per RFC
@@ -449,54 +449,54 @@ Zyp, et al. Expires June 21, 2013 [Page 8]
Internet-Draft JSON Schema Media Type December 2012
- and MAY be a relative URI. The base URI to be used for relative
- resolution SHOULD be the URI used to retrieve the instance object
- (not the schema) when used within a schema. Also, when links are
- used within a schema, the URI SHOULD be parametrized by the property
- values of the instance object, if property values exist for the
- corresponding variables in the template (otherwise they MAY be
- provided from alternate sources, like user input).
+ 3986 [RFC3986] and MAY be a relative URI. The base URI to be used
+ for relative URI resolution SHOULD be the URI used to retrieve the
+ instance object (not the schema).
- Instance property values SHOULD be substituted into the URIs where
- matching braces ('{', '}') are found surrounding zero or more
- characters, creating an expanded URI. Instance property value
- substitutions are resolved by using the text between the braces to
- denote the property name from the instance to get the value to
- substitute. The property name between the braces SHOULD be percent
- encoded (FIXME reference?). In particular, the character for the
- braces ('{' and '}') as well as the percent sign ('%') MUST be
- encoded, such that decoding the text obtains the correct property
- name.
+5.1.1. URI Templating
- For example, if an href value is defined:
+ The value of "href" is to be used as a URI Template, as defined in
+ RFC 6570 [RFC6570]. However, some special considerations apply:
+5.1.1.1. Pre-processing
- http://somesite.com/{id}
+ The URI Template specification [RFC6570] has a very restrictive set
+ of characters available for variable names. Property names in JSON,
+ however, can be any UTF-8 string. As such, the following pre-
+ processing rules apply:
+5.1.1.1.1. Bracket escaping
- Then it would be resolved by replace the value of the "id" property
- value from the instance object.
+ For any text that is:
- If the value of the "id" property was "45", the expanded URI would
- be:
+ Surrounded by a pair of rounded brackets: ( )
+ The closing rounded bracket is not immediately followed by another
+ closing bracket
- http://somesite.com/45
+ The closing rounded bracket is not immediately preceded by an odd
+ number of closing brackets
+ The surrounding rounded brackets are themselves contained within a
+ pair of curly brackets: { }
- If matching braces are found with the string "@" (no quotes) between
- the braces, then the actual instance value SHOULD be used to replace
- the braces, rather than a property value.
+ Before using "href" as a template, that section of the text MUST be
+ replaced, according to the following rules:
-5.1.1. Missing values
+ If the brackets contained no text (the empty string), then they
+ MUST be replaced with "%65mpty" (which is "empty" with a percent-
+ encoded "e")
- Values may only be used for substitution if they are of a scalar type
- (string, boolean or number).
+ Otherwise, the text should be replaced with its percent-encoded
+ equivalent, such that the result is a valid RFC 6570 variable name
+ (note that this includes encoding characters such as "*" and "!")
+
+5.1.1.1.2. Replacing $
+
+ After the above substitutions, if the character "$" (dollar sign)
+ appears within a pair of curly brackets, then it MUST be replaced
+ with the text "%73elf" (which is "self" with a percent-encoded "s").
- In cases where suitable values do not exist for substitution because
- they are of an incorrect type, then they should be treated as if the
- values were missing, and substitute values MAY be provided from
- alternate sources, like user input.
@@ -505,6 +505,92 @@ Zyp, et al. Expires June 21, 2013 [Page 9]
Internet-Draft JSON Schema Media Type December 2012
+5.1.1.1.3. Examples
+
+ For example, here are some possible values for "href", followed by
+ the results after pre-processing:
+
+
+ Input Output
+ -----------------------------------------
+ "no change" "no change"
+ "(no change)" "(no change)"
+ "{(escape space)}" "{escape%20space}"
+ "{(escape+plus)}" "{escape%2Bplus}"
+ "{(escape*asterisk)}" "{escape%2Aasterisk}"
+ "{(escape(bracket)}" "{escape%28bracket}"
+ "{(escape))bracket)}" "{escape%29bracket}"
+ "{(a (b)))}" "{a%20%28b%29}
+ "{()}" "{%65mpty}
+ "{+$*}" "{+%73elf*}
+ "{+($)*}" "{+%24*}
+
+
+ Note that in the final example, because the "+" was outside the
+ brackets, it remained unescaped, whereas in the fourth example the
+ "+" was escaped.
+
+5.1.1.2. Values for substitution
+
+ After pre-processing, the template is filled out using data from the
+ instance. For a given variable name, the value to use is determined
+ as follows:
+
+ If the variable name is "%73elf", then the instance value itself
+ MUST be used.
+
+ If the variable name is "%65mpty", then the instances's empty-
+ string ("") property MUST be used (if it exists).
+
+ If the instance is an array, and the variable name is a
+ representation of a positive integer, then the value at the
+ corresponding array index MUST be used (if it exists).
+
+ Otherwise, the variable name should be percent-decoded, and the
+ corresponding object property MUST be used (if it exists).
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 10]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+5.1.1.2.1. Converting to strings
+
+ When any value referenced by the URI template is null, a boolean or a
+ number, then it should first be converted into a string as follows:
+
+ null values SHOULD be replaced by the text "null"
+
+ boolean values SHOULD be replaced by their lower-case equivalents:
+ "true" or "false"
+
+ numbers SHOULD be replaced with their original JSON
+ representation.
+
+ In some software environments the original JSON representation of a
+ number will not be available (there is no way to tell the difference
+ between 1.0 and 1), so any reasonable representation should be used.
+ Schema and API authors should bear this in mind, and use other types
+ (such as string or boolean) if the exact representation is important.
+
+5.1.1.3. Missing values
+
+ Sometimes, the appropriate values will not be available. For
+ example, the template might specify the use of object properties, but
+ the instance is an array or a string.
+
+ If any of the values required for the template are not present in the
+ JSON instance, then substitute values MAY be provided from another
+ source (such as default values). Otherwise, the link definition
+ SHOULD be considered not to apply to the instance.
+
5.2. rel
The value of the "rel" property indicates the name of the relation to
@@ -524,6 +610,13 @@ Internet-Draft JSON Schema Media Type December 2012
of normative interpretation within the context of JSON Schema defined
relations:
+
+
+Zyp, et al. Expires June 21, 2013 [Page 11]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
self If the relation value is "self", when this property is
encountered in the instance object, the object represents a
resource and the instance object is treated as a full
@@ -551,23 +644,34 @@ Internet-Draft JSON Schema Media Type December 2012
instances This indicates the target resource that represents a
collection of instances of a schema.
+ create This indicates a target to use for creating new instances of
+ a schema. This link definition SHOULD be a submission link with a
+ non-safe method (like POST).
+
+ Links defined in the schema using these relation values SHOULD not
+ require parameterization with data from the instance, as they
+ describe a link for the schema, not the instances.
+
+
+
+
+
-Zyp, et al. Expires June 21, 2013 [Page 10]
-
-Internet-Draft JSON Schema Media Type December 2012
- create This indicates a target to use for creating new instances of
- a schema. This link definition SHOULD be a submission link with a
- non-safe method (like POST).
- Links defined in the schema using these relation values SHOULD not
- require parameterization with data from the instance, as they
- describe a link for the schema, not the instances.
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2012
+
For example, if a schema is defined:
@@ -609,14 +713,6 @@ Internet-Draft JSON Schema Media Type December 2012
Note that these relationship values are case-insensitive, consistent
with their use in HTML and the HTTP Link header
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 11]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
[I-D.nottingham-http-link-header].
5.2.1. Security Considerations for "self" links
@@ -625,6 +721,14 @@ Internet-Draft JSON Schema Media Type December 2012
of an object, the user agent SHOULD NOT consider the representation
to be the authoritative representation of the resource denoted by the
target URI if the target URI is not equivalent to or a sub-path of
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
the the URI used to request the resource representation which
contains the target URI with the "self" link.
@@ -645,34 +749,6 @@ Internet-Draft JSON Schema Media Type December 2012
GET /foo/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 12]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
With a response of:
@@ -701,6 +777,14 @@ Internet-Draft JSON Schema Media Type December 2012
This property value is advisory only, and is a schema that defines
the expected structure of the JSON representation of the target of
the link, if the target of the link is returned using JSON
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 14]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
representation.
5.3.1. Security Considerations for "targetSchema"
@@ -710,25 +794,6 @@ Internet-Draft JSON Schema Media Type December 2012
interpretation of the data received in response to following the
link, as this leaves "safe" data open to re-interpretation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 13]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, suppose two programmers are having a discussion about
web security using a text-only message board. Here is some data from
that conversation, with a URI of:
@@ -768,6 +833,14 @@ Internet-Draft JSON Schema Media Type December 2012
If the client used this "targetSchema" value when interpreting the
above data, then it might display the contents of "message" as HTML.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
At this point, the JavaScript embedded in the message might be
executed (in the context of the "forum.example.com" domain).
@@ -777,14 +850,6 @@ Internet-Draft JSON Schema Media Type December 2012
type RFC 2046 [RFC2046], that is expected to be returned when
fetching this resource. This property value MAY be a media range
instead, using the same pattern defined in RFC 2161, section 14.1 -
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 14]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
HTTP "Accept" header [RFC2616].
This property is analogous to the "type" property of elements in HTML
@@ -806,6 +871,32 @@ Internet-Draft JSON Schema Media Type December 2012
If this property's value is not specified, then the value should be
taken to be "application/json".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 16]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
For example, if a schema is defined:
@@ -833,14 +924,6 @@ Internet-Draft JSON Schema Media Type December 2012
defined. The link with a "rel" value of "self" would have an
expected MIME type of "application/json" (the default). The two
links with a "rel" value of "alternate" specify the locations of HTML
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 15]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
and RSS versions of the current item. The link with a "rel" value of
"icon" links to an image, but does not specify the exact format.
@@ -862,6 +945,14 @@ Internet-Draft JSON Schema Media Type December 2012
format of the link's target. However, this is advisory only, and
MUST NOT be considered authoritative.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 17]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
When choosing how to interpret data, the type information provided by
the server (or inferred from the filename, or any other usual method)
MUST be the only consideration, and the "mediaType" property of the
@@ -890,13 +981,6 @@ Internet-Draft JSON Schema Media Type December 2012
are clearly implied by accessed resources, and do not need to be
defined here). This defaults to "GET".
-
-
-Zyp, et al. Expires June 21, 2013 [Page 16]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
5.5.2. encType
If present, this property indicates a query media type format that
@@ -906,6 +990,25 @@ Internet-Draft JSON Schema Media Type December 2012
the resources that SHOULD be returned from the server or used to post
data to the resource (depending on the method).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 18]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
For example, with the following schema:
@@ -943,16 +1046,6 @@ Internet-Draft JSON Schema Media Type December 2012
would define the properties for the query string and for a POST
request, this would define the body.
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 17]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
6. IANA Considerations
The proposed MIME media type for JSON Schema is "application/
@@ -964,6 +1057,14 @@ Internet-Draft JSON Schema Media Type December 2012
Required parameters: profile
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 19]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
The value of the profile parameter SHOULD be a URI (relative or
absolute) that refers to the schema used to define the structure of
this structure (the meta-schema). Normally the value would be
@@ -1001,14 +1102,6 @@ Internet-Draft JSON Schema Media Type December 2012
[RFC3339] Klyne, G., Ed. and C. Newman,
"Date and Time on the Internet:
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 18]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
Timestamps", RFC 3339, July 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and
@@ -1020,6 +1113,19 @@ Internet-Draft JSON Schema Media Type December 2012
Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 20]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ [RFC6570] Gregorio, J., Fielding, R.,
+ Hadley, M., Nottingham, M., and D.
+ Orchard, "URI Template", RFC 6570,
+ March 2012.
+
[json-pointer] Bryan, P. and K. Zyp, "JSON
Pointer", October 2011, .
[W3C.CR-CSS21-20070719] Hickson, I., Lie, H., Celik, T.,
@@ -1110,17 +1210,6 @@ Appendix A. Change Log
* Improved wording of sections.
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 20]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
draft-03
* Added example and verbiage to "extends" attribute.
@@ -1135,6 +1224,15 @@ Internet-Draft JSON Schema Media Type December 2012
* Added more explanation of nullability.
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 22]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
* Removed "alternate" attribute.
* Upper cased many normative usages of must, may, and should.
@@ -1167,16 +1265,6 @@ Internet-Draft JSON Schema Media Type December 2012
* Added "$ref" and "$schema" attributes.
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 21]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
draft-02
* Replaced "maxDecimal" attribute with "divisibleBy" attribute.
@@ -1191,6 +1279,16 @@ Internet-Draft JSON Schema Media Type December 2012
* Added "targetSchema" attribute to link description object.
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 23]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
draft-01
* Fixed category and updates from template.
@@ -1228,5 +1326,19 @@ Authors' Addresses
-Zyp, et al. Expires June 21, 2013 [Page 22]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 21, 2013 [Page 24]
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index 66e0af7b..2dd6d3ca 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -10,8 +10,8 @@
+
-
@@ -333,43 +333,116 @@
- The value of the "href" link description property indicates the target URI of the related resource.
+ The value of the "href" link description property is a template used to determine the target URI of the related resource.
The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative URI.
- The base URI to be used for relative resolution SHOULD be the URI used to retrieve the instance object (not the schema) when used within a schema.
- Also, when links are used within a schema, the URI SHOULD be parametrized by the property values of the instance object, if property values exist for the corresponding variables in the template (otherwise they MAY be provided from alternate sources, like user input).
+ The base URI to be used for relative URI resolution SHOULD be the URI used to retrieve the instance object (not the schema).
-
-
- Instance property values SHOULD be substituted into the URIs where matching braces ('{', '}') are found surrounding zero or more characters, creating an expanded URI.
- Instance property value substitutions are resolved by using the text between the braces to denote the property name from the instance to get the value to substitute.
- The property name between the braces SHOULD be percent encoded (FIXME reference?).
- In particular, the character for the braces ('{' and '}') as well as the percent sign ('%') MUST be encoded, such that decoding the text obtains the correct property name.
-
-
- For example, if an href value is defined:
-
-
-
- Then it would be resolved by replace the value of the "id" property value from the instance object.
-
-
-
- If the value of the "id" property was "45", the expanded URI would be:
-
+
+
+
+ The value of "href" is to be used as a URI Template, as defined in RFC 6570. However, some special considerations apply:
+
+
+
+
+ The URI Template specification has a very restrictive set of characters available for variable names.
+ Property names in JSON, however, can be any UTF-8 string. As such, the following pre-processing rules apply:
+
+
+
+
+ For any text that is:
+
+ Surrounded by a pair of rounded brackets: ( )
+ The closing rounded bracket is not immediately followed by another closing bracket
+ The closing rounded bracket is not immediately preceded by an odd number of closing brackets
+ The surrounding rounded brackets are themselves contained within a pair of curly brackets: { }
+
+
+
+ Before using "href" as a template, that section of the text MUST be replaced, according to the following rules:
+
+ If the brackets contained no text (the empty string), then they MUST be replaced with "%65mpty" (which is "empty" with a percent-encoded "e")
+ Otherwise, the text should be replaced with its percent-encoded equivalent, such that the result is a valid RFC 6570 variable name (note that this includes encoding characters such as "*" and "!")
+
+
+
+
+
+
+ After the above substitutions, if the character "$" (dollar sign) appears within a pair of curly brackets, then it MUST be replaced with the text "%73elf" (which is "self" with a percent-encoded "s").
+
+
+
+
+
+ For example, here are some possible values for "href", followed by the results after pre-processing:
+
-
-
-
- If matching braces are found with the string "@" (no quotes) between the braces, then the actual instance value SHOULD be used to replace the braces, rather than a property value.
-
-
- Values may only be used for substitution if they are of a scalar type (string, boolean or number).
- In cases where suitable values do not exist for substitution because they are of an incorrect type, then they should be treated as if the values were missing, and substitute values MAY be provided from alternate sources, like user input.
+
+
+ Note that in the final example, because the "+" was outside the brackets, it remained unescaped, whereas in the fourth example the "+" was escaped.
+
+
+
+
+
+
+
+
+ After pre-processing, the template is filled out using data from the instance.
+ For a given variable name, the value to use is determined as follows:
+
+ If the variable name is "%73elf", then the instance value itself MUST be used.
+ If the variable name is "%65mpty", then the instances's empty-string ("") property MUST be used (if it exists).
+ If the instance is an array, and the variable name is a representation of a positive integer, then the value at the corresponding array index MUST be used (if it exists).
+ Otherwise, the variable name should be percent-decoded, and the corresponding object property MUST be used (if it exists).
+
+
+
+
+
+ When any value referenced by the URI template is null, a boolean or a number, then it should first be converted into a string as follows:
+
+ null values SHOULD be replaced by the text "null"
+ boolean values SHOULD be replaced by their lower-case equivalents: "true" or "false"
+ numbers SHOULD be replaced with their original JSON representation.
+
+
+
+ In some software environments the original JSON representation of a number will not be available (there is no way to tell the difference between 1.0 and 1), so any reasonable representation should be used.
+ Schema and API authors should bear this in mind, and use other types (such as string or boolean) if the exact representation is important.
+
+
+
+
+
+
+ Sometimes, the appropriate values will not be available.
+ For example, the template might specify the use of object properties, but the instance is an array or a string.
+
+
+
+ If any of the values required for the template are not present in the JSON instance, then substitute values MAY be provided from another source (such as default values).
+ Otherwise, the link definition SHOULD be considered not to apply to the instance.
+
+
+
@@ -757,6 +830,7 @@ Content-Type: application/json; profile=/schema-for-this-data
&rfc3339;
&rfc3986;
&rfc4287;
+ &rfc6570;
JSON Pointer
@@ -776,7 +850,6 @@ Content-Type: application/json; profile=/schema-for-this-data
&rfc5226;
&rfc2046;
&iddiscovery;
- &uritemplate;
&linkheader;
&html401;
&css21;
From 0344ed51953c8ed5bfd5d89e80cd99ac3b42b996 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Wed, 19 Dec 2012 00:54:37 +0000
Subject: [PATCH 0134/1659] Expanded "rel" section, some formatting tweaks
---
proposals/json-schema-hypermedia.html | 323 ++++++++++---
proposals/json-schema-hypermedia.txt | 664 +++++++++++++++-----------
proposals/json-schema-hypermedia.xml | 226 +++++++--
3 files changed, 826 insertions(+), 387 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index b54f83ce..f07a7f27 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -145,8 +145,8 @@
Internet Engineering Task Force
K. Zyp, Ed.
Internet-Draft
SitePen (USA)
Intended status: Informational
G. Court
-
Expires: June 21, 2013
G. Luff
-
December 18, 2012
+
Expires: June 22, 2013
G. Luff
+
December 19, 2012
Hyperlinks and media for JSON Schema draft-zyp-json-hyper-schema-04
@@ -172,7 +172,7 @@
Status of This Memo
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 June 21, 2013.
+This Internet-Draft will expire on June 22, 2013.
The property of schemas is used to associate Link Description Options with instances. The value of this property MUST be an array, and the items in the array must be Link Description Objects, as defined below.
-
An example schema using the links keywords could be:
+
An example schema using the "links" keywords could be:
+ A single URI might have more than one role with relation to an instance. This is not a problem - the same URI can be used in more than one Link Description Object.
+
+
+ For example, this schema describes a news post, accessed via HTTP.
+ The links describe how to access the comments for a news post, how to search the comments, and how to submit new comments, all with the same URI:
+
+ If the client follows the first link, the URI might be expanded to "/15/comments".
+ For the second link, the method is "GET" (the default for HTTP) so the parameters are added to the URL to produce something like: "/15/comments?searchTerm=JSON&itemsPerPage=50".
+ The third link might have a URI of "/15/comments", but the text content of the new comment is posted as JSON.
+
+
- If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
+ If the "binaryEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document type, and the character set SHOULD be considered to be UTF-8.
After the above substitutions, if the character "$" (dollar sign) appears within a pair of curly brackets, then it MUST be replaced with the text "%73elf" (which is "self" with a percent-encoded "s").
-
+
The value of the "rel" property indicates the name of the relation to the target resource.
+ This property is not optional.
+
+
+
The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
- If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
@@ -760,6 +832,8 @@
Table of Contents
This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+ The URI of this link MUST be a fragment, specifying a location within the instance.
+ If it is not, this link should be ignored.
And if a collection of instance resources were retrieved with JSON representation:
-
GET /Resource/
[{
@@ -819,18 +890,121 @@
Table of Contents
"id": "thing2",
"upId": "parent"
}]
-
- This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
- The "children" collection would be located at "/Resource/?upId=thing".
+
+
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+
+
+ To correctly resolve the URL "http://example.com/data/12345", we must take the "root" link into account. Here are some example URIs, along with the data they would resolve to:
+
+ Because of the "root" link type's effect on URL resolution, it possible to create apparent paradoxes in URI resolution. For example, consider this response from a server:
+
+ The "profile" parameter in the "Content-Type" HTTP header defines the schema to be inside the data itself.
+ But the schema defines a "root" link, which changes the document root, which seems like it should change the target of "#/schema".
+
+
+
+
+
+ To avoid this scenario, the following behaviour is defined: when resolving URIs for schemas, that schema MUST NOT be taken into account when calculating the document root.
+
+
This property value is advisory only, and is a schema that defines the expected structure of the JSON representation of the target of the link, if the target of the link is returned using JSON representation.
-
+
The interpretation of the data itself is performed by the news feed aggregator, which SHOULD reject any data that would not have also been interpreted as a news feed, had it been displayed in the main view.
-
+
The following properties also apply to link definition objects, and provide functionality analogous to HTML forms, in providing a means for submitting extra (often user supplied) information to send to a server.
-
+
For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
-
+
+ Note that this is separate from the URI templating of "href" (which uses data from the instance, not submitted by the user).
+ It is also separate from the "targetSchema" property, which provides a schema for the data that the client should expect to be returned when they follow the link.
+
+
The value of the pretty parameter MAY be true or false to indicate if additional
whitespace has been included to make the JSON representation easier to read.
Moved "mediaType" and "contentEncoding" to the new "media" property
+
Moved "mediaType" and "contentEncoding" to the new "media" property (renamed "type" and "binaryEncoding")
Added "mediaType" property to LDOs
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index c21cc8ed..9339855c 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -4,8 +4,8 @@
Internet Engineering Task Force K. Zyp, Ed.
Internet-Draft SitePen (USA)
Intended status: Informational G. Court
-Expires: June 21, 2013 G. Luff
- December 18, 2012
+Expires: June 22, 2013 G. Luff
+ December 19, 2012
Hyperlinks and media for JSON Schema
@@ -32,7 +32,7 @@ Status of This Memo
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 June 21, 2013.
+ This Internet-Draft will expire on June 22, 2013.
Copyright Notice
@@ -52,7 +52,7 @@ Copyright Notice
-Zyp, et al. Expires June 21, 2013 [Page 1]
+Zyp, et al. Expires June 22, 2013 [Page 1]
Internet-Draft JSON Schema Media Type December 2012
@@ -67,31 +67,33 @@ Table of Contents
3.1.2. Hypermedia interpretation . . . . . . . . . . . . . . 5
4. Schema keywords . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 6
- 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 7
- 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.3.1. contentEncoding . . . . . . . . . . . . . . . . . . . 7
- 4.3.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Link Description Object . . . . . . . . . . . . . . . . . . . 8
- 5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.1.1. URI Templating . . . . . . . . . . . . . . . . . . . . 9
- 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.2.1. Security Considerations for "self" links . . . . . . . 13
- 5.3. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 14
- 5.3.1. Security Considerations for "targetSchema" . . . . . . 15
- 5.4. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.4.1. Security concerns for "mediaType" . . . . . . . . . . 17
- 5.5. Submission Link Properties . . . . . . . . . . . . . . . . 18
- 5.5.1. method . . . . . . . . . . . . . . . . . . . . . . . . 18
- 5.5.2. encType . . . . . . . . . . . . . . . . . . . . . . . 18
- 5.5.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 19
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
- 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 20
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
- 7.2. Informative References . . . . . . . . . . . . . . . . . . 21
- Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
+ 4.1.1. Multiple links per URI . . . . . . . . . . . . . . . . 6
+ 4.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 8
+ 4.2.1. json-pointer fragment resolution . . . . . . . . . . . 8
+ 4.3. media . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.3.1. binaryEncoding . . . . . . . . . . . . . . . . . . . . 8
+ 4.3.2. type . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.4. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Link Description Object . . . . . . . . . . . . . . . . . . . 10
+ 5.1. href . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.1.1. URI Templating . . . . . . . . . . . . . . . . . . . . 10
+ 5.2. rel . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.2.1. Fragment resolution with "root" links . . . . . . . . 15
+ 5.2.2. Security Considerations for "self" links . . . . . . . 16
+ 5.3. targetSchema . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.3.1. Security Considerations for "targetSchema" . . . . . . 17
+ 5.4. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.4.1. Security concerns for "mediaType" . . . . . . . . . . 20
+ 5.5. Submission Link Properties . . . . . . . . . . . . . . . . 20
+ 5.5.1. method . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.5.2. encType . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5.5.3. schema . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
+ 6.1. Registry of Link Relations . . . . . . . . . . . . . . . . 22
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 23
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 24
@@ -106,9 +108,7 @@ Table of Contents
-
-
-Zyp, et al. Expires June 21, 2013 [Page 2]
+Zyp, et al. Expires June 22, 2013 [Page 2]
Internet-Draft JSON Schema Media Type December 2012
@@ -164,7 +164,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 3]
+Zyp, et al. Expires June 22, 2013 [Page 3]
Internet-Draft JSON Schema Media Type December 2012
@@ -191,7 +191,7 @@ Internet-Draft JSON Schema Media Type December 2012
"title": "Article Illustration (small)",
"type": "string",
"media": {
- "contentEncoding": "base64",
+ "binaryEncoding": "base64",
"type": "image/png"
}
}
@@ -220,7 +220,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 4]
+Zyp, et al. Expires June 22, 2013 [Page 4]
Internet-Draft JSON Schema Media Type December 2012
@@ -276,7 +276,7 @@ Internet-Draft JSON Schema Media Type December 2012
-Zyp, et al. Expires June 21, 2013 [Page 5]
+Zyp, et al. Expires June 22, 2013 [Page 5]
Internet-Draft JSON Schema Media Type December 2012
@@ -288,8 +288,7 @@ Internet-Draft JSON Schema Media Type December 2012
items in the array must be Link Description Objects, as defined
below.
- An example schema using the links keywords could be:
-
+ An example schema using the "links" keywords could be:
{
"title": "Schema defining links",
@@ -305,6 +304,101 @@ Internet-Draft JSON Schema Media Type December 2012
]
}
+4.1.1. Multiple links per URI
+
+ A single URI might have more than one role with relation to an
+ instance. This is not a problem - the same URI can be used in more
+ than one Link Description Object.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 6]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ For example, this schema describes a news post, accessed via HTTP.
+ The links describe how to access the comments for a news post, how to
+ search the comments, and how to submit new comments, all with the
+ same URI:
+
+ {
+ "title": "News post",
+ ...
+ "links": [
+ {
+ "rel": "comments",
+ "href": "/{id}/comments"
+ },
+ {
+ "rel": "search",
+ "href": "/{id}/comments",
+ "schema": {
+ "type": "object",
+ "properties": {
+ "searchTerm": {
+ "type": "string"
+ },
+ "itemsPerPage": {
+ "type": "integer",
+ "minimum": 10,
+ "multipleOf": 10,
+ "default": 20
+ }
+ },
+ "required": ["searchTerm"]
+ }
+ },
+ {
+ "rel": "post-comment",
+ "href": "/{id}/comments",
+ "method": "POST",
+ "schema": {
+ "type": "object",
+ "properties": {
+ "message": {
+ "type": "string"
+ }
+ },
+ "required": ["message"]
+ }
+ }
+ ]
+ }
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 7]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ If the client follows the first link, the URI might be expanded to
+ "/15/comments". For the second link, the method is "GET" (the
+ default for HTTP) so the parameters are added to the URL to produce
+ something like: "/15/comments?searchTerm=JSON&itemsPerPage=50". The
+ third link might have a URI of "/15/comments", but the text content
+ of the new comment is posted as JSON.
4.2. fragmentResolution
@@ -326,17 +420,6 @@ Internet-Draft JSON Schema Media Type December 2012
relative to the target of the root link. The only exception to this
is the resolution of "root" links themselves.
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 6]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
4.2.1. json-pointer fragment resolution
The "json-pointer" fragment resolution protocol uses a JSON Pointer
@@ -348,7 +431,7 @@ Internet-Draft JSON Schema Media Type December 2012
The value of this properties MUST be an object. It MAY contain any
of the following properties:
-4.3.1. contentEncoding
+4.3.1. binaryEncoding
The value of this property SHOULD be ignored for any instance that is
not a string. If the instance value is a string, this property
@@ -356,15 +439,26 @@ Internet-Draft JSON Schema Media Type December 2012
decoded using the encoding named by this property. RFC 2045, Sec 6.1
[RFC2045] lists the possible values for this property.
+
+
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 8]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
4.3.2. type
The value of this property must be a media type RFC 2046 [RFC2046].
This property defines the media type of instances which this schema
defines.
- If the "contentEncoding" property is not set, but the instance value
+ If the "binaryEncoding" property is not set, but the instance value
is a string, then the value of this property SHOULD specify a text
- document, and the character set SHOULD be considered to be UTF-8.
+ document type, and the character set SHOULD be considered to be
+ UTF-8.
For example:
@@ -372,8 +466,8 @@ Internet-Draft JSON Schema Media Type December 2012
{
"type": "string",
"media": {
- "contentEncoding": "base64",
- "mediaType": "image/png"
+ "encoding": "base64",
+ "type": "image/png"
}
}
@@ -381,18 +475,6 @@ Internet-Draft JSON Schema Media Type December 2012
Instances described by this schema should be strings, and their
values should be interpretable as base64-encoded PNG images.
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 7]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
Another example:
@@ -415,6 +497,14 @@ Internet-Draft JSON Schema Media Type December 2012
relative to the instance's URI.
When multiple schemas have been referenced for an instance, the user
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 9]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
agent can determine if this schema is applicable for a particular
instance by determining if the URI of the instance begins with the
the value of the "pathStart" property. If the URI of the instance
@@ -441,17 +531,11 @@ Internet-Draft JSON Schema Media Type December 2012
The value of the "href" link description property is a template used
to determine the target URI of the related resource. The value of
the instance property SHOULD be resolved as a URI-Reference per RFC
+ 3986 [RFC3986] and MAY be a relative reference to a URI. The base
+ URI to be used for relative URI resolution SHOULD be the URI used to
+ retrieve the instance object (not the schema).
-
-
-Zyp, et al. Expires June 21, 2013 [Page 8]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
- 3986 [RFC3986] and MAY be a relative URI. The base URI to be used
- for relative URI resolution SHOULD be the URI used to retrieve the
- instance object (not the schema).
+ This property is not optional.
5.1.1. URI Templating
@@ -469,6 +553,14 @@ Internet-Draft JSON Schema Media Type December 2012
For any text that is:
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 10]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
Surrounded by a pair of rounded brackets: ( )
The closing rounded bracket is not immediately followed by another
@@ -497,14 +589,6 @@ Internet-Draft JSON Schema Media Type December 2012
appears within a pair of curly brackets, then it MUST be replaced
with the text "%73elf" (which is "self" with a percent-encoded "s").
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 9]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
5.1.1.1.3. Examples
For example, here are some possible values for "href", followed by
@@ -526,6 +610,13 @@ Internet-Draft JSON Schema Media Type December 2012
"{+($)*}" "{+%24*}
+
+
+Zyp, et al. Expires June 22, 2013 [Page 11]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
Note that in the final example, because the "+" was outside the
brackets, it remained unescaped, whereas in the fourth example the
"+" was escaped.
@@ -549,18 +640,6 @@ Internet-Draft JSON Schema Media Type December 2012
Otherwise, the variable name should be percent-decoded, and the
corresponding object property MUST be used (if it exists).
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 10]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
5.1.1.2.1. Converting to strings
When any value referenced by the URI template is null, a boolean or a
@@ -586,6 +665,14 @@ Internet-Draft JSON Schema Media Type December 2012
example, the template might specify the use of object properties, but
the instance is an array or a string.
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
If any of the values required for the template are not present in the
JSON instance, then substitute values MAY be provided from another
source (such as default values). Otherwise, the link definition
@@ -594,14 +681,14 @@ Internet-Draft JSON Schema Media Type December 2012
5.2. rel
The value of the "rel" property indicates the name of the relation to
- the target resource. The relation to the target SHOULD be
- interpreted as specifically from the instance object that the schema
- (or sub-schema) applies to, not just the top level resource that
- contains the object within its hierarchy. If a resource JSON
- representation contains a sub object with a property interpreted as a
- link, that sub-object holds the relation with the target. A link
- relation from the top level resource to a target MUST be indicated
- with the schema describing the top level JSON representation.
+ the target resource. This property is not optional.
+
+ The relation to the target SHOULD be interpreted as specifically from
+ the instance object that the schema (or sub-schema) applies to, not
+ just the top level resource that contains the object within its
+ hierarchy. A link relation from the top level resource to a target
+ MUST be indicated with the schema describing the top level JSON
+ representation.
Relationship definitions SHOULD NOT be media type dependent, and
users are encouraged to utilize existing accepted relation
@@ -610,13 +697,6 @@ Internet-Draft JSON Schema Media Type December 2012
of normative interpretation within the context of JSON Schema defined
relations:
-
-
-Zyp, et al. Expires June 21, 2013 [Page 11]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
self If the relation value is "self", when this property is
encountered in the instance object, the object represents a
resource and the instance object is treated as a full
@@ -636,9 +716,19 @@ Internet-Draft JSON Schema Media Type December 2012
treated as the root or the body of the representation for the
purposes of user agent interaction or fragment resolution. All
other properties of the instance objects can be regarded as meta-
- data descriptions for the data.
+ data descriptions for the data. The URI of this link MUST be a
+ fragment, specifying a location within the instance. If it is
+ not, this link should be ignored.
The following relations are applicable for schemas (the schema as the
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
"from" resource in the relation):
instances This indicates the target resource that represents a
@@ -652,30 +742,8 @@ Internet-Draft JSON Schema Media Type December 2012
require parameterization with data from the instance, as they
describe a link for the schema, not the instances.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 12]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, if a schema is defined:
-
{
"links": [{
"rel": "self",
@@ -689,11 +757,9 @@ Internet-Draft JSON Schema Media Type December 2012
}]
}
-
And if a collection of instance resources were retrieved with JSON
representation:
-
GET /Resource/
[{
@@ -704,7 +770,6 @@ Internet-Draft JSON Schema Media Type December 2012
"upId": "parent"
}]
-
This would indicate that for the first item in the collection, its
own (self) URI would resolve to "/Resource/thing" and the first
item's "up" relation SHOULD be resolved to the resource at
@@ -712,29 +777,128 @@ Internet-Draft JSON Schema Media Type December 2012
"/Resource/?upId=thing".
Note that these relationship values are case-insensitive, consistent
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 14]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
with their use in HTML and the HTTP Link header
[I-D.nottingham-http-link-header].
-5.2.1. Security Considerations for "self" links
+5.2.1. Fragment resolution with "root" links
+
+ The presence of a link with relation "root" alters what the root of
+ the document is considered to be.
+
+ For example, say we have the following schema:
+
+ {
+ "links": [{
+ "rel": "root",
+ "href": "#/myRootData"
+ }]
+ }
+
+ And the following data, returned from the URI:
+ "http://example.com/data/12345":
+
+ {
+ "myRootData": {
+ "title": "Document title"
+ },
+ "metaData": {
+ ...
+ }
+ }
+
+ To correctly resolve the URL "http://example.com/data/12345", we must
+ take the "root" link into account. Here are some example URIs, along
+ with the data they would resolve to:
+
+
+ URI Data
+ -----------------------------------------------------------------------
+ http://example.com/data/12345 {"title": "Document title"}
+ http://example.com/data/12345#/title "Document title"
+
+
+5.2.1.1. Preventing the URI resolution paradox
+
+ Because of the "root" link type's effect on URL resolution, it
+ possible to create apparent paradoxes in URI resolution. For
+ example, consider this response from a server:
+
+
+
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ Content-Type: application/json; profile=#/schema
+
+ {
+ "myRootData": {
+ "title": "Document title"
+ },
+ "schema": {
+ "type": "object",
+ "properties": {
+ "root": {
+ "title": "Document",
+ "type": "object",
+ "properties": {
+ "title": {"type": "string"}
+ }
+ }
+ },
+ "links": [
+ {
+ "rel": "root",
+ "href": "#/myRootData"
+ }
+ ]
+ }
+ }
+
+
+ The "profile" parameter in the "Content-Type" HTTP header defines the
+ schema to be inside the data itself. But the schema defines a "root"
+ link, which changes the document root, which seems like it should
+ change the target of "#/schema".
+
+ To avoid this scenario, the following behaviour is defined: when
+ resolving URIs for schemas, that schema MUST NOT be taken into
+ account when calculating the document root.
+
+5.2.2. Security Considerations for "self" links
When link relation of "self" is used to denote a full representation
of an object, the user agent SHOULD NOT consider the representation
to be the authoritative representation of the resource denoted by the
target URI if the target URI is not equivalent to or a sub-path of
+ the the URI used to request the resource representation which
+ contains the target URI with the "self" link.
+
+
-Zyp, et al. Expires June 21, 2013 [Page 13]
+
+
+Zyp, et al. Expires June 22, 2013 [Page 16]
Internet-Draft JSON Schema Media Type December 2012
- the the URI used to request the resource representation which
- contains the target URI with the "self" link.
-
For example, if a hyper schema was defined:
-
{
"links": [{
"rel": "self",
@@ -742,7 +906,6 @@ Internet-Draft JSON Schema Media Type December 2012
}]
}
-
And a resource was requested from somesite.com:
@@ -751,7 +914,6 @@ Internet-Draft JSON Schema Media Type December 2012
With a response of:
-
Content-Type: application/json; profile=/schema-for-this-data
[{
@@ -771,20 +933,11 @@ Internet-Draft JSON Schema Media Type December 2012
authoritative representation"
}]
-
5.3. targetSchema
This property value is advisory only, and is a schema that defines
the expected structure of the JSON representation of the target of
the link, if the target of the link is returned using JSON
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 14]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
representation.
5.3.1. Security Considerations for "targetSchema"
@@ -792,6 +945,14 @@ Internet-Draft JSON Schema Media Type December 2012
This property has similar security concerns to that of "mediaType".
Clients MUST NOT use the value of this property to aid in the
interpretation of the data received in response to following the
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 17]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
link, as this leaves "safe" data open to re-interpretation.
For example, suppose two programmers are having a discussion about
@@ -833,14 +994,6 @@ Internet-Draft JSON Schema Media Type December 2012
If the client used this "targetSchema" value when interpreting the
above data, then it might display the contents of "message" as HTML.
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 15]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
At this point, the JavaScript embedded in the message might be
executed (in the context of the "forum.example.com" domain).
@@ -848,6 +1001,14 @@ Internet-Draft JSON Schema Media Type December 2012
The value of this property is advisory only, and represents the media
type RFC 2046 [RFC2046], that is expected to be returned when
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 18]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
fetching this resource. This property value MAY be a media range
instead, using the same pattern defined in RFC 2161, section 14.1 -
HTTP "Accept" header [RFC2616].
@@ -871,32 +1032,6 @@ Internet-Draft JSON Schema Media Type December 2012
If this property's value is not specified, then the value should be
taken to be "application/json".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 16]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, if a schema is defined:
@@ -922,6 +1057,14 @@ Internet-Draft JSON Schema Media Type December 2012
A suitable instance described by this schema would have four links
defined. The link with a "rel" value of "self" would have an
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 19]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
expected MIME type of "application/json" (the default). The two
links with a "rel" value of "alternate" specify the locations of HTML
and RSS versions of the current item. The link with a "rel" value of
@@ -945,14 +1088,6 @@ Internet-Draft JSON Schema Media Type December 2012
format of the link's target. However, this is advisory only, and
MUST NOT be considered authoritative.
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 17]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
When choosing how to interpret data, the type information provided by
the server (or inferred from the filename, or any other usual method)
MUST be the only consideration, and the "mediaType" property of the
@@ -978,6 +1113,14 @@ Internet-Draft JSON Schema Media Type December 2012
This property defines which method can be used to access the target
resource. In an HTTP environment, this could be "GET" or "POST"
(other HTTP methods such as "PUT" and "DELETE" have semantics that
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 20]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
are clearly implied by accessed resources, and do not need to be
defined here). This defaults to "GET".
@@ -990,28 +1133,8 @@ Internet-Draft JSON Schema Media Type December 2012
the resources that SHOULD be returned from the server or used to post
data to the resource (depending on the method).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 18]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
For example, with the following schema:
-
{
"links": [{
"encType": "application/x-www-form-urlencoded",
@@ -1025,7 +1148,6 @@ Internet-Draft JSON Schema Media Type December 2012
}]
}
-
This indicates that the client can query the server for instances
that have a specific name.
@@ -1046,6 +1168,20 @@ Internet-Draft JSON Schema Media Type December 2012
would define the properties for the query string and for a POST
request, this would define the body.
+ Note that this is separate from the URI templating of "href" (which
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 21]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
+ uses data from the instance, not submitted by the user). It is also
+ separate from the "targetSchema" property, which provides a schema
+ for the data that the client should expect to be returned when they
+ follow the link.
+
6. IANA Considerations
The proposed MIME media type for JSON Schema is "application/
@@ -1057,14 +1193,6 @@ Internet-Draft JSON Schema Media Type December 2012
Required parameters: profile
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 19]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
The value of the profile parameter SHOULD be a URI (relative or
absolute) that refers to the schema used to define the structure of
this structure (the meta-schema). Normally the value would be
@@ -1097,6 +1225,14 @@ Internet-Draft JSON Schema Media Type December 2012
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 22]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
Levels", BCP 14, RFC 2119,
March 1997.
@@ -1113,14 +1249,6 @@ Internet-Draft JSON Schema Media Type December 2012
Ed., "The Atom Syndication
Format", RFC 4287, December 2005.
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 20]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
[RFC6570] Gregorio, J., Fielding, R.,
Hadley, M., Nottingham, M., and D.
Orchard, "URI Template", RFC 6570,
@@ -1154,6 +1282,13 @@ Internet-Draft JSON Schema Media Type December 2012
Extensions (MIME) Part Two: Media
Types", RFC 2046, November 1996.
+
+
+Zyp, et al. Expires June 22, 2013 [Page 23]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
[I-D.hammer-discovery] Hammer-Lahav, E., "LRDD: Link-
based Resource Descriptor
Discovery",
@@ -1169,14 +1304,6 @@ Internet-Draft JSON Schema Media Type December 2012
World Wide Web Consortium Recommen
dation REC-html401-19991224,
December 1999, .
[W3C.CR-CSS21-20070719] Hickson, I., Lie, H., Celik, T.,
@@ -1199,7 +1326,7 @@ Appendix A. Change Log
* Capitalised the T in "encType"
* Moved "mediaType" and "contentEncoding" to the new "media"
- property
+ property (renamed "type" and "binaryEncoding")
* Added "mediaType" property to LDOs
@@ -1210,6 +1337,14 @@ Appendix A. Change Log
* Improved wording of sections.
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 24]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
draft-03
* Added example and verbiage to "extends" attribute.
@@ -1224,15 +1359,6 @@ Appendix A. Change Log
* Added more explanation of nullability.
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 22]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
* Removed "alternate" attribute.
* Upper cased many normative usages of must, may, and should.
@@ -1265,6 +1391,16 @@ Internet-Draft JSON Schema Media Type December 2012
* Added "$ref" and "$schema" attributes.
+
+
+
+
+
+Zyp, et al. Expires June 22, 2013 [Page 25]
+
+Internet-Draft JSON Schema Media Type December 2012
+
+
draft-02
* Replaced "maxDecimal" attribute with "divisibleBy" attribute.
@@ -1279,16 +1415,6 @@ Internet-Draft JSON Schema Media Type December 2012
* Added "targetSchema" attribute to link description object.
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 23]
-
-Internet-Draft JSON Schema Media Type December 2012
-
-
draft-01
* Fixed category and updates from template.
@@ -1326,19 +1452,5 @@ Authors' Addresses
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zyp, et al. Expires June 21, 2013 [Page 24]
+Zyp, et al. Expires June 22, 2013 [Page 26]
diff --git a/proposals/json-schema-hypermedia.xml b/proposals/json-schema-hypermedia.xml
index 2dd6d3ca..796f6540 100644
--- a/proposals/json-schema-hypermedia.xml
+++ b/proposals/json-schema-hypermedia.xml
@@ -130,7 +130,7 @@
"title": "Article Illustration (small)",
"type": "string",
"media": {
- "contentEncoding": "base64",
+ "binaryEncoding": "base64",
"type": "image/png"
}
}
@@ -205,10 +205,9 @@
- An example schema using the links keywords could be:
+ An example schema using the "links" keywords could be:
-
+}]]>
-
+
+
+
+ A single URI might have more than one role with relation to an instance. This is not a problem - the same URI can be used in more than one Link Description Object.
+
+
+ For example, this schema describes a news post, accessed via HTTP.
+ The links describe how to access the comments for a news post, how to search the comments, and how to submit new comments, all with the same URI:
+
+
+
+
+
+ If the client follows the first link, the URI might be expanded to "/15/comments".
+ For the second link, the method is "GET" (the default for HTTP) so the parameters are added to the URL to produce something like: "/15/comments?searchTerm=JSON&itemsPerPage=50".
+ The third link might have a URI of "/15/comments", but the text content of the new comment is posted as JSON.
+
+
+
@@ -256,7 +314,7 @@
The value of this properties MUST be an object. It MAY contain any of the following properties:
-
+
The value of this property SHOULD be ignored for any instance that is not a string.
If the instance value is a string, this property defines that the string SHOULD be interpreted as binary data and decoded using the encoding named by this property.
@@ -271,7 +329,7 @@
- If the "contentEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document, and the character set SHOULD be considered to be UTF-8.
+ If the "binaryEncoding" property is not set, but the instance value is a string, then the value of this property SHOULD specify a text document type, and the character set SHOULD be considered to be UTF-8.
@@ -283,8 +341,8 @@
{
"type": "string",
"media": {
- "contentEncoding": "base64",
- "mediaType": "image/png"
+ "binaryEncoding": "base64",
+ "type": "image/png"
}
}
]]>
@@ -334,10 +392,12 @@
The value of the "href" link description property is a template used to determine the target URI of the related resource.
- The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative URI.
+ The value of the instance property SHOULD be resolved as a URI-Reference per RFC 3986 and MAY be a relative reference to a URI.
The base URI to be used for relative URI resolution SHOULD be the URI used to retrieve the instance object (not the schema).
+ This property is not optional.
+
The value of "href" is to be used as a URI Template, as defined in RFC 6570. However, some special considerations apply:
@@ -448,8 +508,11 @@ Input Output
The value of the "rel" property indicates the name of the relation to the target resource.
+ This property is not optional.
+
+
+
The relation to the target SHOULD be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy.
- If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target.
A link relation from the top level resource to a target MUST be indicated with the schema describing the top level JSON representation.
@@ -475,6 +538,8 @@ Input Output
This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution.
All other properties of the instance objects can be regarded as meta-data descriptions for the data.
+ The URI of this link MUST be a fragment, specifying a location within the instance.
+ If it is not, this link should be ignored.
@@ -499,8 +564,7 @@ Input Output
For example, if a schema is defined:
-
+}]]>
And if a collection of instance resources were retrieved with JSON representation:
-
+}]]]>
- This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
- The "children" collection would be located at "/Resource/?upId=thing".
+
+ This would indicate that for the first item in the collection, its own (self) URI would resolve to "/Resource/thing" and the first item's "up" relation SHOULD be resolved to the resource at "/Resource/parent".
+ The "children" collection would be located at "/Resource/?upId=thing".
+ Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header.
+
+
+ The presence of a link with relation "root" alters what the root of the document is considered to be.
+
+
+
+ For example, say we have the following schema:
+
+
+
+
+
+
+
+ And the following data, returned from the URI: "http://example.com/data/12345":
+
+
+
+
+
+
+ To correctly resolve the URL "http://example.com/data/12345", we must take the "root" link into account. Here are some example URIs, along with the data they would resolve to:
+
+
+
+
+
+
+
+
+
+ Because of the "root" link type's effect on URL resolution, it possible to create apparent paradoxes in URI resolution. For example, consider this response from a server:
+
+
+
+
+
+ The "profile" parameter in the "Content-Type" HTTP header defines the schema to be inside the data itself.
+ But the schema defines a "root" link, which changes the document root, which seems like it should change the target of "#/schema".
+
+
+
+
+
+ To avoid this scenario, the following behaviour is defined: when resolving URIs for schemas, that schema MUST NOT be taken into account when calculating the document root.
+
+
+
+
When link relation of "self" is used to denote a full representation of an object, the user agent SHOULD NOT consider the representation to be the authoritative representation of the resource denoted by the target URI if the target URI is not equivalent to or a sub-path of the the URI used to request the resource representation which contains the target URI with the "self" link.
@@ -545,14 +700,12 @@ GET /Resource/
For example, if a hyper schema was defined:
-
+}]]>
@@ -568,8 +721,7 @@ GET /foo/
With a response of:
-
+}]]]>
@@ -758,8 +909,7 @@ Content-Type: application/json; profile=/schema-for-this-data
For example, with the following schema:
-
+}]]>
This indicates that the client can query the server for instances that have a specific name.
@@ -795,6 +944,11 @@ Content-Type: application/json; profile=/schema-for-this-data
This property contains a schema which defines the acceptable structure of the submitted request.
For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.
+
+
+ Note that this is separate from the URI templating of "href" (which uses data from the instance, not submitted by the user).
+ It is also separate from the "targetSchema" property, which provides a schema for the data that the client should expect to be returned when they follow the link.
+
@@ -863,7 +1017,7 @@ Content-Type: application/json; profile=/schema-for-this-data
Split hyper-schema definition out from main schema.Removed "readonly"Capitalised the T in "encType"
- Moved "mediaType" and "contentEncoding" to the new "media" property
+ Moved "mediaType" and "contentEncoding" to the new "media" property (renamed "type" and "binaryEncoding")Added "mediaType" property to LDOsReplaced "slash-delimited" fragment resolution with
"json-pointer".
From cc8a979a1a07a2bd761eb4b2acd622b92c4e87c6 Mon Sep 17 00:00:00 2001
From: Geraint Luff
Date: Wed, 19 Dec 2012 00:55:29 +0000
Subject: [PATCH 0135/1659] Updated text and html
---
proposals/json-schema-hypermedia.html | 2 +-
proposals/json-schema-hypermedia.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/proposals/json-schema-hypermedia.html b/proposals/json-schema-hypermedia.html
index f07a7f27..aa6638db 100644
--- a/proposals/json-schema-hypermedia.html
+++ b/proposals/json-schema-hypermedia.html
@@ -575,7 +575,7 @@
Table of Contents
{
"type": "string",
"media": {
- "encoding": "base64",
+ "binaryEncoding": "base64",
"type": "image/png"
}
}
diff --git a/proposals/json-schema-hypermedia.txt b/proposals/json-schema-hypermedia.txt
index 9339855c..45d14cdc 100644
--- a/proposals/json-schema-hypermedia.txt
+++ b/proposals/json-schema-hypermedia.txt
@@ -466,7 +466,7 @@ Internet-Draft JSON Schema Media Type December 2012
{
"type": "string",
"media": {
- "encoding": "base64",
+ "binaryEncoding": "base64",
"type": "image/png"
}
}
From 7c65ebba7bad02c3c4547ba055df6899283315e0 Mon Sep 17 00:00:00 2001
From: nickl-
Date: Wed, 19 Dec 2012 04:13:10 +0200
Subject: [PATCH 0136/1659] Verify ownership
---
google09cd80b591ceeb46.html | 1 +
1 file changed, 1 insertion(+)
create mode 100644 google09cd80b591ceeb46.html
diff --git a/google09cd80b591ceeb46.html b/google09cd80b591ceeb46.html
new file mode 100644
index 00000000..abe96859
--- /dev/null
+++ b/google09cd80b591ceeb46.html
@@ -0,0 +1 @@
+google-site-verification: google09cd80b591ceeb46.html
\ No newline at end of file
From 170bb4f83a6f0e5036c8055d1c4b3c7bc44cd2a0 Mon Sep 17 00:00:00 2001
From: Kris Zyp
Date: Tue, 22 Nov 2011 14:41:16 -0700
Subject: [PATCH 0137/1659] Added files from json-schema.org
---
address | 12 +
address-v2 | 12 +
address.properties | 9 +
calendar | 20 +
calendar-v2 | 20 +
calendar.properties | 13 +
card | 43 +
card-v2 | 47 +
card.properties | 40 +
draft-zyp-json-schema-00.txt | 1289 +++++++++++++++++++++++++++
draft-zyp-json-schema-00.xml | 897 +++++++++++++++++++
draft-zyp-json-schema-01.html | 1400 +++++++++++++++++++++++++++++
draft-zyp-json-schema-01.txt | 1289 +++++++++++++++++++++++++++
draft-zyp-json-schema-01.xml | 897 +++++++++++++++++++
draft-zyp-json-schema-02.txt | 1345 ++++++++++++++++++++++++++++
draft-zyp-json-schema-02.xml | 931 +++++++++++++++++++
draft-zyp-json-schema-03.txt | 1569 +++++++++++++++++++++++++++++++++
geo | 7 +
geo-v2 | 7 +
geo.properties | 4 +
hyper-schema | 107 +++
hyper-schema-or-uri | 10 +
hyper-schema-v2 | 68 ++
hypertextSchema | 254 ++++++
implementations.html | 22 +
index.html | 27 +
interfaces | 23 +
interfaces-v2 | 23 +
json-ref | 26 +
json-ref-v2 | 26 +
links | 34 +
links-v2 | 35 +
schema | 137 +++
schema-v2 | 165 ++++
schema.properties | 136 +++
schema.type | 73 ++
shared.html | 58 ++
37 files changed, 11075 insertions(+)
create mode 100644 address
create mode 100644 address-v2
create mode 100644 address.properties
create mode 100644 calendar
create mode 100644 calendar-v2
create mode 100644 calendar.properties
create mode 100644 card
create mode 100644 card-v2
create mode 100644 card.properties
create mode 100644 draft-zyp-json-schema-00.txt
create mode 100644 draft-zyp-json-schema-00.xml
create mode 100644 draft-zyp-json-schema-01.html
create mode 100644 draft-zyp-json-schema-01.txt
create mode 100644 draft-zyp-json-schema-01.xml
create mode 100644 draft-zyp-json-schema-02.txt
create mode 100644 draft-zyp-json-schema-02.xml
create mode 100644 draft-zyp-json-schema-03.txt
create mode 100644 geo
create mode 100644 geo-v2
create mode 100644 geo.properties
create mode 100644 hyper-schema
create mode 100644 hyper-schema-or-uri
create mode 100644 hyper-schema-v2
create mode 100644 hypertextSchema
create mode 100644 implementations.html
create mode 100644 index.html
create mode 100644 interfaces
create mode 100644 interfaces-v2
create mode 100644 json-ref
create mode 100644 json-ref-v2
create mode 100644 links
create mode 100644 links-v2
create mode 100644 schema
create mode 100644 schema-v2
create mode 100644 schema.properties
create mode 100644 schema.type
create mode 100644 shared.html
diff --git a/address b/address
new file mode 100644
index 00000000..c553848c
--- /dev/null
+++ b/address
@@ -0,0 +1,12 @@
+{"description":"An Address following the convention of http://microformats.org/wiki/hcard",
+ "type":"object",
+ "properties":{
+ "post-office-box":{"type":"string","requires":"street-address"},
+ "extended-address":{"type":"string","requires":"street-address"},
+ "street-address":{"type":"string","requires":"region"},
+ "locality":{"type":"string","requires":"region", "required":true},
+ "region":{"type":"string","requires":"country-name", "required":true},
+ "postal-code":{"type":"string"},
+ "country-name":{"type":"string", "required":true}
+ }
+}
\ No newline at end of file
diff --git a/address-v2 b/address-v2
new file mode 100644
index 00000000..437da9e4
--- /dev/null
+++ b/address-v2
@@ -0,0 +1,12 @@
+{"description":"An Address following the convention of http://microformats.org/wiki/hcard",
+ "type":"object",
+ "properties":{
+ "post-office-box":{"type":"string","specifity":5,"optional":true},
+ "extended-address":{"type":"string","specifity":5,"optional":true},
+ "street-address":{"type":"string","specifity":4,"optional":true},
+ "locality":{"type":"string","specifity":3},
+ "region":{"type":"string","specifity":2},
+ "postal-code":{"type":"string","optional":true},
+ "country-name":{"type":"string","specifity":1}
+ }
+}
\ No newline at end of file
diff --git a/address.properties b/address.properties
new file mode 100644
index 00000000..fc61ac2b
--- /dev/null
+++ b/address.properties
@@ -0,0 +1,9 @@
+{
+"post-office-box":{"type":"string","specifity":5,"optional":true},
+"extended-address":{"type":"string","specifity":5,"optional":true},
+"street-address":{"type":"string","specifity":4,"optional":true},
+"locality":{"type":"string","specifity":3},
+"region":{"type":"string","specifity":2},
+"postal-code":{"type":"string","optional":true},
+"country-name":{"type":"string","specifity":1}
+}
diff --git a/calendar b/calendar
new file mode 100644
index 00000000..9b02c4d7
--- /dev/null
+++ b/calendar
@@ -0,0 +1,20 @@
+{"description":"A representation of an event",
+ "type":"object",
+ "properties":{
+ "dtstart":{"format":"date-time","type":"string","description":"Event starting time","required":true},
+ "summary":{"type":"string","required":true},
+ "location":{"type":"string"},
+ "url":{"type":"string","format":"url"},
+ "dtend":{"format":"date-time","type":"string","description":"Event ending time"},
+ "duration":{"format":"date","type":"string","description":"Event duration"},
+ "rdate":{"format":"date-time","type":"string","description":"Recurrence date"},
+ "rrule":{"type":"string","description":"Recurrence rule"},
+ "category":{"type":"string"},
+ "description":{"type":"string"},
+ "geo":"http://json-schema.org/geo"
+ }
+}
+
+
+
+
diff --git a/calendar-v2 b/calendar-v2
new file mode 100644
index 00000000..d2503693
--- /dev/null
+++ b/calendar-v2
@@ -0,0 +1,20 @@
+{"description":"A representation of an event",
+ "type":"object",
+ "properties":{
+ "dtstart":{"format":"date-time","type":"string","description":"Event starting time"},
+ "summary":{"type":"string"},
+ "location":{"type":"string","optional":true},
+ "url":{"type":"string","format":"url","optional":true},
+ "dtend":{"format":"date-time","type":"string","description":"Event ending time","optional":true},
+ "duration":{"format":"date","type":"string","description":"Event duration","optional":true},
+ "rdate":{"format":"date-time","type":"string","description":"Recurrence date","optional":true},
+ "rrule":{"type":"string","description":"Recurrence rule","optional":true},
+ "category":{"type":"string","optional":true},
+ "description":{"type":"string","optional":true},
+ "geo":{"type":"object","properties":{"$ref":"http://json-schema.org/geo#properties"},"optional":true}
+ }
+}
+
+
+
+
diff --git a/calendar.properties b/calendar.properties
new file mode 100644
index 00000000..a71520d8
--- /dev/null
+++ b/calendar.properties
@@ -0,0 +1,13 @@
+{
+ "dtstart":{"format":"date-time","type":"string","description":"Event starting time"},
+ "summary":{"type":"string"},
+ "location":{"type":"string","optional":true},
+ "url":{"type":"string","format":"url","optional":true},
+ "dtend":{"format":"date-time","type":"string","description":"Event ending time","optional":true},
+ "duration":{"format":"date","type":"string","description":"Event duration","optional":true},
+ "rdate":{"format":"date-time","type":"string","description":"Recurrence date","optional":true},
+ "rrule":{"type":"string","description":"Recurrence rule","optional":true},
+ "category":{"type":"string","optional":true},
+ "description":{"type":"string","optional":true},
+ "geo":{"type":"object","properties":{"$ref":"http://json-schema.org/geo.properties"},"optional":true}
+ }
diff --git a/card b/card
new file mode 100644
index 00000000..ba47d78b
--- /dev/null
+++ b/card
@@ -0,0 +1,43 @@
+{"description":"A representation of a person, company, organization, or place",
+ "type":"object",
+ "properties":{
+ "fn":{"description":"Formatted Name","type":"string"},
+ "familyName":{"type":"string", "required":true},
+ "givenName":{"type":"string", "required":true},
+ "additionalName":{"type":"array","items":{"type":"string"}},
+ "honorificPrefix":{"type":"array","items":{"type":"string"}},
+ "honorificSuffix":{"type":"array","items":{"type":"string"}},
+ "nickname":{"type":"string"},
+ "url":{"type":"string","format":"url"},
+ "email":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"email"}},
+ },
+ "tel":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"phone"}},
+ },
+ "adr":"http://json-schema.org/address",
+ "geo":"http://json-schema.org/geo",
+ "tz":{"type":"string"},
+ "photo":{"format":"image","type":"string"},
+ "logo":{"format":"image","type":"string"},
+ "sound":{"format":"attachment","type":"string"},
+ "bday":{"type":"string","format":"date"},
+ "title":{"type":"string"},
+ "role":{"type":"string"},
+ "org":{"type":"object",
+ "properties":{
+ "organizationName":{"type":"string"},
+ "organizationUnit":{"type":"string"}},
+ }
+ }
+}
+
+
+
+
diff --git a/card-v2 b/card-v2
new file mode 100644
index 00000000..520dfbbe
--- /dev/null
+++ b/card-v2
@@ -0,0 +1,47 @@
+{"description":"A representation of a person, company, organization, or place",
+ "type":"object",
+ "properties":{
+ "fn":{"description":"Formatted Name","type":"string","optional":true},
+ "familyName":{"type":"string"},
+ "givenName":{"type":"string"},
+ "additionalName":{"type":"array","items":{"type":"string"},"optional":true},
+ "honorificPrefix":{"type":"array","items":{"type":"string"},"optional":true},
+ "honorificSuffix":{"type":"array","items":{"type":"string"},"optional":true},
+ "nickname":{"type":"string","optional":true},
+ "url":{"type":"string","format":"url","optional":true},
+ "email":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"email"}},
+ "optional":true},
+ "tel":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"phone"}},
+ "optional":true},
+ "adr":{ "type":"object",
+ "properties":{"$ref":"http://json-schema.org/address#properties"},
+ "optional":true},
+ "geo":{ "type":"object",
+ "properties":{"$ref":"http://json-schema.org/geo#properties"},
+ "optional":true},
+ "tz":{"type":"string","optional":true},
+ "photo":{"format":"image","type":"string","optional":true},
+ "logo":{"format":"image","type":"string","optional":true},
+ "sound":{"format":"attachment","type":"string","optional":true},
+ "bday":{"type":"string","format":"date","optional":true},
+ "title":{"type":"string","optional":true},
+ "role":{"type":"string","optional":true},
+ "org":{"type":"object",
+ "properties":{
+ "organizationName":{"type":"string"},
+ "organizationUnit":{"type":"string"}},
+ "optional":true}
+ }
+}
+
+
+
+
diff --git a/card.properties b/card.properties
new file mode 100644
index 00000000..8704f79c
--- /dev/null
+++ b/card.properties
@@ -0,0 +1,40 @@
+{
+ "fn":{"description":"Formatted Name","type":"string","optional":true},
+ "familyName":{"type":"string"},
+ "givenName":{"type":"string"},
+ "additionalName":{"type":"array","items":{"type":"string"},"optional":true},
+ "honorificPrefix":{"type":"array","items":{"type":"string"},"optional":true},
+ "honorificSuffix":{"type":"array","items":{"type":"string"},"optional":true},
+ "nickname":{"type":"string","optional":true},
+ "url":{"type":"string","format":"url","optional":true},
+ "email":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"email"}},
+ "optional":true},
+ "tel":{
+ "type":"object",
+ "properties":{
+ "type":{"type":"string"},
+ "value":{"type":"string","format":"phone"}},
+ "optional":true},
+ "adr":{ "type":"object",
+ "properties":{"$ref":"http://json-schema.org/address.properties"},
+ "optional":true},
+ "geo":{ "type":"object",
+ "properties":{"$ref":"http://json-schema.org/geo.properties"},
+ "optional":true},
+ "tz":{"type":"string","optional":true},
+ "photo":{"format":"image","type":"string","optional":true},
+ "logo":{"format":"image","type":"string","optional":true},
+ "sound":{"format":"attachment","type":"string","optional":true},
+ "bday":{"type":"string","format":"date","optional":true},
+ "title":{"type":"string","optional":true},
+ "role":{"type":"string","optional":true},
+ "org":{"type":"object",
+ "properties":{
+ "organizationName":{"type":"string"},
+ "organizationUnit":{"type":"string"}},
+ "optional":true}
+ }
\ No newline at end of file
diff --git a/draft-zyp-json-schema-00.txt b/draft-zyp-json-schema-00.txt
new file mode 100644
index 00000000..2cdabe26
--- /dev/null
+++ b/draft-zyp-json-schema-00.txt
@@ -0,0 +1,1289 @@
+
+
+
+Internet Engineering Task Force K. Zyp, Ed.
+Internet-Draft SitePen (USA)
+Updates: 4120 (if approved) December 5, 2009
+Intended status: Standards Track
+Expires: June 8, 2010
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON
+ Documents
+ draft-zyp-json-schema-00
+
+Abstract
+
+ JSON (JavaScript Object Notation) Schema defines the media type
+ application/schema+json, a JSON based format for defining the
+ structure of JSON data. JSON Schema provides a contract for what
+ JSON data is required for a given application and how to interact
+ with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on June 8, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+Zyp Expires June 8, 2010 [Page 1]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ 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 BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Design Considerations . . . . . . . . . . . . . . . . . . 6
+ 4. Schema/Instance Association . . . . . . . . . . . . . . . . . 6
+ 4.1. Self-Descriptive Schema . . . . . . . . . . . . . . . . . 7
+ 5. Core Schema Definition . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. type . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. properties . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.3. items . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.4. optional . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.5. additionalProperties . . . . . . . . . . . . . . . . . . . 9
+ 5.6. requires . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.7. minimum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.8. maximum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.9. minimumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.10. maximumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.11. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.12. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.13. pattern . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.14. maxLength . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.15. minLength . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.16. enum . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.17. title . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.18. description . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.19. format . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.20. contentEncoding . . . . . . . . . . . . . . . . . . . . . 12
+ 5.21. default . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.22. maxDecimal . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.23. disallow . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.24. extends . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Hyper Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1.1. Link Description Object . . . . . . . . . . . . . . . 13
+ 6.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Zyp Expires June 8, 2010 [Page 2]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ 6.2.1. dot-delimited fragment resolution . . . . . . . . . . 18
+ 6.3. root . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.4. readonly . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.5. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.6. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.7. alternate . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 8.1. Registry of Link Relations . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
+ Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 3]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+1. Introduction
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for
+ defining the structure of JSON data. JSON Schema provides a contract
+ for what JSON data is required for a given application and how to
+ interact with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+2. Conventions
+
+ 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.
+
+3. Overview
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other JSON documents. JSON Schema is
+ JSON-based and includes facilities for describing the structure of
+ JSON documents in terms of allowable values, descriptions, and
+ interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions.
+ The first definition is the core schema specification. This
+ definition is primary concerned with describing a JSON structure and
+ specifying valid elements in the structure. The second definition is
+ the Hyper Schema specification which is intended define elements in a
+ structure that can be interpreted as hyperlinks. Hyper Schema builds
+ on JSON Schema to describe the hyperlink structure of other JSON
+ documents. This allows user agents to be able to successfully
+ navigate JSON documents based on their schemas.
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to
+ define the required type and constraints on property values, as well
+ as define the meaning of the property values for the purpose of
+ describing a resource and determining hyperlinks within the
+ representation.
+
+ An example JSON Schema that describes products might look like:
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 4]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ {
+ "name":"Product",
+ "properties":{
+ "id":{
+ "type":"number",
+ "description":"Product identifier"
+ },
+ "name":{
+ "description":"Name of the product",
+ "type":"string"
+ },
+ "price":{
+ "type": "number",
+ "minimum":0
+ },
+ "tags":{
+ "optional":true,
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ }
+ },
+ "links":[
+ {
+ "rel":"full",
+ "href":"{id}"
+ },
+ {
+ "rel":"comments",
+ "href":"comments/?id={id}"
+ }
+ ]
+ }
+
+ This schema defines the properties of the instance JSON documents and
+ their required properties (id, name, and price) as well as an
+ optional property (tags). This also defines the link relations of
+ the instance JSON documents.
+
+3.1. Terminology
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that
+ the schema will be describing and validating
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 5]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+3.2. Design Considerations
+
+ The JSON Schema media type does not attempt to dictate the structure
+ of JSON representations that contain data, but rather provides a
+ separate format for flexibly communicating how a JSON representation
+ should be interpreted and validated, such that user agents can
+ properly understand acceptable structures and extrapolate hyperlink
+ information with the JSON document. This specification does not
+ define a protocol. The underlying protocol (such as HTTP) should
+ sufficiently define the semantics of the client-server interface, the
+ retrieval of resource representations linked to by JSON
+ representations, and modification of those resources. The goal of
+ this format is to sufficiently describe JSON structures such that one
+ can utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a REST
+ architecture using existing protocols.
+
+4. Schema/Instance Association
+
+ JSON Schema instances are correlated to their schema by the
+ "describedby" relation, where the schema is defined to be the target
+ of the relation. Instance representations may be of the application/
+ json media type or any other subtype. Consequently, dictating how an
+ instance representation should specify the relation to the schema is
+ beyond the normative scope of this document (since this document
+ specifically defines the JSON Schema media type, and no other), but
+ it is recommended that instances specify their schema so that user
+ agents can interpret the instance representation and messages may
+ retain the self-descriptive characteristic, avoiding the need for
+ out-of-band information about instance data. Two approaches are
+ recommended for declaring the relation to the schema that describes
+ the meaning of a JSON instance's (or collection of instances)
+ structure. A MIME type parameter named "describedby" or a Link
+ header with a relation of "describedby" SHOULD be used:
+
+
+ Content-Type: application/json;
+ describedby=http://json.com/my-hyper-schema
+
+ or if the content is being transferred by a protocol (such as HTTP)
+ that provides headers, a Link header can be used:
+
+
+ Link: ; rel="describedby"
+
+ Instances MAY specify multiple schemas, to indicate all the schemas
+ that are applicable to the data. The instance data may have multiple
+ schemas that it is defined by (the instance data should be valid for
+
+
+
+Zyp Expires June 8, 2010 [Page 6]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ those schemas). Or if the document is a collection of instances, the
+ collection may contain instances from different schemas. When
+ collections contain heterogeneous instances, the pathStart attribute
+ MAY be specified in the schema to disambiguate which schema should be
+ applied for each item in the collection.
+
+4.1. Self-Descriptive Schema
+
+ JSON Schemas are themselves instances for the schema schemas. A
+ self-describing JSON Schema for the core JSON Schema can be found at
+ http://json-schema.org/schema and the hyper schema self-description
+ can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions SHOULD include a
+ MIME parameter that refers to the self-descriptive hyper schema or
+ another schema that extends this hyper schema:
+
+
+ Content-Type: application/json;
+ describedby=http://www.json-schema.org/hyper-schema
+
+5. Core Schema Definition
+
+ A JSON Schema is a JSON Object that defines various attributes of the
+ instance and defines it's usage and valid values. A JSON Schema is a
+ JSON Object with schema attribute properties. The following is the
+ grammar of a JSON Schema:
+
+ And an example JSON Schema definition could look like:
+
+
+ {"description":"A person",
+ "type":"object",
+
+ "properties":
+ {"name": {"type":"string"},
+ "age" : {"type":"integer",
+ "maximum":125}}
+ }
+
+ A JSON Schema object may have any of the following properties, called
+ schema attributes (all attributes are optional):
+
+5.1. type
+
+ Union type definition - An array with two or more items which
+ indicates a union of type definitions. Each item in the array may
+ be a simple type definition or a schema. The instance value is
+ valid if it is of the same type as one the type definitions in the
+
+
+
+Zyp Expires June 8, 2010 [Page 7]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ array or if it is valid by one of the schemas in the array. For
+ example to indicate that a string or number is a valid: {"type":
+ ["string","number"]}
+
+ Simple type definition - A string indicating a primitive or simple
+ type. The following are acceptable strings:
+
+ string - Value must be a string.
+
+ number - Value must be a number, floating point numbers are
+ allowed.
+
+ integer - Value must be an integer, no floating point numbers
+ are allowed. This is a subset of the number type.
+
+ boolean - Value must be a boolean.
+
+ object - Value must be an object.
+
+ array - Value must be an array.
+
+ null - Value must be null. Note this is mainly for purpose of
+ being able use union types to define nullability.
+
+ any - Value may be of any type including null. If the property
+ is not defined or is not in this list, than any type of value
+ is acceptable. Other type values may be used for custom
+ purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type
+ values.
+
+5.2. properties
+
+ This should be an object type definition, which is an object with
+ property definitions that correspond to instance object properties.
+ When the instance value is an object, the property values of the
+ instance object must conform to the property definitions in this
+ object. In this object, each property definition's value should be a
+ schema, and the property's name should be the name of the instance
+ property that it defines.
+
+5.3. items
+
+ This should be a schema or an array of schemas. When this is an
+ object/schema and the instance value is an array, all the items in
+ the array must conform to this schema. When this is an array of
+ schemas and the instance value is an array, each position in the
+ instance array must conform to the schema in the corresponding
+
+
+
+Zyp Expires June 8, 2010 [Page 8]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ position for this array. This called tuple typing. When tuple
+ typing is used, additional items are allowed, disallowed, or
+ constrained by the additionalProperties attribute using the same
+ rules as extra properties for objects..
+
+5.4. optional
+
+ This indicates that the instance property in the instance object is
+ optional. This is false by default.
+
+5.5. additionalProperties
+
+ This provides a default property definition for all properties that
+ are not explicitly defined in an object type definition. The value
+ must be a schema. If false is provided, no additional properties are
+ allowed, and the schema can not be extended. The default value is an
+ empty schema which allows any value for additional properties.
+
+5.6. requires
+
+ This indicates that if this property is present in the containing
+ instance object, the property given by requires attribute must also
+ be present in the containing instance object. The value of this
+ property may be a string, indicating the require property name. Or
+ the value may be a schema, in which case the containing instance must
+ be valid by the schema if the property is present. For example if a
+ object type definition is defined:
+
+
+ {
+ "state":
+ {
+ "optional":true
+ },
+ "town":
+ {
+ "requires":"state",
+ "optional":true
+ }
+ }
+
+ An instance must include a state property if a town property is
+ included. If a town property is not included, the state property is
+ optional.
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 9]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.7. minimum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.8. maximum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.9. minimumCanEqual
+
+ If the minimum is defined, this indicates whether or not the instance
+ property value can equal the minimum.
+
+5.10. maximumCanEqual
+
+ If the maximum is defined, this indicates whether or not the instance
+ property value can equal the maximum.
+
+5.11. minItems
+
+ This indicates the minimum number of values in an array when an array
+ is the instance value.
+
+5.12. maxItems
+
+ This indicates the maximum number of values in an array when an array
+ is the instance value.
+
+5.13. pattern
+
+ When the instance value is a string, this provides a regular
+ expression that a instance string value should match in order to be
+ valid. Regular expressions should follow the regular expression
+ specification from ECMA 262/Perl 5
+
+5.14. maxLength
+
+ When the instance value is a string, this indicates maximum length of
+ the string.
+
+5.15. minLength
+
+ When the instance value is a string, this indicates minimum length of
+ the string.
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 10]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.16. enum
+
+ This provides an enumeration of possible values that are valid for
+ the instance property. This should be an array, and each item in the
+ array represents a possible value for the instance value. If "enum"
+ is included, the instance value must be one of the values in enum
+ array in order for the schema to be valid.
+
+5.17. title
+
+ This provides a short description of the instance property. The
+ value must be a string.
+
+5.18. description
+
+ This provides a full description of the of purpose the instance
+ property. The value must be a string.
+
+5.19. format
+
+ This property indicates the type of data, content type, or
+ microformat to be expected in the instance property values. A format
+ attribute may be one of the values listed below, and if so, should
+ adhere to the semantics describing for the format. A format should
+ only be used give meaning to primitive types (string, integer,
+ number, or boolean). Validators are not required to validate that
+ the instance values conform to a format. The following formats are
+ defined:
+
+ Any valid MIME media type may be used as a format value, in which
+ case the instance property value must be a string, representing
+ the contents of the MIME file.
+
+ date-time - This should be a date in ISO 8601 format of YYYY-MM-
+ DDThh:mm:ssZ in UTC time. This is the recommended form of date/
+ timestamp.
+
+ date - This should be a date in the format of YYYY-MM-DD. It is
+ recommended that you use the "date-time" format instead of "date"
+ unless you need to transfer only the date part.
+
+ time - This should be a time in the format of hh:mm:ss. It is
+ recommended that you use the "date-time" format instead of "time"
+ unless you need to transfer only the time part.
+
+ utc-millisec - This should be the difference, measured in
+ milliseconds, between the specified time and midnight, January 1,
+ 1970 UTC. The value should be a number (integer or float).
+
+
+
+Zyp Expires June 8, 2010 [Page 11]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ regex - A regular expression.
+
+ color - This is a CSS color (like "#FF0000" or "red").
+
+ style - This is a CSS style definition (like "color: red;
+ background-color:#FFF").
+
+ phone - This should be a phone number (format may follow E.123).
+
+ uri - This value should be a URI..
+
+ email - This should be an email address.
+
+ ip-address - This should be an ip version 4 address.
+
+ ipv6 - This should be an ip version 6 address.
+
+ street-address - This should be a street address.
+
+ locality - This should be a city or town.
+
+ region - This should be a region (a state in the US, province in
+ Canada, etc.)
+
+ postal-code - This should be a postal code (AKA zip code).
+
+ country - This should be the name of a country.
+
+ Additional custom formats may be defined with a URL to a
+ definition of the format.
+
+5.20. contentEncoding
+
+ If the instance property value is a string, this indicates that the
+ string should be interpreted as binary data and decoded using the
+ encoding named by this schema property. RFC 2045, Sec 6.1 lists
+ possible values.
+
+5.21. default
+
+ This indicates the default for the instance property.
+
+5.22. maxDecimal
+
+ This indicates the maximum number of decimal places in a floating
+ point number. By default there is no maximum.
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.23. disallow
+
+ This attribute may take the same values as the "type" attribute,
+ however if the instance matches the type or if this value is an array
+ and the instance matches any type or schema in the array, than this
+ instance is not valid.
+
+5.24. extends
+
+ The value of this property should be another schema which will
+ provide a base schema which the current schema will inherit from.
+ The inheritance rules are such that any instance that is valid
+ according to the current schema must be valid according to the
+ referenced schema. This may also be an array, in which case, the
+ instance must be valid for all the schemas in the array.
+
+6. Hyper Schema
+
+ This section defines hypermedia definitions of JSON schema. The
+ following attributes are specified in addition to those attributes
+ that already provided by JSON schema with the specific purpose of
+ informing user agents of relations between resources based on JSON
+ data. Just as with JSON schema attributes, all the attributes in
+ hyper-schema are optional. Therefore an empty object is a valid
+ (non-informative) schema, and essentially describes plain JSON (no
+ constraints on the structures). Addition of attributes provides
+ additive information for user agents.
+
+6.1. links
+
+ The value of the links property should be an array, where each item
+ in the array is a link description object which describes the link
+ relations of the instances.
+
+6.1.1. Link Description Object
+
+ A link description object is used to describe the link relations of
+ instances of a schema.
+
+6.1.1.1. href
+
+ The value of the "href" link description property indicates the
+ target URI of the related resource. The value of the instance
+ property should be resolved as a URI-Reference per [RFC3986] and may
+ be a relative URI. The base URI to be used for relative resolution
+ should be the URI used to retrieve the instance object (not the
+ schema). Also, the URI may be parametrized by the property values of
+ the instance object.
+
+
+
+Zyp Expires June 8, 2010 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ Instance property values should be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute. For example, if an href value is defined:
+
+
+ http://somesite.com/{id}
+
+ Then it would be resolved by replace the value of the "id" property
+ value from the instance object. If the value of the "id" property
+ was "45", the expanded URI would be:
+
+
+ http://somesite.com/45
+
+ If matching braces are found with the string "-this" (no quotes)
+ between the braces, than the actual instance value should be used to
+ replace the braces, rather than a property value. This should only
+ be used in situations where the instance is a scalar (string,
+ boolean, or number), and not for objects or arrays.
+
+6.1.1.2. rel
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target should be
+ interpreted as specifically from the instance object that the schema
+ (or sub-schema) applies to, not just the top level resource that
+ contains the object within its hierarchy. If a resource JSON
+ representation contains a sub object with a property interpreted as a
+ link, that sub-object holds the relation with the target. A relation
+ to target from the top level resource must be indicated with the
+ schema describing the top level JSON representation.
+
+ Relationship definitions SHOULD NOT be media type dependent, and
+ users are encouraged to utilize existing accepted relation
+ definitions, including those in existing relation registries (see
+ &rfc4287). However, we define these relation here for clarity of
+ normative interpretation within the context of JSON hyper schema
+ defined relations:
+
+ self - If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the specified
+ URI.
+
+
+
+
+Zyp Expires June 8, 2010 [Page 14]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ full - This indicates that the target of the link is the full
+ representation for the instance object. The object that contains
+ this link may not be the full representation.
+
+ describedby - This indicates the target of the link is the schema
+ for the instance object. This may be used to specifically denote
+ the schemas of objects within a JSON object hierarchy,
+ facilitating polymorphic type data structures.
+
+ The following relations are applicable for schemas (the schema as
+ the "from" resource in the relation).
+
+ instances - This indicates the target resource that represents
+ collection of instances of a schema.
+
+ create - This indicates a target to use for creating new instances
+ of a schema. This link definition SHOULD be a submission link
+ with a non-safe method (like POST).
+
+ For example, if a schema is defined:
+
+
+ {
+ "links": [
+ {
+ "rel": "self"
+ "href": "{id}"
+ },
+ {
+ "rel": "up"
+ "href": "{upId}"
+ },
+ {
+ "rel": "children"
+ "href": "?upId={id}"
+ }
+ ]
+ }
+
+ And if a collection of instance resource's JSON representation was
+ retrieved:
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ GET /Resource/
+
+ [
+ {
+ "id": "thing",
+ "upId": "parent"
+ },
+ {
+ "id": "thing2",
+ "upId": "parent"
+ }
+ ]
+
+ This would indicate that for the first item in the collection, it's
+ own (self) URI would resolve to "/Resource/thing" and the first
+ item's "up" relation should be resolved to the resource at
+ "/Resource/parent". The "children" collection would be located at
+ "/Resource/?upId=thing".
+
+6.1.1.3. Submission Link Properties
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means
+ for submitting extra (often user supplied) information to send to a
+ server.
+
+6.1.1.3.1. method
+
+ This indicates which method should be used to access the target
+ resource. In an HTTP environment, this would be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+6.1.1.3.2. enctype
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method). For example, with
+ the following schema:
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 16]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ {
+ "links":[
+ {
+ "enctype": "application/x-www-form-urlencoded",
+ "method": "GET",
+ "href": "/Product/",
+ "properties":{
+ "name":{"description":"name of the product"}
+ }
+ }
+ ]
+ }
+
+ This indicates that the client can query the server for instances
+ that have a specific name:
+
+
+ /Product/?name=Slinky
+
+ If no enctype or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST, application/
+ json is the default media type.
+
+6.1.1.3.3. properties
+
+ This is inherited from the base JSON schema definition, and can
+ follow the same structure, but its meaning should be used to define
+ the acceptable property names and values for the action (whether it
+ be for the GET query or POST body). If properties are omitted, and
+ this form is the child of a schema, the properties from the parent
+ schema should be used as the basis for the form action.
+
+6.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "dot-delimited", which is defined below.
+ Other fragment resolution protocols may be used, but are not defined
+ in this document.
+
+ The fragment identifier is based on RFC 2396 Sec 5, and defines the
+ mechanism for resolving references to entities within a document.
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 17]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+6.2.1. dot-delimited fragment resolution
+
+ With the dot-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens
+ that are delimited by the "." character (\x2E). Each property
+ reference token is a series of any legal URI component characters
+ except the "." character. Each property reference token should be
+ interpreted, starting from the beginning of the fragment identifier,
+ as a path reference in the target JSON structure. The final target
+ value of the fragment can be determined by starting with the root of
+ the JSON structure from the representation of the resource identified
+ by the pre-fragment URI. If the target is a JSON object, than the
+ new target is the value of the property with the name identified by
+ the next property reference token in the fragment. If the target is
+ a JSON array, than the target is determined by finding the item in
+ array the array with the index defined by the next property reference
+ token (which MUST be a number). The target is successively updated
+ for each property reference token, until the entire fragment has been
+ traversed.
+
+ Property names SHOULD be URI-encoded. In particular, any "." in a
+ property name MUST be encoded to avoid being interpreted as a
+ property delimiter.
+
+ For example, for the following JSON representation:
+
+
+ {
+ "foo":{
+ "anArray":[
+ {"prop":44}
+ ],
+ "another prop":{
+ "baz":"A string"
+ }
+ }
+ }
+
+ The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 18]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ fragment identifier resolution
+ ------------------- ----------
+ # self, the root of the resource itself
+ #foo the object referred to by the foo property
+ #foo.another prop the object referred to by the "another prop"
+ property of the object referred to by the
+ "foo" property
+ #foo.another prop.baz the string referred to by the value of "baz"
+ property of the "another prop" property of
+ the object referred to by the "foo" property
+ #foo.anArray.0 the first object in the "anArray" array
+
+6.3. root
+
+ This attribute indicates that the value of the instance property
+ value SHOULD be treated as the root or the body of the representation
+ for the purposes of user agent interaction and fragment resolution
+ (all other properties of the instance objects are can be regarded as
+ meta-data descriptions for the data).
+
+6.4. readonly
+
+ This indicates that the instance property should not be changed.
+ Attempts by a user agent to modify the value of this property are
+ expected to be rejected by a server.
+
+6.5. pathStart
+
+ This property value is a URI-Reference that indicates the URI that
+ all the URIs for the instances of the schema should start with. When
+ multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance
+ by determining if URI of the instance begins with the pathStart's
+ referenced URI. pathStart MUST be resolved as per [RFC3986] section
+ 5. If the URI of the instance does not start with URI indicated by
+ pathStart, or if another schema specifies a starting URI that is
+ longer and also matches the instance, this schema should not be
+ applied to the instance. Any schema that does not have a pathStart
+ attribute should be considered applicable to all the instances for
+ which it is referenced.
+
+6.6. mediaType
+
+ This indicates the media type of the instance representations that
+ this schema is defining.
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 19]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+6.7. alternate
+
+ This is an array of JSON schema definitions that define any other
+ schemas for alternate JSON-based representations of the instance
+ resources.
+
+7. Security Considerations
+
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self" is
+ used to denote a full representation of an object, the user agent
+ SHOULD NOT consider the representation to be the authoritative
+ representation of the resource denoted by the target URI if the
+ target URI is not equivalent to or a sub-path of the the URI used to
+ request the resource representation which contains the target URI
+ with the "self" link. For example, if a hyper schema was defined:
+
+
+ {
+ "links":[
+ {
+ "rel":"self",
+ "href":"{id}"
+ }
+ ]
+ }
+
+ And a resource was requested from somesite.com:
+
+
+ GET /foo/
+
+ With a response of:
+
+
+Content-Type: application/json; describedby=/schema-for-this-data
+[
+ {"id":"bar", "name":"This representation can be safely treated \
+ as authoritative "},
+ {"id":"/baz", "name":"This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from "/baz" to ensure it has the authoritative representation"},
+ {"id":"http://othersite.com/something", "name":"This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"}
+]
+
+
+
+Zyp Expires June 8, 2010 [Page 20]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+8. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is application/
+ schema+json
+
+ Type name: application
+
+ Subtype name: schema+json
+
+ Required parameters: describedby
+
+ The value of the describedby parameter should be a URI (relative or
+ absolute) that refers to the schema used to define the structure of
+ this structure (the meta-schema). Normally the value would be
+ http://json-schema.org/hyper-schema, but it is allowable to use other
+ schemas that extend the hyper schema's meta- schema.
+
+ Optional parameters: pretty
+
+ The value of the pretty parameter may be true or false to indicate if
+ additional whitespace has been included to make the JSON
+ representation easier to read.
+
+8.1. Registry of Link Relations
+
+ This registry is maintained by IANA per RFC 4287 and this
+ specification adds three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+9. References
+
+9.1. Normative References
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in
+ RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC4287] Nottingham, M., Ed. and R. Sayre,
+ Ed., "The Atom Syndication
+ Format", RFC 4287, December 2005.
+
+
+
+Zyp Expires June 8, 2010 [Page 21]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ [RFC3339] Klyne, G., Ed. and C. Newman,
+ "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC2045] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format
+ of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+9.2. Informative References
+
+ [RFC4627] Crockford, D., "The application/
+ json Media Type for JavaScript
+ Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul,
+ J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC5226] Narten, T. and H. Alvestrand,
+ "Guidelines for Writing an IANA
+ Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [I-D.hammer-discovery] Hammer-Lahav, E., "Link-based
+ Resource Descriptor Discovery",
+ draft-hammer-discovery-03 (work in
+ progress), March 2009.
+
+ [I-D.gregorio-uritemplate] Gregorio, J., "URI Template",
+ draft-gregorio-uritemplate-03
+ (work in progress), April 2008.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-06
+ (work in progress), July 2009.
+
+ [W3C.REC-html401-19991224] Hors, A., Jacobs, I., and D.
+ Raggett, "HTML 4.01
+ Specification", World Wide Web
+ Consortium Recommendation REC-
+ html401-19991224, December 1999, <
+ http://www.w3.org/TR/1999/
+ REC-html401-19991224>.
+
+
+
+Zyp Expires June 8, 2010 [Page 22]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+Appendix A. Change Log
+
+Appendix B. Open Issues
+
+ Should we give a preference to MIME headers over Link headers (or
+ only use one)?
+
+ Should we use "profile" as the media type parameter instead?
+
+ Should "root" be a MIME parameter instead of a schema attribute?
+
+ Should "format" be renamed to "mediaType" or "contentType" to reflect
+ the usage MIME media types that are allowed.
+
+ I still do not like how dates are handled.
+
+Author's Address
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 23]
+
+
diff --git a/draft-zyp-json-schema-00.xml b/draft-zyp-json-schema-00.xml
new file mode 100644
index 00000000..9f722c91
--- /dev/null
+++ b/draft-zyp-json-schema-00.xml
@@ -0,0 +1,897 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+
+ SitePen (USA)
+
+
+
+ 530 Lytton Avenue
+
+ Palo Alto, CA 94301
+
+ USA
+
+
+ +1 650 968 8787
+
+ kris@sitepen.com
+
+
+
+
+
+ Internet Engineering Task Force
+
+ JSON
+
+ Schema
+
+ Hyper Schema
+
+ Hypermedia
+
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+ 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.
+
+
+
+
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+
+This schema defines the properties of the instance JSON documents and
+their required properties (id, name, and price) as well as an optional
+property (tags). This also defines the link relations of the instance
+JSON documents.
+
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that the schema
+ will be describing and validating
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. This specification does not define a protocol.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a REST
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the application/json media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "describedby" or a Link header with a relation of "describedby" SHOULD be used:
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+ ; rel="describedby"
+]]>
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data. The instance data may have multiple schemas
+ that it is defined by (the instance data should be valid for those schemas).
+ Or if the document is a collection of instances, the collection may contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the pathStart attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection.
+
+
+
+ JSON Schemas are themselves instances for the schema
+ schemas. A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema and the hyper schema
+ self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ of the instance and defines it's usage and valid values. A JSON
+ Schema is a JSON Object with schema attribute properties.
+ The following is the grammar of a JSON Schema:
+
+
+
+ And an example JSON Schema definition could look like:
+
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array may be a simple type definition or a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas in the array. For example to indicate that a string or number is a valid:
+{"type":["string","number"]}
+Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+
+string - Value must be a string.
+
+number - Value must be a number, floating point numbers are allowed.
+integer - Value must be an integer, no floating point numbers are allowed. This is a subset of the number type.
+boolean - Value must be a boolean.
+object - Value must be an object.
+array - Value must be an array.
+
+null - Value must be null. Note this is mainly for purpose of being able use union types to define nullability.
+any - Value may be of any type including null.
+If the property is not defined or is not in this list, than any type of value is acceptable. Other type values may be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+
+
+
+
+
+This should be an object type definition, which is an object with property definitions that correspond to instance object properties. When the instance value is an object, the property values of the instance object must conform to the property definitions in this object. In this object, each property definition's value should be a schema, and the property's name should be the name of the instance property that it defines.
+
+
+This should be a schema or an array of schemas. When this is an object/schema and the instance value is an array, all the items in the array must conform to this schema. When this is an array of schemas and the instance value is an array, each position in the instance array must conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalProperties attribute using the same rules as extra properties for objects..
+
+
+This indicates that the instance property in the instance object is optional. This is false by default.
+
+
+This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties.
+
+
+This indicates that if this property is present in the containing instance object, the property given by requires attribute must also be present in the containing instance object. The value
+of this property may be a string, indicating the require property name. Or the value may be a schema, in which case the containing instance must be valid by the schema if the property is present. For example if a object type definition is defined:
+
+
+
+
+An instance must include a state property if a town property is included. If a town property is not included, the state property is optional.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+If the minimum is defined, this indicates whether or not the instance property value can equal the minimum.
+
+
+If the maximum is defined, this indicates whether or not the instance property value can equal the maximum.
+
+
+This indicates the minimum number of values in an array when an array is the instance value.
+
+
+This indicates the maximum number of values in an array when an array is the instance value.
+
+
+When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid. Regular expressions should follow the regular expression specification from ECMA 262/Perl 5
+
+When the instance value is a string, this indicates maximum length of the string.
+
+
+When the instance value is a string, this indicates minimum length of the string.
+
+
+This provides an enumeration of possible values that are valid for the instance property. This should be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value must be one of the values in enum array in order for the schema to be valid.
+
+
+This provides a short description of the instance property. The value must be a string.
+
+
+This provides a full description of the of purpose the instance property. The value must be a string.
+
+This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute may be one of the values listed below, and if so, should adhere to the semantics describing for the format. A format should only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
+Any valid MIME media type may be used as a format value, in which case the instance property value must be a string, representing the contents of the MIME file.
+date-time - This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+date - This should be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+time - This should be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+utc-millisec - This should be the difference, measured in milliseconds, between the specified time and midnight, January 1, 1970 UTC. The value should be a number (integer or float).
+regex - A regular expression.
+color - This is a CSS color (like "#FF0000" or "red").
+style - This is a CSS style definition (like "color: red; background-color:#FFF").
+phone - This should be a phone number (format may follow E.123).
+uri - This value should be a URI..
+email - This should be an email address.
+ip-address - This should be an ip version 4 address.
+ipv6 - This should be an ip version 6 address.
+street-address - This should be a street address.
+locality - This should be a city or town.
+region - This should be a region (a state in the US, province in Canada, etc.)
+postal-code - This should be a postal code (AKA zip code).
+country - This should be the name of a country.
+Additional custom formats may be defined with a URL to a definition of the format.
+
+
+
+If the instance property value is a string, this indicates that the string should be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+
+
+
+This indicates the default for the instance property.
+
+
+This indicates the maximum number of decimal places in a floating point number. By default there is no maximum.
+
+
+This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, than this instance is not valid.
+
+
+The value of this property should be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema must be valid according to the referenced schema. This may also be an array, in which case, the instance must be valid for all the schemas in the array.
+
+
+
+ This section defines hypermedia definitions of JSON schema.
+ The following attributes are specified in addition to those
+attributes that already provided by JSON schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper-schema are optional.
+Therefore an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+
+The value of the links property should be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+
+A link description object is used to describe the link relations
+of instances of a schema.
+
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property should be resolved as a URI-Reference per [RFC3986]
+and may be a relative URI. The base URI to be used for relative resolution
+should be the URI used to retrieve the instance object (not the schema).
+Also, the URI may be parametrized by the property values of the instance
+object.
+
+
+Instance property values should be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+
+If matching braces are found with the string "-this" (no quotes) between the braces, than the
+actual instance value should be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target should be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource must be indicated with the schema describing the top level JSON representation.
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+self - If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link may not be the full representation.
+
+
+describedby - This indicates the target of the link is the schema for the instance object. This may be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+
+
+instances - This indicates the target resource that represents collection of instances of a schema.
+
+
+create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+For example, if a schema is defined:
+
+
+
+
+And if a collection of instance resource's JSON representation was
+retrieved:
+
+
+
+
+
+This would indicate that for the first item in the collection, it's own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation should be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+This indicates which method should be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, application/json is
+the default media type.
+
+
+
+
+This is inherited from the base JSON schema definition, and can follow the
+same structure, but its meaning should be used to define the acceptable
+property names and values for the action (whether it be for the GET query
+or POST body). If properties are omitted, and this form is the child of a
+schema, the properties from the parent schema should be used as the basis
+for the form action.
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "dot-delimited", which is defined below. Other fragment
+resolution protocols may be used, but are not defined in this
+document.
+
+
+
+The fragment identifier is based on RFC 2396 Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
+With the dot-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that
+are delimited by the "." character (\x2E). Each property reference token
+is a series of any legal URI component characters except the "." character. Each property
+reference token should be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, than the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, than the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+Property names SHOULD be URI-encoded. In particular, any "." in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+For example, for the following JSON representation:
+
+
+
+
+The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+
+
+
+
+ This attribute indicates that the value of the instance property value
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
+
+
+This indicates that the instance property should not be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+
+ This property value is a URI-Reference that indicates the URI that all
+the URIs for the instances of the schema should start with. When
+multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if URI of the instance begins with the pathStart's referenced
+URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+the instance does not start with URI indicated by pathStart, or if another
+schema specifies a starting URI that is longer and also matches the
+instance, this schema should not be applied to the instance. Any schema
+that does not have a pathStart attribute should be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+
+
+
+ This indicates the media type of the instance representations that this schema is defining.
+
+
+
+
+
+ This is an array of JSON schema definitions that define any
+ other schemas for alternate JSON-based representations
+ of the instance resources.
+
+
+
+
+
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC
+4627. However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+
+
+And a resource was requested from somesite.com:
+
+
+
+
+
+With a response of:
+
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is application/schema+json
+
+
+ Type name: application
+
+
+ Subtype name: schema+json
+
+
+ Required parameters: describedby
+
+
+ The value of the describedby parameter should be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+ Optional parameters: pretty
+
+
+ The value of the pretty parameter may be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+
+
+
+
+ &rfc3986;
+ &rfc2119;
+ &rfc4287;
+ &rfc3339;
+ &rfc2045;
+
+
+
+ &rfc4627;
+ &rfc2616;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+
+
+
+
+
+ -01
+
+
+ Fixed category and updates from template
+
+
+ -00
+
+
+ Initial draft
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should we use "profile" as the media type parameter instead?
+ Should "root" be a MIME parameter instead of a schema attribute?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed.
+ I still do not like how dates are handled.
+
+
+
+
+
+
diff --git a/draft-zyp-json-schema-01.html b/draft-zyp-json-schema-01.html
new file mode 100644
index 00000000..7ce12a86
--- /dev/null
+++ b/draft-zyp-json-schema-01.html
@@ -0,0 +1,1400 @@
+
+A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+
+
+
+
+
+
A JSON Media Type for Describing the Structure and Meaning of JSON Documents draft-zyp-json-schema-01
+
+
Abstract
+
+
JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
Status of This Memo
+
+This Internet-Draft is submitted to IETF in full
+conformance with the provisions of BCP 78 and BCP 79.
+
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.
+Note that other groups may also distribute working documents as
+Internet-Drafts.
+
+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.”
+Copyright (c) 2009 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 BSD License.
JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
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.
+
JSON Schema defines the media type application/schema+json for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+
JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+This schema defines the properties of the instance JSON documents and
+their required properties (id, name, and price) as well as an optional
+property (tags). This also defines the link relations of the instance
+JSON documents.
+
+
For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that the schema
+ will be describing and validating
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. This specification does not define a protocol.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a REST
+ architecture using existing protocols.
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the application/json media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "describedby" or a Link header with a relation of "describedby" SHOULD be used:
+
+
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data. The instance data may have multiple schemas
+ that it is defined by (the instance data should be valid for those schemas).
+ Or if the document is a collection of instances, the collection may contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the pathStart attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection.
+
+
+ JSON Schemas are themselves instances for the schema
+ schemas. A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema and the hyper schema
+ self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
A JSON Schema is a JSON Object that defines various attributes
+ of the instance and defines it's usage and valid values. A JSON
+ Schema is a JSON Object with schema attribute properties.
+ The following is the grammar of a JSON Schema:
+
+
+
And an example JSON Schema definition could look like:
+
Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array may be a simple type definition or a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas in the array. For example to indicate that a string or number is a valid:
+{"type":["string","number"]}
+
+
Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+
+
+
string - Value must be a string.
+
+
+
number - Value must be a number, floating point numbers are allowed.
+
+
integer - Value must be an integer, no floating point numbers are allowed. This is a subset of the number type.
+
+
boolean - Value must be a boolean.
+
+
object - Value must be an object.
+
+
array - Value must be an array.
+
+
+
null - Value must be null. Note this is mainly for purpose of being able use union types to define nullability.
+
+
any - Value may be of any type including null.
+If the property is not defined or is not in this list, than any type of value is acceptable. Other type values may be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
This should be an object type definition, which is an object with property definitions that correspond to instance object properties. When the instance value is an object, the property values of the instance object must conform to the property definitions in this object. In this object, each property definition's value should be a schema, and the property's name should be the name of the instance property that it defines.
+
This should be a schema or an array of schemas. When this is an object/schema and the instance value is an array, all the items in the array must conform to this schema. When this is an array of schemas and the instance value is an array, each position in the instance array must conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalProperties attribute using the same rules as extra properties for objects..
+
This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties.
+
This indicates that if this property is present in the containing instance object, the property given by requires attribute must also be present in the containing instance object. The value
+of this property may be a string, indicating the require property name. Or the value may be a schema, in which case the containing instance must be valid by the schema if the property is present. For example if a object type definition is defined:
+
When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid. Regular expressions should follow the regular expression specification from ECMA 262/Perl 5
+
This provides an enumeration of possible values that are valid for the instance property. This should be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value must be one of the values in enum array in order for the schema to be valid.
+
This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute may be one of the values listed below, and if so, should adhere to the semantics describing for the format. A format should only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
+
+
Any valid MIME media type may be used as a format value, in which case the instance property value must be a string, representing the contents of the MIME file.
+
+
+
date-time - This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+
+
+
date - This should be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+
+
+
time - This should be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+
+
+
utc-millisec - This should be the difference, measured in milliseconds, between the specified time and midnight, January 1, 1970 UTC. The value should be a number (integer or float).
+
+
+
regex - A regular expression.
+
+
+
color - This is a CSS color (like "#FF0000" or "red").
+
+
+
style - This is a CSS style definition (like "color: red; background-color:#FFF").
+
+
+
phone - This should be a phone number (format may follow E.123).
+
+
+
uri - This value should be a URI..
+
+
+
email - This should be an email address.
+
+
+
ip-address - This should be an ip version 4 address.
+
+
+
ipv6 - This should be an ip version 6 address.
+
+
street-address - This should be a street address.
+
+
locality - This should be a city or town.
+
+
region - This should be a region (a state in the US, province in Canada, etc.)
+
+
postal-code - This should be a postal code (AKA zip code).
+
+
country - This should be the name of a country.
+
+
Additional custom formats may be defined with a URL to a definition of the format.
+
+If the instance property value is a string, this indicates that the string should be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+
+
This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, than this instance is not valid.
+
The value of this property should be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema must be valid according to the referenced schema. This may also be an array, in which case, the instance must be valid for all the schemas in the array.
+
This section defines hypermedia definitions of JSON schema.
+ The following attributes are specified in addition to those
+attributes that already provided by JSON schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper-schema are optional.
+Therefore an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+The value of the links property should be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property should be resolved as a URI-Reference per [RFC3986]
+and may be a relative URI. The base URI to be used for relative resolution
+should be the URI used to retrieve the instance object (not the schema).
+Also, the URI may be parametrized by the property values of the instance
+object.
+
+
+
+Instance property values should be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+http://somesite.com/{id}
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+http://somesite.com/45
+
+
+If matching braces are found with the string "-this" (no quotes) between the braces, than the
+actual instance value should be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target should be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource must be indicated with the schema describing the top level JSON representation.
+
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+
+self - If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+
+full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link may not be the full representation.
+
+
+
+describedby - This indicates the target of the link is the schema for the instance object. This may be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+
+
+
+instances - This indicates the target resource that represents collection of instances of a schema.
+
+
+
+create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+
+
+This would indicate that for the first item in the collection, it's own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation should be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+This indicates which method should be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+/Product/?name=Slinky
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, application/json is
+the default media type.
+
+
+This is inherited from the base JSON schema definition, and can follow the
+same structure, but its meaning should be used to define the acceptable
+property names and values for the action (whether it be for the GET query
+or POST body). If properties are omitted, and this form is the child of a
+schema, the properties from the parent schema should be used as the basis
+for the form action.
+
+
This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "dot-delimited", which is defined below. Other fragment
+resolution protocols may be used, but are not defined in this
+document.
+
+
+
+
+The fragment identifier is based on RFC 2396 Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
With the dot-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that
+are delimited by the "." character (\x2E). Each property reference token
+is a series of any legal URI component characters except the "." character. Each property
+reference token should be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, than the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, than the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+
+Property names SHOULD be URI-encoded. In particular, any "." in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+
+For example, for the following JSON representation:
+
+
+The following fragment identifiers would be resolved:
+
+
+
+fragment identifier resolution
+------------------- ----------
+# self, the root of the resource itself
+#foo the object referred to by the foo property
+#foo.another prop the object referred to by the "another prop"
+ property of the object referred to by the
+ "foo" property
+#foo.another prop.baz the string referred to by the value of "baz"
+ property of the "another prop" property of
+ the object referred to by the "foo" property
+#foo.anArray.0 the first object in the "anArray" array
+
This attribute indicates that the value of the instance property value
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
This indicates that the instance property should not be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
This property value is a URI-Reference that indicates the URI that all
+the URIs for the instances of the schema should start with. When
+multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if URI of the instance begins with the pathStart's referenced
+URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+the instance does not start with URI indicated by pathStart, or if another
+schema specifies a starting URI that is longer and also matches the
+instance, this schema should not be applied to the instance. Any schema
+that does not have a pathStart attribute should be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC
+4627. However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+And a resource was requested from somesite.com:
+
+
+
+GET /foo/
+
+
+
+With a response of:
+
+
+
+Content-Type: application/json; describedby=/schema-for-this-data
+[
+ {"id":"bar", "name":"This representation can be safely treated \
+ as authoritative "},
+ {"id":"/baz", "name":"This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from "/baz" to ensure it has the authoritative representation"},
+ {"id":"http://othersite.com/something", "name":"This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"}
+]
+
+ The proposed MIME media type for JSON Schema is application/schema+json
+
+
+
+ Type name: application
+
+
+
+ Subtype name: schema+json
+
+
+
+ Required parameters: describedby
+
+
+
+ The value of the describedby parameter should be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+
+ Optional parameters: pretty
+
+
+
+ The value of the pretty parameter may be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
diff --git a/draft-zyp-json-schema-01.txt b/draft-zyp-json-schema-01.txt
new file mode 100644
index 00000000..e154671e
--- /dev/null
+++ b/draft-zyp-json-schema-01.txt
@@ -0,0 +1,1289 @@
+
+
+
+Internet Engineering Task Force K. Zyp, Ed.
+Internet-Draft SitePen (USA)
+Intended status: Informational December 5, 2009
+Expires: June 8, 2010
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON
+ Documents
+ draft-zyp-json-schema-01
+
+Abstract
+
+ JSON (JavaScript Object Notation) Schema defines the media type
+ application/schema+json, a JSON based format for defining the
+ structure of JSON data. JSON Schema provides a contract for what
+ JSON data is required for a given application and how to interact
+ with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on June 8, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Zyp Expires June 8, 2010 [Page 1]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ 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 BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Design Considerations . . . . . . . . . . . . . . . . . . 6
+ 4. Schema/Instance Association . . . . . . . . . . . . . . . . . 6
+ 4.1. Self-Descriptive Schema . . . . . . . . . . . . . . . . . 7
+ 5. Core Schema Definition . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. type . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. properties . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.3. items . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.4. optional . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.5. additionalProperties . . . . . . . . . . . . . . . . . . . 9
+ 5.6. requires . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.7. minimum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.8. maximum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.9. minimumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.10. maximumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.11. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.12. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.13. pattern . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.14. maxLength . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.15. minLength . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.16. enum . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.17. title . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.18. description . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.19. format . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.20. contentEncoding . . . . . . . . . . . . . . . . . . . . . 12
+ 5.21. default . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.22. maxDecimal . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.23. disallow . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.24. extends . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Hyper Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1.1. Link Description Object . . . . . . . . . . . . . . . 13
+ 6.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Zyp Expires June 8, 2010 [Page 2]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ 6.2.1. dot-delimited fragment resolution . . . . . . . . . . 18
+ 6.3. root . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.4. readonly . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.5. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.6. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.7. alternate . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 8.1. Registry of Link Relations . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
+ Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 3]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+1. Introduction
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for
+ defining the structure of JSON data. JSON Schema provides a contract
+ for what JSON data is required for a given application and how to
+ interact with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+2. Conventions
+
+ 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.
+
+3. Overview
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other JSON documents. JSON Schema is
+ JSON-based and includes facilities for describing the structure of
+ JSON documents in terms of allowable values, descriptions, and
+ interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions.
+ The first definition is the core schema specification. This
+ definition is primary concerned with describing a JSON structure and
+ specifying valid elements in the structure. The second definition is
+ the Hyper Schema specification which is intended define elements in a
+ structure that can be interpreted as hyperlinks. Hyper Schema builds
+ on JSON Schema to describe the hyperlink structure of other JSON
+ documents. This allows user agents to be able to successfully
+ navigate JSON documents based on their schemas.
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to
+ define the required type and constraints on property values, as well
+ as define the meaning of the property values for the purpose of
+ describing a resource and determining hyperlinks within the
+ representation.
+
+ An example JSON Schema that describes products might look like:
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 4]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ {
+ "name":"Product",
+ "properties":{
+ "id":{
+ "type":"number",
+ "description":"Product identifier"
+ },
+ "name":{
+ "description":"Name of the product",
+ "type":"string"
+ },
+ "price":{
+ "type": "number",
+ "minimum":0
+ },
+ "tags":{
+ "optional":true,
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ }
+ },
+ "links":[
+ {
+ "rel":"full",
+ "href":"{id}"
+ },
+ {
+ "rel":"comments",
+ "href":"comments/?id={id}"
+ }
+ ]
+ }
+
+ This schema defines the properties of the instance JSON documents and
+ their required properties (id, name, and price) as well as an
+ optional property (tags). This also defines the link relations of
+ the instance JSON documents.
+
+3.1. Terminology
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that
+ the schema will be describing and validating
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 5]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+3.2. Design Considerations
+
+ The JSON Schema media type does not attempt to dictate the structure
+ of JSON representations that contain data, but rather provides a
+ separate format for flexibly communicating how a JSON representation
+ should be interpreted and validated, such that user agents can
+ properly understand acceptable structures and extrapolate hyperlink
+ information with the JSON document. This specification does not
+ define a protocol. The underlying protocol (such as HTTP) should
+ sufficiently define the semantics of the client-server interface, the
+ retrieval of resource representations linked to by JSON
+ representations, and modification of those resources. The goal of
+ this format is to sufficiently describe JSON structures such that one
+ can utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a REST
+ architecture using existing protocols.
+
+4. Schema/Instance Association
+
+ JSON Schema instances are correlated to their schema by the
+ "describedby" relation, where the schema is defined to be the target
+ of the relation. Instance representations may be of the application/
+ json media type or any other subtype. Consequently, dictating how an
+ instance representation should specify the relation to the schema is
+ beyond the normative scope of this document (since this document
+ specifically defines the JSON Schema media type, and no other), but
+ it is recommended that instances specify their schema so that user
+ agents can interpret the instance representation and messages may
+ retain the self-descriptive characteristic, avoiding the need for
+ out-of-band information about instance data. Two approaches are
+ recommended for declaring the relation to the schema that describes
+ the meaning of a JSON instance's (or collection of instances)
+ structure. A MIME type parameter named "describedby" or a Link
+ header with a relation of "describedby" SHOULD be used:
+
+
+ Content-Type: application/json;
+ describedby=http://json.com/my-hyper-schema
+
+ or if the content is being transferred by a protocol (such as HTTP)
+ that provides headers, a Link header can be used:
+
+
+ Link: ; rel="describedby"
+
+ Instances MAY specify multiple schemas, to indicate all the schemas
+ that are applicable to the data. The instance data may have multiple
+ schemas that it is defined by (the instance data should be valid for
+
+
+
+Zyp Expires June 8, 2010 [Page 6]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ those schemas). Or if the document is a collection of instances, the
+ collection may contain instances from different schemas. When
+ collections contain heterogeneous instances, the pathStart attribute
+ MAY be specified in the schema to disambiguate which schema should be
+ applied for each item in the collection.
+
+4.1. Self-Descriptive Schema
+
+ JSON Schemas are themselves instances for the schema schemas. A
+ self-describing JSON Schema for the core JSON Schema can be found at
+ http://json-schema.org/schema and the hyper schema self-description
+ can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions SHOULD include a
+ MIME parameter that refers to the self-descriptive hyper schema or
+ another schema that extends this hyper schema:
+
+
+ Content-Type: application/json;
+ describedby=http://www.json-schema.org/hyper-schema
+
+5. Core Schema Definition
+
+ A JSON Schema is a JSON Object that defines various attributes of the
+ instance and defines it's usage and valid values. A JSON Schema is a
+ JSON Object with schema attribute properties. The following is the
+ grammar of a JSON Schema:
+
+ And an example JSON Schema definition could look like:
+
+
+ {"description":"A person",
+ "type":"object",
+
+ "properties":
+ {"name": {"type":"string"},
+ "age" : {"type":"integer",
+ "maximum":125}}
+ }
+
+ A JSON Schema object may have any of the following properties, called
+ schema attributes (all attributes are optional):
+
+5.1. type
+
+ Union type definition - An array with two or more items which
+ indicates a union of type definitions. Each item in the array may
+ be a simple type definition or a schema. The instance value is
+ valid if it is of the same type as one the type definitions in the
+
+
+
+Zyp Expires June 8, 2010 [Page 7]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ array or if it is valid by one of the schemas in the array. For
+ example to indicate that a string or number is a valid: {"type":
+ ["string","number"]}
+
+ Simple type definition - A string indicating a primitive or simple
+ type. The following are acceptable strings:
+
+ string - Value must be a string.
+
+ number - Value must be a number, floating point numbers are
+ allowed.
+
+ integer - Value must be an integer, no floating point numbers
+ are allowed. This is a subset of the number type.
+
+ boolean - Value must be a boolean.
+
+ object - Value must be an object.
+
+ array - Value must be an array.
+
+ null - Value must be null. Note this is mainly for purpose of
+ being able use union types to define nullability.
+
+ any - Value may be of any type including null. If the property
+ is not defined or is not in this list, than any type of value
+ is acceptable. Other type values may be used for custom
+ purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type
+ values.
+
+5.2. properties
+
+ This should be an object type definition, which is an object with
+ property definitions that correspond to instance object properties.
+ When the instance value is an object, the property values of the
+ instance object must conform to the property definitions in this
+ object. In this object, each property definition's value should be a
+ schema, and the property's name should be the name of the instance
+ property that it defines.
+
+5.3. items
+
+ This should be a schema or an array of schemas. When this is an
+ object/schema and the instance value is an array, all the items in
+ the array must conform to this schema. When this is an array of
+ schemas and the instance value is an array, each position in the
+ instance array must conform to the schema in the corresponding
+
+
+
+Zyp Expires June 8, 2010 [Page 8]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ position for this array. This called tuple typing. When tuple
+ typing is used, additional items are allowed, disallowed, or
+ constrained by the additionalProperties attribute using the same
+ rules as extra properties for objects..
+
+5.4. optional
+
+ This indicates that the instance property in the instance object is
+ optional. This is false by default.
+
+5.5. additionalProperties
+
+ This provides a default property definition for all properties that
+ are not explicitly defined in an object type definition. The value
+ must be a schema. If false is provided, no additional properties are
+ allowed, and the schema can not be extended. The default value is an
+ empty schema which allows any value for additional properties.
+
+5.6. requires
+
+ This indicates that if this property is present in the containing
+ instance object, the property given by requires attribute must also
+ be present in the containing instance object. The value of this
+ property may be a string, indicating the require property name. Or
+ the value may be a schema, in which case the containing instance must
+ be valid by the schema if the property is present. For example if a
+ object type definition is defined:
+
+
+ {
+ "state":
+ {
+ "optional":true
+ },
+ "town":
+ {
+ "requires":"state",
+ "optional":true
+ }
+ }
+
+ An instance must include a state property if a town property is
+ included. If a town property is not included, the state property is
+ optional.
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 9]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.7. minimum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.8. maximum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.9. minimumCanEqual
+
+ If the minimum is defined, this indicates whether or not the instance
+ property value can equal the minimum.
+
+5.10. maximumCanEqual
+
+ If the maximum is defined, this indicates whether or not the instance
+ property value can equal the maximum.
+
+5.11. minItems
+
+ This indicates the minimum number of values in an array when an array
+ is the instance value.
+
+5.12. maxItems
+
+ This indicates the maximum number of values in an array when an array
+ is the instance value.
+
+5.13. pattern
+
+ When the instance value is a string, this provides a regular
+ expression that a instance string value should match in order to be
+ valid. Regular expressions should follow the regular expression
+ specification from ECMA 262/Perl 5
+
+5.14. maxLength
+
+ When the instance value is a string, this indicates maximum length of
+ the string.
+
+5.15. minLength
+
+ When the instance value is a string, this indicates minimum length of
+ the string.
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 10]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.16. enum
+
+ This provides an enumeration of possible values that are valid for
+ the instance property. This should be an array, and each item in the
+ array represents a possible value for the instance value. If "enum"
+ is included, the instance value must be one of the values in enum
+ array in order for the schema to be valid.
+
+5.17. title
+
+ This provides a short description of the instance property. The
+ value must be a string.
+
+5.18. description
+
+ This provides a full description of the of purpose the instance
+ property. The value must be a string.
+
+5.19. format
+
+ This property indicates the type of data, content type, or
+ microformat to be expected in the instance property values. A format
+ attribute may be one of the values listed below, and if so, should
+ adhere to the semantics describing for the format. A format should
+ only be used give meaning to primitive types (string, integer,
+ number, or boolean). Validators are not required to validate that
+ the instance values conform to a format. The following formats are
+ defined:
+
+ Any valid MIME media type may be used as a format value, in which
+ case the instance property value must be a string, representing
+ the contents of the MIME file.
+
+ date-time - This should be a date in ISO 8601 format of YYYY-MM-
+ DDThh:mm:ssZ in UTC time. This is the recommended form of date/
+ timestamp.
+
+ date - This should be a date in the format of YYYY-MM-DD. It is
+ recommended that you use the "date-time" format instead of "date"
+ unless you need to transfer only the date part.
+
+ time - This should be a time in the format of hh:mm:ss. It is
+ recommended that you use the "date-time" format instead of "time"
+ unless you need to transfer only the time part.
+
+ utc-millisec - This should be the difference, measured in
+ milliseconds, between the specified time and midnight, January 1,
+ 1970 UTC. The value should be a number (integer or float).
+
+
+
+Zyp Expires June 8, 2010 [Page 11]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ regex - A regular expression.
+
+ color - This is a CSS color (like "#FF0000" or "red").
+
+ style - This is a CSS style definition (like "color: red;
+ background-color:#FFF").
+
+ phone - This should be a phone number (format may follow E.123).
+
+ uri - This value should be a URI..
+
+ email - This should be an email address.
+
+ ip-address - This should be an ip version 4 address.
+
+ ipv6 - This should be an ip version 6 address.
+
+ street-address - This should be a street address.
+
+ locality - This should be a city or town.
+
+ region - This should be a region (a state in the US, province in
+ Canada, etc.)
+
+ postal-code - This should be a postal code (AKA zip code).
+
+ country - This should be the name of a country.
+
+ Additional custom formats may be defined with a URL to a
+ definition of the format.
+
+5.20. contentEncoding
+
+ If the instance property value is a string, this indicates that the
+ string should be interpreted as binary data and decoded using the
+ encoding named by this schema property. RFC 2045, Sec 6.1 lists
+ possible values.
+
+5.21. default
+
+ This indicates the default for the instance property.
+
+5.22. maxDecimal
+
+ This indicates the maximum number of decimal places in a floating
+ point number. By default there is no maximum.
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 12]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+5.23. disallow
+
+ This attribute may take the same values as the "type" attribute,
+ however if the instance matches the type or if this value is an array
+ and the instance matches any type or schema in the array, than this
+ instance is not valid.
+
+5.24. extends
+
+ The value of this property should be another schema which will
+ provide a base schema which the current schema will inherit from.
+ The inheritance rules are such that any instance that is valid
+ according to the current schema must be valid according to the
+ referenced schema. This may also be an array, in which case, the
+ instance must be valid for all the schemas in the array.
+
+6. Hyper Schema
+
+ This section defines hypermedia definitions of JSON schema. The
+ following attributes are specified in addition to those attributes
+ that already provided by JSON schema with the specific purpose of
+ informing user agents of relations between resources based on JSON
+ data. Just as with JSON schema attributes, all the attributes in
+ hyper-schema are optional. Therefore an empty object is a valid
+ (non-informative) schema, and essentially describes plain JSON (no
+ constraints on the structures). Addition of attributes provides
+ additive information for user agents.
+
+6.1. links
+
+ The value of the links property should be an array, where each item
+ in the array is a link description object which describes the link
+ relations of the instances.
+
+6.1.1. Link Description Object
+
+ A link description object is used to describe the link relations of
+ instances of a schema.
+
+6.1.1.1. href
+
+ The value of the "href" link description property indicates the
+ target URI of the related resource. The value of the instance
+ property should be resolved as a URI-Reference per [RFC3986] and may
+ be a relative URI. The base URI to be used for relative resolution
+ should be the URI used to retrieve the instance object (not the
+ schema). Also, the URI may be parametrized by the property values of
+ the instance object.
+
+
+
+Zyp Expires June 8, 2010 [Page 13]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ Instance property values should be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute. For example, if an href value is defined:
+
+
+ http://somesite.com/{id}
+
+ Then it would be resolved by replace the value of the "id" property
+ value from the instance object. If the value of the "id" property
+ was "45", the expanded URI would be:
+
+
+ http://somesite.com/45
+
+ If matching braces are found with the string "-this" (no quotes)
+ between the braces, than the actual instance value should be used to
+ replace the braces, rather than a property value. This should only
+ be used in situations where the instance is a scalar (string,
+ boolean, or number), and not for objects or arrays.
+
+6.1.1.2. rel
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target should be
+ interpreted as specifically from the instance object that the schema
+ (or sub-schema) applies to, not just the top level resource that
+ contains the object within its hierarchy. If a resource JSON
+ representation contains a sub object with a property interpreted as a
+ link, that sub-object holds the relation with the target. A relation
+ to target from the top level resource must be indicated with the
+ schema describing the top level JSON representation.
+
+ Relationship definitions SHOULD NOT be media type dependent, and
+ users are encouraged to utilize existing accepted relation
+ definitions, including those in existing relation registries (see
+ &rfc4287). However, we define these relation here for clarity of
+ normative interpretation within the context of JSON hyper schema
+ defined relations:
+
+ self - If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the specified
+ URI.
+
+
+
+
+Zyp Expires June 8, 2010 [Page 14]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ full - This indicates that the target of the link is the full
+ representation for the instance object. The object that contains
+ this link may not be the full representation.
+
+ describedby - This indicates the target of the link is the schema
+ for the instance object. This may be used to specifically denote
+ the schemas of objects within a JSON object hierarchy,
+ facilitating polymorphic type data structures.
+
+ The following relations are applicable for schemas (the schema as
+ the "from" resource in the relation).
+
+ instances - This indicates the target resource that represents
+ collection of instances of a schema.
+
+ create - This indicates a target to use for creating new instances
+ of a schema. This link definition SHOULD be a submission link
+ with a non-safe method (like POST).
+
+ For example, if a schema is defined:
+
+
+ {
+ "links": [
+ {
+ "rel": "self"
+ "href": "{id}"
+ },
+ {
+ "rel": "up"
+ "href": "{upId}"
+ },
+ {
+ "rel": "children"
+ "href": "?upId={id}"
+ }
+ ]
+ }
+
+ And if a collection of instance resource's JSON representation was
+ retrieved:
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 15]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ GET /Resource/
+
+ [
+ {
+ "id": "thing",
+ "upId": "parent"
+ },
+ {
+ "id": "thing2",
+ "upId": "parent"
+ }
+ ]
+
+ This would indicate that for the first item in the collection, it's
+ own (self) URI would resolve to "/Resource/thing" and the first
+ item's "up" relation should be resolved to the resource at
+ "/Resource/parent". The "children" collection would be located at
+ "/Resource/?upId=thing".
+
+6.1.1.3. Submission Link Properties
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means
+ for submitting extra (often user supplied) information to send to a
+ server.
+
+6.1.1.3.1. method
+
+ This indicates which method should be used to access the target
+ resource. In an HTTP environment, this would be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+6.1.1.3.2. enctype
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method). For example, with
+ the following schema:
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 16]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ {
+ "links":[
+ {
+ "enctype": "application/x-www-form-urlencoded",
+ "method": "GET",
+ "href": "/Product/",
+ "properties":{
+ "name":{"description":"name of the product"}
+ }
+ }
+ ]
+ }
+
+ This indicates that the client can query the server for instances
+ that have a specific name:
+
+
+ /Product/?name=Slinky
+
+ If no enctype or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST, application/
+ json is the default media type.
+
+6.1.1.3.3. properties
+
+ This is inherited from the base JSON schema definition, and can
+ follow the same structure, but its meaning should be used to define
+ the acceptable property names and values for the action (whether it
+ be for the GET query or POST body). If properties are omitted, and
+ this form is the child of a schema, the properties from the parent
+ schema should be used as the basis for the form action.
+
+6.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "dot-delimited", which is defined below.
+ Other fragment resolution protocols may be used, but are not defined
+ in this document.
+
+ The fragment identifier is based on RFC 2396 Sec 5, and defines the
+ mechanism for resolving references to entities within a document.
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 17]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+6.2.1. dot-delimited fragment resolution
+
+ With the dot-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens
+ that are delimited by the "." character (\x2E). Each property
+ reference token is a series of any legal URI component characters
+ except the "." character. Each property reference token should be
+ interpreted, starting from the beginning of the fragment identifier,
+ as a path reference in the target JSON structure. The final target
+ value of the fragment can be determined by starting with the root of
+ the JSON structure from the representation of the resource identified
+ by the pre-fragment URI. If the target is a JSON object, than the
+ new target is the value of the property with the name identified by
+ the next property reference token in the fragment. If the target is
+ a JSON array, than the target is determined by finding the item in
+ array the array with the index defined by the next property reference
+ token (which MUST be a number). The target is successively updated
+ for each property reference token, until the entire fragment has been
+ traversed.
+
+ Property names SHOULD be URI-encoded. In particular, any "." in a
+ property name MUST be encoded to avoid being interpreted as a
+ property delimiter.
+
+ For example, for the following JSON representation:
+
+
+ {
+ "foo":{
+ "anArray":[
+ {"prop":44}
+ ],
+ "another prop":{
+ "baz":"A string"
+ }
+ }
+ }
+
+ The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 18]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ fragment identifier resolution
+ ------------------- ----------
+ # self, the root of the resource itself
+ #foo the object referred to by the foo property
+ #foo.another prop the object referred to by the "another prop"
+ property of the object referred to by the
+ "foo" property
+ #foo.another prop.baz the string referred to by the value of "baz"
+ property of the "another prop" property of
+ the object referred to by the "foo" property
+ #foo.anArray.0 the first object in the "anArray" array
+
+6.3. root
+
+ This attribute indicates that the value of the instance property
+ value SHOULD be treated as the root or the body of the representation
+ for the purposes of user agent interaction and fragment resolution
+ (all other properties of the instance objects are can be regarded as
+ meta-data descriptions for the data).
+
+6.4. readonly
+
+ This indicates that the instance property should not be changed.
+ Attempts by a user agent to modify the value of this property are
+ expected to be rejected by a server.
+
+6.5. pathStart
+
+ This property value is a URI-Reference that indicates the URI that
+ all the URIs for the instances of the schema should start with. When
+ multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance
+ by determining if URI of the instance begins with the pathStart's
+ referenced URI. pathStart MUST be resolved as per [RFC3986] section
+ 5. If the URI of the instance does not start with URI indicated by
+ pathStart, or if another schema specifies a starting URI that is
+ longer and also matches the instance, this schema should not be
+ applied to the instance. Any schema that does not have a pathStart
+ attribute should be considered applicable to all the instances for
+ which it is referenced.
+
+6.6. mediaType
+
+ This indicates the media type of the instance representations that
+ this schema is defining.
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 19]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+6.7. alternate
+
+ This is an array of JSON schema definitions that define any other
+ schemas for alternate JSON-based representations of the instance
+ resources.
+
+7. Security Considerations
+
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self" is
+ used to denote a full representation of an object, the user agent
+ SHOULD NOT consider the representation to be the authoritative
+ representation of the resource denoted by the target URI if the
+ target URI is not equivalent to or a sub-path of the the URI used to
+ request the resource representation which contains the target URI
+ with the "self" link. For example, if a hyper schema was defined:
+
+
+ {
+ "links":[
+ {
+ "rel":"self",
+ "href":"{id}"
+ }
+ ]
+ }
+
+ And a resource was requested from somesite.com:
+
+
+ GET /foo/
+
+ With a response of:
+
+
+Content-Type: application/json; describedby=/schema-for-this-data
+[
+ {"id":"bar", "name":"This representation can be safely treated \
+ as authoritative "},
+ {"id":"/baz", "name":"This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from "/baz" to ensure it has the authoritative representation"},
+ {"id":"http://othersite.com/something", "name":"This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"}
+]
+
+
+
+Zyp Expires June 8, 2010 [Page 20]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+8. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is application/
+ schema+json
+
+ Type name: application
+
+ Subtype name: schema+json
+
+ Required parameters: describedby
+
+ The value of the describedby parameter should be a URI (relative or
+ absolute) that refers to the schema used to define the structure of
+ this structure (the meta-schema). Normally the value would be
+ http://json-schema.org/hyper-schema, but it is allowable to use other
+ schemas that extend the hyper schema's meta- schema.
+
+ Optional parameters: pretty
+
+ The value of the pretty parameter may be true or false to indicate if
+ additional whitespace has been included to make the JSON
+ representation easier to read.
+
+8.1. Registry of Link Relations
+
+ This registry is maintained by IANA per RFC 4287 and this
+ specification adds three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+9. References
+
+9.1. Normative References
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in
+ RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC4287] Nottingham, M., Ed. and R. Sayre,
+ Ed., "The Atom Syndication
+ Format", RFC 4287, December 2005.
+
+
+
+Zyp Expires June 8, 2010 [Page 21]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+ [RFC3339] Klyne, G., Ed. and C. Newman,
+ "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC2045] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format
+ of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+9.2. Informative References
+
+ [RFC4627] Crockford, D., "The application/
+ json Media Type for JavaScript
+ Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul,
+ J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC5226] Narten, T. and H. Alvestrand,
+ "Guidelines for Writing an IANA
+ Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [I-D.hammer-discovery] Hammer-Lahav, E., "Link-based
+ Resource Descriptor Discovery",
+ draft-hammer-discovery-03 (work in
+ progress), March 2009.
+
+ [I-D.gregorio-uritemplate] Gregorio, J., "URI Template",
+ draft-gregorio-uritemplate-03
+ (work in progress), April 2008.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-06
+ (work in progress), July 2009.
+
+ [W3C.REC-html401-19991224] Hors, A., Jacobs, I., and D.
+ Raggett, "HTML 4.01
+ Specification", World Wide Web
+ Consortium Recommendation REC-
+ html401-19991224, December 1999, <
+ http://www.w3.org/TR/1999/
+ REC-html401-19991224>.
+
+
+
+Zyp Expires June 8, 2010 [Page 22]
+
+Internet-Draft JSON Schema Media Type December 2009
+
+
+Appendix A. Change Log
+
+ -01
+
+ o Fixed category and updates from template
+
+ -00
+
+ o Initial draft
+
+Appendix B. Open Issues
+
+ Should we give a preference to MIME headers over Link headers (or
+ only use one)?
+
+ Should we use "profile" as the media type parameter instead?
+
+ Should "root" be a MIME parameter instead of a schema attribute?
+
+ Should "format" be renamed to "mediaType" or "contentType" to reflect
+ the usage MIME media types that are allowed.
+
+ I still do not like how dates are handled.
+
+Author's Address
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires June 8, 2010 [Page 23]
+
+
diff --git a/draft-zyp-json-schema-01.xml b/draft-zyp-json-schema-01.xml
new file mode 100644
index 00000000..215d9278
--- /dev/null
+++ b/draft-zyp-json-schema-01.xml
@@ -0,0 +1,897 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+
+ SitePen (USA)
+
+
+
+ 530 Lytton Avenue
+
+ Palo Alto, CA 94301
+
+ USA
+
+
+ +1 650 968 8787
+
+ kris@sitepen.com
+
+
+
+
+
+ Internet Engineering Task Force
+
+ JSON
+
+ Schema
+
+ Hyper Schema
+
+ Hypermedia
+
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+ 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.
+
+
+
+
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+
+This schema defines the properties of the instance JSON documents and
+their required properties (id, name, and price) as well as an optional
+property (tags). This also defines the link relations of the instance
+JSON documents.
+
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that the schema
+ will be describing and validating
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. This specification does not define a protocol.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a REST
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the application/json media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "describedby" or a Link header with a relation of "describedby" SHOULD be used:
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+ ; rel="describedby"
+]]>
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data. The instance data may have multiple schemas
+ that it is defined by (the instance data should be valid for those schemas).
+ Or if the document is a collection of instances, the collection may contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the pathStart attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection.
+
+
+
+ JSON Schemas are themselves instances for the schema
+ schemas. A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema and the hyper schema
+ self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ of the instance and defines it's usage and valid values. A JSON
+ Schema is a JSON Object with schema attribute properties.
+ The following is the grammar of a JSON Schema:
+
+
+
+ And an example JSON Schema definition could look like:
+
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array may be a simple type definition or a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas in the array. For example to indicate that a string or number is a valid:
+{"type":["string","number"]}
+Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+
+string - Value must be a string.
+
+number - Value must be a number, floating point numbers are allowed.
+integer - Value must be an integer, no floating point numbers are allowed. This is a subset of the number type.
+boolean - Value must be a boolean.
+object - Value must be an object.
+array - Value must be an array.
+
+null - Value must be null. Note this is mainly for purpose of being able use union types to define nullability.
+any - Value may be of any type including null.
+If the property is not defined or is not in this list, than any type of value is acceptable. Other type values may be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+
+
+
+
+
+This should be an object type definition, which is an object with property definitions that correspond to instance object properties. When the instance value is an object, the property values of the instance object must conform to the property definitions in this object. In this object, each property definition's value should be a schema, and the property's name should be the name of the instance property that it defines.
+
+
+This should be a schema or an array of schemas. When this is an object/schema and the instance value is an array, all the items in the array must conform to this schema. When this is an array of schemas and the instance value is an array, each position in the instance array must conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalProperties attribute using the same rules as extra properties for objects..
+
+
+This indicates that the instance property in the instance object is optional. This is false by default.
+
+
+This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties.
+
+
+This indicates that if this property is present in the containing instance object, the property given by requires attribute must also be present in the containing instance object. The value
+of this property may be a string, indicating the require property name. Or the value may be a schema, in which case the containing instance must be valid by the schema if the property is present. For example if a object type definition is defined:
+
+
+
+
+An instance must include a state property if a town property is included. If a town property is not included, the state property is optional.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+If the minimum is defined, this indicates whether or not the instance property value can equal the minimum.
+
+
+If the maximum is defined, this indicates whether or not the instance property value can equal the maximum.
+
+
+This indicates the minimum number of values in an array when an array is the instance value.
+
+
+This indicates the maximum number of values in an array when an array is the instance value.
+
+
+When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid. Regular expressions should follow the regular expression specification from ECMA 262/Perl 5
+
+When the instance value is a string, this indicates maximum length of the string.
+
+
+When the instance value is a string, this indicates minimum length of the string.
+
+
+This provides an enumeration of possible values that are valid for the instance property. This should be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value must be one of the values in enum array in order for the schema to be valid.
+
+
+This provides a short description of the instance property. The value must be a string.
+
+
+This provides a full description of the of purpose the instance property. The value must be a string.
+
+This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute may be one of the values listed below, and if so, should adhere to the semantics describing for the format. A format should only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
+Any valid MIME media type may be used as a format value, in which case the instance property value must be a string, representing the contents of the MIME file.
+date-time - This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+date - This should be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+time - This should be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+utc-millisec - This should be the difference, measured in milliseconds, between the specified time and midnight, January 1, 1970 UTC. The value should be a number (integer or float).
+regex - A regular expression.
+color - This is a CSS color (like "#FF0000" or "red").
+style - This is a CSS style definition (like "color: red; background-color:#FFF").
+phone - This should be a phone number (format may follow E.123).
+uri - This value should be a URI..
+email - This should be an email address.
+ip-address - This should be an ip version 4 address.
+ipv6 - This should be an ip version 6 address.
+street-address - This should be a street address.
+locality - This should be a city or town.
+region - This should be a region (a state in the US, province in Canada, etc.)
+postal-code - This should be a postal code (AKA zip code).
+country - This should be the name of a country.
+Additional custom formats may be defined with a URL to a definition of the format.
+
+
+
+If the instance property value is a string, this indicates that the string should be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+
+
+
+This indicates the default for the instance property.
+
+
+This indicates the maximum number of decimal places in a floating point number. By default there is no maximum.
+
+
+This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, than this instance is not valid.
+
+
+The value of this property should be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema must be valid according to the referenced schema. This may also be an array, in which case, the instance must be valid for all the schemas in the array.
+
+
+
+ This section defines hypermedia definitions of JSON schema.
+ The following attributes are specified in addition to those
+attributes that already provided by JSON schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper-schema are optional.
+Therefore an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+
+The value of the links property should be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+
+A link description object is used to describe the link relations
+of instances of a schema.
+
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property should be resolved as a URI-Reference per [RFC3986]
+and may be a relative URI. The base URI to be used for relative resolution
+should be the URI used to retrieve the instance object (not the schema).
+Also, the URI may be parametrized by the property values of the instance
+object.
+
+
+Instance property values should be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+
+If matching braces are found with the string "-this" (no quotes) between the braces, than the
+actual instance value should be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target should be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource must be indicated with the schema describing the top level JSON representation.
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+self - If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link may not be the full representation.
+
+
+describedby - This indicates the target of the link is the schema for the instance object. This may be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+
+
+instances - This indicates the target resource that represents collection of instances of a schema.
+
+
+create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+For example, if a schema is defined:
+
+
+
+
+And if a collection of instance resource's JSON representation was
+retrieved:
+
+
+
+
+
+This would indicate that for the first item in the collection, it's own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation should be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+This indicates which method should be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, application/json is
+the default media type.
+
+
+
+
+This is inherited from the base JSON schema definition, and can follow the
+same structure, but its meaning should be used to define the acceptable
+property names and values for the action (whether it be for the GET query
+or POST body). If properties are omitted, and this form is the child of a
+schema, the properties from the parent schema should be used as the basis
+for the form action.
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "dot-delimited", which is defined below. Other fragment
+resolution protocols may be used, but are not defined in this
+document.
+
+
+
+The fragment identifier is based on RFC 2396 Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
+With the dot-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that
+are delimited by the "." character (\x2E). Each property reference token
+is a series of any legal URI component characters except the "." character. Each property
+reference token should be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, than the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, than the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+Property names SHOULD be URI-encoded. In particular, any "." in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+For example, for the following JSON representation:
+
+
+
+
+The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+
+
+
+
+ This attribute indicates that the value of the instance property value
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
+
+
+This indicates that the instance property should not be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+
+ This property value is a URI-Reference that indicates the URI that all
+the URIs for the instances of the schema should start with. When
+multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if URI of the instance begins with the pathStart's referenced
+URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+the instance does not start with URI indicated by pathStart, or if another
+schema specifies a starting URI that is longer and also matches the
+instance, this schema should not be applied to the instance. Any schema
+that does not have a pathStart attribute should be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+
+
+
+ This indicates the media type of the instance representations that this schema is defining.
+
+
+
+
+
+ This is an array of JSON schema definitions that define any
+ other schemas for alternate JSON-based representations
+ of the instance resources.
+
+
+
+
+
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC
+4627. However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+
+
+And a resource was requested from somesite.com:
+
+
+
+
+
+With a response of:
+
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is application/schema+json
+
+
+ Type name: application
+
+
+ Subtype name: schema+json
+
+
+ Required parameters: describedby
+
+
+ The value of the describedby parameter should be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+ Optional parameters: pretty
+
+
+ The value of the pretty parameter may be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+
+
+
+
+ &rfc3986;
+ &rfc2119;
+ &rfc4287;
+ &rfc3339;
+ &rfc2045;
+
+
+
+ &rfc4627;
+ &rfc2616;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+
+
+
+
+
+ -01
+
+
+ Fixed category and updates from template
+
+
+ -00
+
+
+ Initial draft
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should we use "profile" as the media type parameter instead?
+ Should "root" be a MIME parameter instead of a schema attribute?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed.
+ I still do not like how dates are handled.
+
+
+
+
+
+
diff --git a/draft-zyp-json-schema-02.txt b/draft-zyp-json-schema-02.txt
new file mode 100644
index 00000000..5e72feeb
--- /dev/null
+++ b/draft-zyp-json-schema-02.txt
@@ -0,0 +1,1345 @@
+
+
+
+Internet Engineering Task Force K. Zyp, Ed.
+Internet-Draft SitePen (USA)
+Intended status: Informational March 23, 2010
+Expires: September 24, 2010
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON
+ Documents
+ draft-zyp-json-schema-02
+
+Abstract
+
+ JSON (JavaScript Object Notation) Schema defines the media type
+ application/schema+json, a JSON based format for defining the
+ structure of JSON data. JSON Schema provides a contract for what
+ JSON data is required for a given application and how to interact
+ with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 24, 2010.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Zyp Expires September 24, 2010 [Page 1]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ 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 BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Design Considerations . . . . . . . . . . . . . . . . . . 6
+ 4. Schema/Instance Association . . . . . . . . . . . . . . . . . 6
+ 4.1. Self-Descriptive Schema . . . . . . . . . . . . . . . . . 7
+ 5. Core Schema Definition . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. type . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2. properties . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.3. items . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.4. optional . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.5. additionalProperties . . . . . . . . . . . . . . . . . . . 9
+ 5.6. requires . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.7. minimum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.8. maximum . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.9. minimumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.10. maximumCanEqual . . . . . . . . . . . . . . . . . . . . . 10
+ 5.11. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.12. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.13. uniqueItems . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.14. pattern . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.15. maxLength . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.16. minLength . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.17. enum . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.18. title . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.19. description . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.20. format . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.21. contentEncoding . . . . . . . . . . . . . . . . . . . . . 12
+ 5.22. default . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.23. divisibleBy . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.24. disallow . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.25. extends . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Hyper Schema . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.1.1. Link Description Object . . . . . . . . . . . . . . . 14
+
+
+
+Zyp Expires September 24, 2010 [Page 2]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ 6.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 18
+ 6.2.1. dot-delimited fragment resolution . . . . . . . . . . 18
+ 6.2.2. slash-delimited fragment resolution . . . . . . . . . 19
+ 6.3. root . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.4. readonly . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6.5. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.6. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 6.7. alternate . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 8.1. Registry of Link Relations . . . . . . . . . . . . . . . . 21
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
+ Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 3]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+1. Introduction
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for
+ defining the structure of JSON data. JSON Schema provides a contract
+ for what JSON data is required for a given application and how to
+ interact with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+2. Conventions
+
+ 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.
+
+3. Overview
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other JSON documents. JSON Schema is
+ JSON-based and includes facilities for describing the structure of
+ JSON documents in terms of allowable values, descriptions, and
+ interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions.
+ The first definition is the core schema specification. This
+ definition is primary concerned with describing a JSON structure and
+ specifying valid elements in the structure. The second definition is
+ the Hyper Schema specification which is intended define elements in a
+ structure that can be interpreted as hyperlinks. Hyper Schema builds
+ on JSON Schema to describe the hyperlink structure of other JSON
+ documents. This allows user agents to be able to successfully
+ navigate JSON documents based on their schemas.
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to
+ define the required type and constraints on property values, as well
+ as define the meaning of the property values for the purpose of
+ describing a resource and determining hyperlinks within the
+ representation.
+
+ An example JSON Schema that describes products might look like:
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 4]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ {
+ "name":"Product",
+ "properties":{
+ "id":{
+ "type":"number",
+ "description":"Product identifier"
+ },
+ "name":{
+ "description":"Name of the product",
+ "type":"string"
+ },
+ "price":{
+ "type": "number",
+ "minimum":0
+ },
+ "tags":{
+ "optional":true,
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ }
+ },
+ "links":[
+ {
+ "rel":"full",
+ "href":"{id}"
+ },
+ {
+ "rel":"comments",
+ "href":"comments/?id={id}"
+ }
+ ]
+ }
+
+ This schema defines the properties of the instance JSON documents and
+ their required properties (id, name, and price) as well as an
+ optional property (tags). This also defines the link relations of
+ the instance JSON documents.
+
+3.1. Terminology
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that
+ the schema will be describing and validating
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 5]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+3.2. Design Considerations
+
+ The JSON Schema media type does not attempt to dictate the structure
+ of JSON representations that contain data, but rather provides a
+ separate format for flexibly communicating how a JSON representation
+ should be interpreted and validated, such that user agents can
+ properly understand acceptable structures and extrapolate hyperlink
+ information with the JSON document. It is acknowledged that JSON
+ documents come in a variety of structures, and JSON is unique in that
+ the structure of stored data structures often prescribes a non-
+ ambiguous definite JSON representation. Attempting to force a
+ specific structure is generally not viable, and therefore JSON Schema
+ allows for great flexibility in the structure of JSON data that it
+ describes.
+
+ This specification is protocol agnostic. The underlying protocol
+ (such as HTTP) should sufficiently define the semantics of the
+ client-server interface, the retrieval of resource representations
+ linked to by JSON representations, and modification of those
+ resources. The goal of this format is to sufficiently describe JSON
+ structures such that one can utilize existing information available
+ in existing JSON representations from a large variety of services
+ that leverage a representational state transfer architecture using
+ existing protocols.
+
+4. Schema/Instance Association
+
+ JSON Schema instances are correlated to their schema by the
+ "describedby" relation, where the schema is defined to be the target
+ of the relation. Instance representations may be of the application/
+ json media type or any other subtype. Consequently, dictating how an
+ instance representation should specify the relation to the schema is
+ beyond the normative scope of this document (since this document
+ specifically defines the JSON Schema media type, and no other), but
+ it is recommended that instances specify their schema so that user
+ agents can interpret the instance representation and messages may
+ retain the self-descriptive characteristic, avoiding the need for
+ out-of-band information about instance data. Two approaches are
+ recommended for declaring the relation to the schema that describes
+ the meaning of a JSON instance's (or collection of instances)
+ structure. A MIME type parameter named "profile" or a Link header
+ with a relation of "describedby" SHOULD be used:
+
+
+ Content-Type: application/json;
+ profile=http://json.com/my-hyper-schema
+
+ or if the content is being transferred by a protocol (such as HTTP)
+
+
+
+Zyp Expires September 24, 2010 [Page 6]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ that provides headers, a Link header can be used:
+
+
+ Link: ; rel="describedby"
+
+ Instances MAY specify multiple schemas, to indicate all the schemas
+ that are applicable to the data. The instance data may have multiple
+ schemas that it is defined by (the instance data should be valid for
+ those schemas). Or if the document is a collection of instances, the
+ collection may contain instances from different schemas. When
+ collections contain heterogeneous instances, the pathStart attribute
+ MAY be specified in the schema to disambiguate which schema should be
+ applied for each item in the collection.
+
+4.1. Self-Descriptive Schema
+
+ JSON Schemas are themselves instances for the schema schemas. A
+ self-describing JSON Schema for the core JSON Schema can be found at
+ http://json-schema.org/schema and the hyper schema self-description
+ can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions SHOULD include a
+ MIME parameter that refers to the self-descriptive hyper schema or
+ another schema that extends this hyper schema:
+
+
+ Content-Type: application/json;
+ profile=http://www.json-schema.org/hyper-schema
+
+5. Core Schema Definition
+
+ A JSON Schema is a JSON Object that defines various attributes of the
+ instance and defines it's usage and valid values. A JSON Schema is a
+ JSON Object with schema attribute properties. The following is the
+ grammar of a JSON Schema:
+
+ And an example JSON Schema definition could look like:
+
+
+ {"description":"A person",
+ "type":"object",
+
+ "properties":
+ {"name": {"type":"string"},
+ "age" : {"type":"integer",
+ "maximum":125}}
+ }
+
+ A JSON Schema object may have any of the following properties, called
+
+
+
+Zyp Expires September 24, 2010 [Page 7]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ schema attributes (all attributes are optional):
+
+5.1. type
+
+ Union type definition - An array with two or more items which
+ indicates a union of type definitions. Each item in the array may
+ be a simple type definition or a schema. The instance value is
+ valid if it is of the same type as one the type definitions in the
+ array or if it is valid by one of the schemas in the array. For
+ example to indicate that a string or number is a valid: {"type":
+ ["string","number"]}
+
+ Simple type definition - A string indicating a primitive or simple
+ type. The following are acceptable strings:
+
+ string - Value must be a string.
+
+ number - Value must be a number, floating point numbers are
+ allowed.
+
+ integer - Value must be an integer, no floating point numbers
+ are allowed. This is a subset of the number type.
+
+ boolean - Value must be a boolean.
+
+ object - Value must be an object.
+
+ array - Value must be an array.
+
+ null - Value must be null. Note this is mainly for purpose of
+ being able use union types to define nullability.
+
+ any - Value may be of any type including null. If the property
+ is not defined or is not in this list, than any type of value
+ is acceptable. Other type values may be used for custom
+ purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type
+ values.
+
+5.2. properties
+
+ This should be an object type definition, which is an object with
+ property definitions that correspond to instance object properties.
+ When the instance value is an object, the property values of the
+ instance object must conform to the property definitions in this
+ object. In this object, each property definition's value should be a
+ schema, and the property's name should be the name of the instance
+ property that it defines.
+
+
+
+Zyp Expires September 24, 2010 [Page 8]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+5.3. items
+
+ This should be a schema or an array of schemas. When this is an
+ object/schema and the instance value is an array, all the items in
+ the array must conform to this schema. When this is an array of
+ schemas and the instance value is an array, each position in the
+ instance array must conform to the schema in the corresponding
+ position for this array. This called tuple typing. When tuple
+ typing is used, additional items are allowed, disallowed, or
+ constrained by the additionalProperties attribute using the same
+ rules as extra properties for objects. The default value is an empty
+ schema which allows any value for items in the instance array.
+
+5.4. optional
+
+ This indicates that the instance property in the instance object is
+ optional. This is false by default.
+
+5.5. additionalProperties
+
+ This provides a default property definition for all properties that
+ are not explicitly defined in an object type definition. The value
+ must be a schema. If false is provided, no additional properties are
+ allowed, and the schema can not be extended. The default value is an
+ empty schema which allows any value for additional properties.
+
+5.6. requires
+
+ This indicates that if this property is present in the containing
+ instance object, the property given by requires attribute must also
+ be present in the containing instance object. The value of this
+ property may be a string, indicating the require property name. Or
+ the value may be a schema, in which case the containing instance must
+ be valid by the schema if the property is present. For example if a
+ object type definition is defined:
+
+
+ {
+ "state":
+ {
+ "optional":true
+ },
+ "town":
+ {
+ "requires":"state",
+ "optional":true
+ }
+ }
+
+
+
+Zyp Expires September 24, 2010 [Page 9]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ An instance must include a state property if a town property is
+ included. If a town property is not included, the state property is
+ optional.
+
+5.7. minimum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.8. maximum
+
+ This indicates the minimum value for the instance property when the
+ type of the instance value is a number.
+
+5.9. minimumCanEqual
+
+ If the minimum is defined, this indicates whether or not the instance
+ property value can equal the minimum.
+
+5.10. maximumCanEqual
+
+ If the maximum is defined, this indicates whether or not the instance
+ property value can equal the maximum.
+
+5.11. minItems
+
+ This indicates the minimum number of values in an array when an array
+ is the instance value.
+
+5.12. maxItems
+
+ This indicates the maximum number of values in an array when an array
+ is the instance value.
+
+5.13. uniqueItems
+
+ This indicates that all the items in an array must be unique (no two
+ identical values) within that array when an array is the instance
+ value.
+
+5.14. pattern
+
+ When the instance value is a string, this provides a regular
+ expression that a instance string value should match in order to be
+ valid. Regular expressions should follow the regular expression
+ specification from ECMA 262/Perl 5
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 10]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+5.15. maxLength
+
+ When the instance value is a string, this indicates maximum length of
+ the string.
+
+5.16. minLength
+
+ When the instance value is a string, this indicates minimum length of
+ the string.
+
+5.17. enum
+
+ This provides an enumeration of possible values that are valid for
+ the instance property. This should be an array, and each item in the
+ array represents a possible value for the instance value. If "enum"
+ is included, the instance value must be one of the values in enum
+ array in order for the schema to be valid.
+
+5.18. title
+
+ This provides a short description of the instance property. The
+ value must be a string.
+
+5.19. description
+
+ This provides a full description of the of purpose the instance
+ property. The value must be a string.
+
+5.20. format
+
+ This property indicates the type of data, content type, or
+ microformat to be expected in the instance property values. A format
+ attribute may be one of the values listed below, and if so, should
+ adhere to the semantics describing for the format. A format should
+ only be used give meaning to primitive types (string, integer,
+ number, or boolean). Validators are not required to validate that
+ the instance values conform to a format. The following formats are
+ defined:
+
+ Any valid MIME media type may be used as a format value, in which
+ case the instance property value must be a string, representing
+ the contents of the MIME file.
+
+ date-time - This should be a date in ISO 8601 format of YYYY-MM-
+ DDThh:mm:ssZ in UTC time. This is the recommended form of date/
+ timestamp.
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 11]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ date - This should be a date in the format of YYYY-MM-DD. It is
+ recommended that you use the "date-time" format instead of "date"
+ unless you need to transfer only the date part.
+
+ time - This should be a time in the format of hh:mm:ss. It is
+ recommended that you use the "date-time" format instead of "time"
+ unless you need to transfer only the time part.
+
+ utc-millisec - This should be the difference, measured in
+ milliseconds, between the specified time and midnight, January 1,
+ 1970 UTC. The value should be a number (integer or float).
+
+ regex - A regular expression.
+
+ color - This is a CSS color (like "#FF0000" or "red").
+
+ style - This is a CSS style definition (like "color: red;
+ background-color:#FFF").
+
+ phone - This should be a phone number (format may follow E.123).
+
+ uri - This value should be a URI..
+
+ email - This should be an email address.
+
+ ip-address - This should be an ip version 4 address.
+
+ ipv6 - This should be an ip version 6 address.
+
+ street-address - This should be a street address.
+
+ locality - This should be a city or town.
+
+ region - This should be a region (a state in the US, province in
+ Canada, etc.)
+
+ postal-code - This should be a postal code (AKA zip code).
+
+ country - This should be the name of a country.
+
+ Additional custom formats may be defined with a URL to a
+ definition of the format.
+
+5.21. contentEncoding
+
+ If the instance property value is a string, this indicates that the
+ string should be interpreted as binary data and decoded using the
+ encoding named by this schema property. RFC 2045, Sec 6.1 lists
+
+
+
+Zyp Expires September 24, 2010 [Page 12]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ possible values.
+
+5.22. default
+
+ This indicates the default for the instance property.
+
+5.23. divisibleBy
+
+ This indicates that the instance property value must be divisible by
+ the given schema value when the instance property value is a number.
+
+5.24. disallow
+
+ This attribute may take the same values as the "type" attribute,
+ however if the instance matches the type or if this value is an array
+ and the instance matches any type or schema in the array, than this
+ instance is not valid.
+
+5.25. extends
+
+ The value of this property should be another schema which will
+ provide a base schema which the current schema will inherit from.
+ The inheritance rules are such that any instance that is valid
+ according to the current schema must be valid according to the
+ referenced schema. This may also be an array, in which case, the
+ instance must be valid for all the schemas in the array.
+
+6. Hyper Schema
+
+ This section defines hypermedia definitions of JSON schema. The
+ following attributes are specified in addition to those attributes
+ that already provided by JSON schema with the specific purpose of
+ informing user agents of relations between resources based on JSON
+ data. Just as with JSON schema attributes, all the attributes in
+ hyper-schema are optional. Therefore an empty object is a valid
+ (non-informative) schema, and essentially describes plain JSON (no
+ constraints on the structures). Addition of attributes provides
+ additive information for user agents.
+
+6.1. links
+
+ The value of the links property should be an array, where each item
+ in the array is a link description object which describes the link
+ relations of the instances.
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 13]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+6.1.1. Link Description Object
+
+ A link description object is used to describe the link relations. In
+ the context of a schema, it defines the link relations of the
+ instances of the schema, and can be parameterized by the instance
+ values. The link description format can be used on its own in
+ regular (non-schema documents), and use of this format can be
+ declared by referencing the normative link description schema as the
+ the schema for the data structure that uses the links. The URI of
+ the normative link description schema is:
+ http://json-schema.org/links.
+
+6.1.1.1. href
+
+ The value of the "href" link description property indicates the
+ target URI of the related resource. The value of the instance
+ property should be resolved as a URI-Reference per [RFC3986] and may
+ be a relative URI. The base URI to be used for relative resolution
+ should be the URI used to retrieve the instance object (not the
+ schema) when used in the context of a schema. Also, the URI may be
+ parametrized by the property values of the instance object.
+
+ Instance property values should be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute. For example, if an href value is defined:
+
+
+ http://somesite.com/{id}
+
+ Then it would be resolved by replace the value of the "id" property
+ value from the instance object. If the value of the "id" property
+ was "45", the expanded URI would be:
+
+
+ http://somesite.com/45
+
+ If matching braces are found with the string "-this" (no quotes)
+ between the braces, than the actual instance value should be used to
+ replace the braces, rather than a property value. This should only
+ be used in situations where the instance is a scalar (string,
+ boolean, or number), and not for objects or arrays.
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 14]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+6.1.1.2. rel
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target should be
+ interpreted as specifically from the instance object that the schema
+ (or sub-schema) applies to, not just the top level resource that
+ contains the object within its hierarchy. If a resource JSON
+ representation contains a sub object with a property interpreted as a
+ link, that sub-object holds the relation with the target. A relation
+ to target from the top level resource must be indicated with the
+ schema describing the top level JSON representation.
+
+ Relationship definitions SHOULD NOT be media type dependent, and
+ users are encouraged to utilize existing accepted relation
+ definitions, including those in existing relation registries (see
+ &rfc4287). However, we define these relation here for clarity of
+ normative interpretation within the context of JSON hyper schema
+ defined relations:
+
+ self - If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the specified
+ URI.
+
+ full - This indicates that the target of the link is the full
+ representation for the instance object. The object that contains
+ this link may not be the full representation.
+
+ describedby - This indicates the target of the link is the schema
+ for the instance object. This may be used to specifically denote
+ the schemas of objects within a JSON object hierarchy,
+ facilitating polymorphic type data structures.
+
+ The following relations are applicable for schemas (the schema as
+ the "from" resource in the relation).
+
+ instances - This indicates the target resource that represents
+ collection of instances of a schema.
+
+ create - This indicates a target to use for creating new instances
+ of a schema. This link definition SHOULD be a submission link
+ with a non-safe method (like POST).
+
+ For example, if a schema is defined:
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 15]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ {
+ "links": [
+ {
+ "rel": "self"
+ "href": "{id}"
+ },
+ {
+ "rel": "up"
+ "href": "{upId}"
+ },
+ {
+ "rel": "children"
+ "href": "?upId={id}"
+ }
+ ]
+ }
+
+ And if a collection of instance resource's JSON representation was
+ retrieved:
+
+
+ GET /Resource/
+
+ [
+ {
+ "id": "thing",
+ "upId": "parent"
+ },
+ {
+ "id": "thing2",
+ "upId": "parent"
+ }
+ ]
+
+ This would indicate that for the first item in the collection, it's
+ own (self) URI would resolve to "/Resource/thing" and the first
+ item's "up" relation should be resolved to the resource at
+ "/Resource/parent". The "children" collection would be located at
+ "/Resource/?upId=thing".
+
+6.1.1.2.1. targetSchema
+
+ This property value can be a schema that defines the expected
+ structure of the JSON representation of the target of the link.
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 16]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+6.1.1.3. Submission Link Properties
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means
+ for submitting extra (often user supplied) information to send to a
+ server.
+
+6.1.1.3.1. method
+
+ This indicates which method should be used to access the target
+ resource. In an HTTP environment, this would be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+6.1.1.3.2. enctype
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method). For example, with
+ the following schema:
+
+
+ {
+ "links":[
+ {
+ "enctype": "application/x-www-form-urlencoded",
+ "method": "GET",
+ "href": "/Product/",
+ "properties":{
+ "name":{"description":"name of the product"}
+ }
+ }
+ ]
+ }
+
+ This indicates that the client can query the server for instances
+ that have a specific name:
+
+
+ /Product/?name=Slinky
+
+ If no enctype or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST, application/
+ json is the default media type.
+
+
+
+Zyp Expires September 24, 2010 [Page 17]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+6.1.1.3.3. properties
+
+ This is inherited from the base JSON schema definition, and can
+ follow the same structure, but its meaning should be used to define
+ the acceptable property names and values for the action (whether it
+ be for the GET query or POST body). If properties are omitted, and
+ this form is the child of a schema, the properties from the parent
+ schema should be used as the basis for the form action.
+
+6.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "slash-delimited", which is defined below.
+ Other fragment resolution protocols may be used, but are not defined
+ in this document.
+
+ The fragment identifier is based on RFC 2396 Sec 5, and defines the
+ mechanism for resolving references to entities within a document.
+
+6.2.1. dot-delimited fragment resolution
+
+ With the dot-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens
+ that are delimited by the "." character (\x2E). Each property
+ reference token is a series of any legal URI component characters
+ except the "." character. Each property reference token should be
+ interpreted, starting from the beginning of the fragment identifier,
+ as a path reference in the target JSON structure. The final target
+ value of the fragment can be determined by starting with the root of
+ the JSON structure from the representation of the resource identified
+ by the pre-fragment URI. If the target is a JSON object, than the
+ new target is the value of the property with the name identified by
+ the next property reference token in the fragment. If the target is
+ a JSON array, than the target is determined by finding the item in
+ array the array with the index defined by the next property reference
+ token (which MUST be a number). The target is successively updated
+ for each property reference token, until the entire fragment has been
+ traversed.
+
+ Property names SHOULD be URI-encoded. In particular, any "." in a
+ property name MUST be encoded to avoid being interpreted as a
+ property delimiter.
+
+ For example, for the following JSON representation:
+
+
+
+
+Zyp Expires September 24, 2010 [Page 18]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ {
+ "foo":{
+ "anArray":[
+ {"prop":44}
+ ],
+ "another prop":{
+ "baz":"A string"
+ }
+ }
+ }
+
+ The following fragment identifiers would be resolved:
+
+
+ fragment identifier resolution
+ ------------------- ----------
+ # self, the root of the resource itself
+ #foo the object referred to by the foo property
+ #foo.another prop the object referred to by the "another prop"
+ property of the object referred to by the
+ "foo" property
+ #foo.another prop.baz the string referred to by the value of "baz"
+ property of the "another prop" property of
+ the object referred to by the "foo" property
+ #foo.anArray.0 the first object in the "anArray" array
+
+6.2.2. slash-delimited fragment resolution
+
+ The slash-delimited fragment resolution protocol is exactly the same
+ as dot-delimited fragment resolution protocol except that the "/"
+ character (\x2F) is used as the delimiter between property names
+ (instead of ".").
+
+6.3. root
+
+ This attribute indicates that the value of the instance property
+ value SHOULD be treated as the root or the body of the representation
+ for the purposes of user agent interaction and fragment resolution
+ (all other properties of the instance objects are can be regarded as
+ meta-data descriptions for the data).
+
+6.4. readonly
+
+ This indicates that the instance property should not be changed.
+ Attempts by a user agent to modify the value of this property are
+ expected to be rejected by a server.
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 19]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+6.5. pathStart
+
+ This property value is a URI-Reference that indicates the URI that
+ all the URIs for the instances of the schema should start with. When
+ multiple schemas have been referenced for an instance, the user agent
+ can determine if this schema is applicable for a particular instance
+ by determining if URI of the instance begins with the pathStart's
+ referenced URI. pathStart MUST be resolved as per [RFC3986] section
+ 5. If the URI of the instance does not start with URI indicated by
+ pathStart, or if another schema specifies a starting URI that is
+ longer and also matches the instance, this schema should not be
+ applied to the instance. Any schema that does not have a pathStart
+ attribute should be considered applicable to all the instances for
+ which it is referenced.
+
+6.6. mediaType
+
+ This indicates the media type of the instance representations that
+ this schema is defining.
+
+6.7. alternate
+
+ This is an array of JSON schema definitions that define any other
+ schemas for alternate JSON-based representations of the instance
+ resources.
+
+7. Security Considerations
+
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627.
+ However, an additional issue is that when link relation of "self" is
+ used to denote a full representation of an object, the user agent
+ SHOULD NOT consider the representation to be the authoritative
+ representation of the resource denoted by the target URI if the
+ target URI is not equivalent to or a sub-path of the the URI used to
+ request the resource representation which contains the target URI
+ with the "self" link. For example, if a hyper schema was defined:
+
+
+ {
+ "links":[
+ {
+ "rel":"self",
+ "href":"{id}"
+ }
+ ]
+ }
+
+
+
+
+Zyp Expires September 24, 2010 [Page 20]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ And a resource was requested from somesite.com:
+
+
+ GET /foo/
+
+ With a response of:
+
+
+Content-Type: application/json; profile=/schema-for-this-data
+[
+ {"id":"bar", "name":"This representation can be safely treated \
+ as authoritative "},
+ {"id":"/baz", "name":"This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from "/baz" to ensure it has the authoritative representation"},
+ {"id":"http://othersite.com/something", "name":"This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"}
+]
+
+8. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is application/
+ schema+json
+
+ Type name: application
+
+ Subtype name: schema+json
+
+ Required parameters: profile
+
+ The value of the profile parameter should be a URI (relative or
+ absolute) that refers to the schema used to define the structure of
+ this structure (the meta-schema). Normally the value would be
+ http://json-schema.org/hyper-schema, but it is allowable to use other
+ schemas that extend the hyper schema's meta- schema.
+
+ Optional parameters: pretty
+
+ The value of the pretty parameter may be true or false to indicate if
+ additional whitespace has been included to make the JSON
+ representation easier to read.
+
+8.1. Registry of Link Relations
+
+ This registry is maintained by IANA per RFC 4287 and this
+ specification adds three values: "full", "create", "instances". New
+
+
+
+Zyp Expires September 24, 2010 [Page 21]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+9. References
+
+9.1. Normative References
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in
+ RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC4287] Nottingham, M., Ed. and R. Sayre,
+ Ed., "The Atom Syndication
+ Format", RFC 4287, December 2005.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman,
+ "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC2045] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format
+ of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+9.2. Informative References
+
+ [RFC4627] Crockford, D., "The application/
+ json Media Type for JavaScript
+ Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul,
+ J., Frystyk, H., Masinter, L.,
+ Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC5226] Narten, T. and H. Alvestrand,
+ "Guidelines for Writing an IANA
+ Considerations Section in RFCs",
+
+
+
+Zyp Expires September 24, 2010 [Page 22]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ BCP 26, RFC 5226, May 2008.
+
+ [I-D.hammer-discovery] Hammer-Lahav, E., "LRDD: Link-
+ based Resource Descriptor
+ Discovery",
+ draft-hammer-discovery-04 (work in
+ progress), March 2010.
+
+ [I-D.gregorio-uritemplate] Gregorio, J., Fielding, R.,
+ Hadley, M., and M. Nottingham,
+ "URI Template",
+ draft-gregorio-uritemplate-04
+ (work in progress), March 2010.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-08
+ (work in progress), March 2010.
+
+ [W3C.REC-html401-19991224] Hors, A., Jacobs, I., and D.
+ Raggett, "HTML 4.01
+ Specification", World Wide Web
+ Consortium Recommendation REC-
+ html401-19991224, December 1999, <
+ http://www.w3.org/TR/1999/
+ REC-html401-19991224>.
+
+Appendix A. Change Log
+
+ -02
+
+ o Replaced maxDecimal attribute with divisibleBy attribute
+
+ o Added slash-delimited fragment resolution protocol and made it the
+ default.
+
+ o Added language about using links outside of schemas by referencing
+ it's normative URI.
+
+ o Added uniqueItems attribute
+
+ o Added targetSchema attribute to link description object
+
+ -01
+
+ o Fixed category and updates from template
+
+ -00
+
+
+
+
+Zyp Expires September 24, 2010 [Page 23]
+
+Internet-Draft JSON Schema Media Type March 2010
+
+
+ o Initial draft
+
+Appendix B. Open Issues
+
+ Should we give a preference to MIME headers over Link headers (or
+ only use one)?
+
+ Should we use "profile" as the media type parameter instead?
+
+ Should "root" be a MIME parameter instead of a schema attribute?
+
+ Should "format" be renamed to "mediaType" or "contentType" to reflect
+ the usage MIME media types that are allowed.
+
+ I still do not like how dates are handled.
+
+ Should "slash-delimited" or "dot-delimited" be the default fragment
+ resolution protocol?
+
+Author's Address
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp Expires September 24, 2010 [Page 24]
+
+
diff --git a/draft-zyp-json-schema-02.xml b/draft-zyp-json-schema-02.xml
new file mode 100644
index 00000000..0e36d7b4
--- /dev/null
+++ b/draft-zyp-json-schema-02.xml
@@ -0,0 +1,931 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+]>
+
+
+
+
+
+
+
+
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON Documents
+
+
+
+ SitePen (USA)
+
+
+
+ 530 Lytton Avenue
+
+ Palo Alto, CA 94301
+
+ USA
+
+
+ +1 650 968 8787
+
+ kris@sitepen.com
+
+
+
+
+
+ Internet Engineering Task Force
+
+ JSON
+
+ Schema
+
+ Hyper Schema
+
+ Hypermedia
+
+
+
+
+ JSON (JavaScript Object Notation) Schema defines the media type application/schema+json,
+ a JSON based format for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+
+
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for defining
+ the structure of JSON data. JSON Schema provides a contract for what JSON
+ data is required for a given application and how to interact with it. JSON
+ Schema is intended to define validation, documentation, hyperlink
+ navigation, and interaction control of JSON data.
+
+
+
+
+ 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.
+
+
+
+
+
+ JSON Schema defines the media type application/schema+json for
+ describing the structure of other
+ JSON documents. JSON Schema is JSON-based and includes facilities
+ for describing the structure of JSON documents in terms of
+ allowable values, descriptions, and interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions. The first
+ definition is the core schema specification. This definition is primary
+ concerned with describing a JSON structure and specifying valid elements
+ in the structure. The second definition is the Hyper Schema specification
+ which is intended define elements in a structure that can be interpreted as
+ hyperlinks.
+ Hyper Schema builds on JSON Schema to describe the hyperlink structure of
+ other JSON documents. This allows user agents to be able to successfully navigate
+ JSON documents based on their schemas.
+
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to define the required type and constraints on
+ property values, as well as define the meaning of the property values
+ for the purpose of describing a resource and determining hyperlinks
+ within the representation.
+
+
+ An example JSON Schema that describes products might look like:
+
+
+
+This schema defines the properties of the instance JSON documents and
+their required properties (id, name, and price) as well as an optional
+property (tags). This also defines the link relations of the instance
+JSON documents.
+
+
+ For this specification, a schema will be used to denote a JSON Schema
+ definition, and an instance refers to the JSON object or array that the schema
+ will be describing and validating
+
+
+
+
+ The JSON Schema media type does not attempt to dictate the structure of JSON
+ representations that contain data, but rather provides a separate format
+ for flexibly communicating how a JSON representation should be
+ interpreted and validated, such that user agents can properly understand
+ acceptable structures and extrapolate hyperlink information
+ with the JSON document. It is acknowledged that JSON documents come
+ in a variety of structures, and JSON is unique in that the structure
+ of stored data structures often prescribes a non-ambiguous definite
+ JSON representation. Attempting to force a specific structure is generally
+ not viable, and therefore JSON Schema allows for great flexibility
+ in the structure of JSON data that it describes.
+
+ This specification is protocol agnostic.
+ The underlying protocol (such as HTTP) should sufficiently define the
+ semantics of the client-server interface, the retrieval of resource
+ representations linked to by JSON representations, and modification of
+ those resources. The goal of this
+ format is to sufficiently describe JSON structures such that one can
+ utilize existing information available in existing JSON
+ representations from a large variety of services that leverage a representational state transfer
+ architecture using existing protocols.
+
+
+
+
+
+
+ JSON Schema instances are correlated to their schema by the "describedby"
+ relation, where the schema is defined to be the target of the relation.
+ Instance representations may be of the application/json media type or
+ any other subtype. Consequently, dictating how an instance
+ representation should specify the relation to the schema is beyond the normative scope
+ of this document (since this document specifically defines the JSON
+ Schema media type, and no other), but it is recommended that instances
+ specify their schema so that user agents can interpret the instance
+ representation and messages may retain the self-descriptive
+ characteristic, avoiding the need for out-of-band information about
+ instance data. Two approaches are recommended for declaring the
+ relation to the schema that describes the meaning of a JSON instance's (or collection
+ of instances) structure. A MIME type parameter named
+ "profile" or a Link header with a relation of "describedby" SHOULD be used:
+
+
+
+ or if the content is being transferred by a protocol (such as HTTP) that
+ provides headers, a Link header can be used:
+
+
+ ; rel="describedby"
+]]>
+ Instances MAY specify multiple schemas, to indicate all the schemas that
+ are applicable to the data. The instance data may have multiple schemas
+ that it is defined by (the instance data should be valid for those schemas).
+ Or if the document is a collection of instances, the collection may contain
+ instances from different schemas. When collections contain heterogeneous
+ instances, the pathStart attribute MAY be specified in the
+ schema to disambiguate which schema should be applied for each item in the
+collection.
+
+
+
+ JSON Schemas are themselves instances for the schema
+ schemas. A self-describing JSON Schema for the core JSON Schema can
+ be found at http://json-schema.org/schema and the hyper schema
+ self-description can be found at: http://json-schema.org/hyper-schema. All schemas
+ used within a protocol with media type definitions
+ SHOULD include a MIME parameter that refers to the self-descriptive
+ hyper schema or another schema that extends this hyper schema:
+
+
+
+
+
+
+
+
+ A JSON Schema is a JSON Object that defines various attributes
+ of the instance and defines it's usage and valid values. A JSON
+ Schema is a JSON Object with schema attribute properties.
+ The following is the grammar of a JSON Schema:
+
+
+
+ And an example JSON Schema definition could look like:
+
+
+
+
+
+ A JSON Schema object may have any of the following properties, called schema
+ attributes (all attributes are optional):
+
+
+
+
+Union type definition - An array with two or more items which indicates a union of type definitions. Each item in the array may be a simple type definition or a schema. The instance value is valid if it is of the same type as one the type definitions in the array or if it is valid by one of the schemas in the array. For example to indicate that a string or number is a valid:
+{"type":["string","number"]}
+Simple type definition - A string indicating a primitive or simple type. The following are acceptable strings:
+
+
+
+string - Value must be a string.
+
+number - Value must be a number, floating point numbers are allowed.
+integer - Value must be an integer, no floating point numbers are allowed. This is a subset of the number type.
+boolean - Value must be a boolean.
+object - Value must be an object.
+array - Value must be an array.
+
+null - Value must be null. Note this is mainly for purpose of being able use union types to define nullability.
+any - Value may be of any type including null.
+If the property is not defined or is not in this list, than any type of value is acceptable. Other type values may be used for custom purposes, but minimal validators of the specification implementation can allow any instance value on unknown type values.
+
+
+
+
+
+
+This should be an object type definition, which is an object with property definitions that correspond to instance object properties. When the instance value is an object, the property values of the instance object must conform to the property definitions in this object. In this object, each property definition's value should be a schema, and the property's name should be the name of the instance property that it defines.
+
+
+This should be a schema or an array of schemas. When this is an object/schema and the instance value is an array, all the items in the array must conform to this schema. When this is an array of schemas and the instance value is an array, each position in the instance array must conform to the schema in the corresponding position for this array. This called tuple typing. When tuple typing is used, additional items are allowed, disallowed, or constrained by the additionalProperties attribute using the same rules as extra properties for objects. The default value is an empty schema which allows any value for items in the instance array.
+
+
+This indicates that the instance property in the instance object is optional. This is false by default.
+
+
+This provides a default property definition for all properties that are not explicitly defined in an object type definition. The value must be a schema. If false is provided, no additional properties are allowed, and the schema can not be extended. The default value is an empty schema which allows any value for additional properties.
+
+
+This indicates that if this property is present in the containing instance object, the property given by requires attribute must also be present in the containing instance object. The value
+of this property may be a string, indicating the require property name. Or the value may be a schema, in which case the containing instance must be valid by the schema if the property is present. For example if a object type definition is defined:
+
+
+
+
+An instance must include a state property if a town property is included. If a town property is not included, the state property is optional.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+This indicates the minimum value for the instance property when the type of the instance value is a number.
+
+
+If the minimum is defined, this indicates whether or not the instance property value can equal the minimum.
+
+
+If the maximum is defined, this indicates whether or not the instance property value can equal the maximum.
+
+
+This indicates the minimum number of values in an array when an array is the instance value.
+
+
+This indicates the maximum number of values in an array when an array is the instance value.
+
+
+This indicates that all the items in an array must be unique (no two identical values) within that array when an array is the instance value.
+
+
+When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid. Regular expressions should follow the regular expression specification from ECMA 262/Perl 5
+
+When the instance value is a string, this indicates maximum length of the string.
+
+
+When the instance value is a string, this indicates minimum length of the string.
+
+
+This provides an enumeration of possible values that are valid for the instance property. This should be an array, and each item in the array represents a possible value for the instance value. If "enum" is included, the instance value must be one of the values in enum array in order for the schema to be valid.
+
+
+This provides a short description of the instance property. The value must be a string.
+
+
+This provides a full description of the of purpose the instance property. The value must be a string.
+
+This property indicates the type of data, content type, or microformat to be expected in the instance property values. A format attribute may be one of the values listed below, and if so, should adhere to the semantics describing for the format. A format should only be used give meaning to primitive types (string, integer, number, or boolean). Validators are not required to validate that the instance values conform to a format. The following formats are defined:
+
+Any valid MIME media type may be used as a format value, in which case the instance property value must be a string, representing the contents of the MIME file.
+date-time - This should be a date in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time. This is the recommended form of date/timestamp.
+date - This should be a date in the format of YYYY-MM-DD. It is recommended that you use the "date-time" format instead of "date" unless you need to transfer only the date part.
+time - This should be a time in the format of hh:mm:ss. It is recommended that you use the "date-time" format instead of "time" unless you need to transfer only the time part.
+utc-millisec - This should be the difference, measured in milliseconds, between the specified time and midnight, January 1, 1970 UTC. The value should be a number (integer or float).
+regex - A regular expression.
+color - This is a CSS color (like "#FF0000" or "red").
+style - This is a CSS style definition (like "color: red; background-color:#FFF").
+phone - This should be a phone number (format may follow E.123).
+uri - This value should be a URI..
+email - This should be an email address.
+ip-address - This should be an ip version 4 address.
+ipv6 - This should be an ip version 6 address.
+street-address - This should be a street address.
+locality - This should be a city or town.
+region - This should be a region (a state in the US, province in Canada, etc.)
+postal-code - This should be a postal code (AKA zip code).
+country - This should be the name of a country.
+Additional custom formats may be defined with a URL to a definition of the format.
+
+
+
+If the instance property value is a string, this indicates that the string should be interpreted as binary data and decoded using the encoding named by this schema property. RFC 2045, Sec 6.1 lists possible values.
+
+
+
+This indicates the default for the instance property.
+
+
+This indicates that the instance property value must be divisible by the given schema value when the instance property value is a number.
+
+
+This attribute may take the same values as the "type" attribute, however if the instance matches the type or if this value is an array and the instance matches any type or schema in the array, than this instance is not valid.
+
+
+The value of this property should be another schema which will provide a base schema which the current schema will inherit from. The inheritance rules are such that any instance that is valid according to the current schema must be valid according to the referenced schema. This may also be an array, in which case, the instance must be valid for all the schemas in the array.
+
+
+
+ This section defines hypermedia definitions of JSON schema.
+ The following attributes are specified in addition to those
+attributes that already provided by JSON schema with the specific
+purpose of informing user agents of relations between resources based
+on JSON data. Just as with JSON
+schema attributes, all the attributes in hyper-schema are optional.
+Therefore an empty object is a valid (non-informative) schema, and
+essentially describes plain JSON (no constraints on the structures).
+Addition of attributes provides additive information for user agents.
+
+
+The value of the links property should be an array, where each item
+in the array is a link description object which describes the link
+relations of the instances.
+
+
+
+A link description object is used to describe the link relations. In
+the context of a schema, it defines the link relations of the
+instances of the schema, and can be parameterized by the instance
+values. The link description format can be used on its own in
+regular (non-schema documents), and use of this format can
+be declared by referencing the normative link description
+schema as the the schema for the data structure that uses the
+links. The URI of the normative link description schema is: http://json-schema.org/links.
+
+
+
+ The value of the "href" link description property
+indicates the target URI of the related resource. The value
+of the instance property should be resolved as a URI-Reference per [RFC3986]
+and may be a relative URI. The base URI to be used for relative resolution
+should be the URI used to retrieve the instance object (not the schema)
+when used in the context of a schema.
+Also, the URI may be parametrized by the property values of the instance
+object.
+
+
+Instance property values should be substituted into the URIs where
+matching braces ('{', '}') are found surrounding zero or more characters,
+creating an expanded URI. Instance property value substitutions are resolved
+by using the text between the braces to denote the property name
+from the instance to get the value to substitute. For example,
+if an href value is defined:
+
+
+
+
+Then it would be resolved by replace the value of the "id" property value from
+the instance object. If the value of the "id" property was "45", the expanded
+URI would be:
+
+
+
+
+If matching braces are found with the string "-this" (no quotes) between the braces, than the
+actual instance value should be used to replace the braces, rather than a property value.
+This should only be used in situations where the instance is a scalar (string,
+boolean, or number), and not for objects or arrays.
+
+
+
+
+The value of the "rel" property indicates the name of the
+relation to the target resource. The relation to the target should be interpreted as specifically from the instance object that the schema (or sub-schema) applies to, not just the top level resource that contains the object within its hierarchy. If a resource JSON representation contains a sub object with a property interpreted as a link, that sub-object holds the relation with the target. A relation to target from the top level resource must be indicated with the schema describing the top level JSON representation.
+
+
+Relationship definitions SHOULD NOT be media type dependent, and users are encouraged to utilize existing accepted relation definitions, including those in existing relation registries (see &rfc4287). However, we define these relation here for clarity of normative interpretation within the context of JSON hyper schema defined relations:
+
+
+self - If the relation value is "self", when this property is encountered in
+the instance object, the object represents a resource and the instance object is
+treated as a full representation of the target resource identified by
+the specified URI.
+
+
+full - This indicates that the target of the link is the full representation for the instance object. The object that contains this link may not be the full representation.
+
+
+describedby - This indicates the target of the link is the schema for the instance object. This may be used to specifically denote the schemas of objects within a JSON object hierarchy, facilitating polymorphic type data structures.
+
+
+The following relations are applicable for schemas (the schema as the "from" resource in the relation).
+
+
+instances - This indicates the target resource that represents collection of instances of a schema.
+
+
+create - This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).
+
+
+For example, if a schema is defined:
+
+
+
+
+And if a collection of instance resource's JSON representation was
+retrieved:
+
+
+
+
+
+This would indicate that for the first item in the collection, it's own
+(self) URI would resolve to "/Resource/thing" and the first item's "up"
+relation should be resolved to the resource at "/Resource/parent".
+The "children" collection would be located at "/Resource/?upId=thing".
+
+
+This property value can be a schema that defines the expected
+structure of the JSON representation of the target of the link.
+
+
+
+
+The following properties also apply to link definition objects, and
+provide functionality analogous to HTML forms, in providing a
+means for submitting extra (often user supplied) information to send to a server.
+
+
+
+
+This indicates which method should be used to access the target resource.
+In an HTTP environment, this would be "GET" or "POST" (other HTTP methods
+such as "PUT" and "DELETE" have semantics that are clearly implied by
+accessed resources, and do not need to be defined here).
+This defaults to "GET".
+
+
+
+
+
+If present, this property indicates a query media type format that the server
+supports for querying or posting to the collection of instances at the target
+resource. The query can be
+suffixed to the target URI to query the collection with
+property-based constraints on the resources that SHOULD be returned from
+the server or used to post data to the resource (depending on the method).
+For example, with the following schema:
+
+
+
+
+This indicates that the client can query the server for instances that
+have a specific name:
+
+
+
+
+
+If no enctype or method is specified, only the single URI specified by
+the href property is defined. If the method is POST, application/json is
+the default media type.
+
+
+
+
+This is inherited from the base JSON schema definition, and can follow the
+same structure, but its meaning should be used to define the acceptable
+property names and values for the action (whether it be for the GET query
+or POST body). If properties are omitted, and this form is the child of a
+schema, the properties from the parent schema should be used as the basis
+for the form action.
+
+
+
+
+
+
+ This property indicates the fragment resolution protocol to use for
+resolving fragment identifiers in URIs within the instance
+representations. This applies to the instance object URIs and all
+children of the instance object's URIs. The default fragment resolution
+protocol is "slash-delimited", which is defined below. Other fragment
+resolution protocols may be used, but are not defined in this
+document.
+
+
+
+The fragment identifier is based on RFC 2396 Sec 5, and defines the
+mechanism for resolving references to entities within a document.
+
+
+With the dot-delimited fragment resolution protocol, the fragment
+identifier is interpreted as a series of property reference tokens that
+are delimited by the "." character (\x2E). Each property reference token
+is a series of any legal URI component characters except the "." character. Each property
+reference token should be interpreted, starting from the beginning of
+the fragment identifier, as a path reference in the target JSON
+structure. The final target value of the fragment can be determined by
+starting with the root of the JSON structure from the representation of
+the resource identified by the pre-fragment URI. If the target is a JSON
+object, than the new target is the value of the property with the name
+identified by the next property reference token in the fragment. If the
+target is a JSON array, than the target is determined by finding the
+item in array the array with the index defined by the next property
+reference token (which MUST be a number). The target is successively
+updated for each property reference token, until the entire fragment has
+been traversed.
+
+
+Property names SHOULD be URI-encoded. In particular, any "." in a
+property name MUST be encoded to avoid being interpreted as a property
+delimiter.
+
+
+For example, for the following JSON representation:
+
+
+
+
+The following fragment identifiers would be resolved:
+
+
+
+
+
+
+
+The slash-delimited fragment resolution protocol is exactly the same as
+dot-delimited fragment resolution protocol except that the "/" character
+(\x2F) is used as the delimiter between property names (instead of ".").
+
+
+
+
+
+
+ This attribute indicates that the value of the instance property value
+SHOULD be treated as the root or the body of the representation for the
+purposes of user agent interaction and fragment resolution (all other
+properties of the instance objects are can be regarded as meta-data
+descriptions for the data).
+
+
+
+
+
+This indicates that the instance property should not be changed. Attempts by a user agent to modify the value of this property are expected to be rejected by a server.
+
+
+
+ This property value is a URI-Reference that indicates the URI that all
+the URIs for the instances of the schema should start with. When
+multiple schemas have been referenced for an instance, the user agent
+can determine if this schema is applicable for a particular instance by
+determining if URI of the instance begins with the pathStart's referenced
+URI. pathStart MUST be resolved as per [RFC3986] section 5. If the URI of
+the instance does not start with URI indicated by pathStart, or if another
+schema specifies a starting URI that is longer and also matches the
+instance, this schema should not be applied to the instance. Any schema
+that does not have a pathStart attribute should be considered applicable
+to all the instances for which it is referenced.
+
+
+
+
+
+
+
+ This indicates the media type of the instance representations that this schema is defining.
+
+
+
+
+
+ This is an array of JSON schema definitions that define any
+ other schemas for alternate JSON-based representations
+ of the instance resources.
+
+
+
+
+
+
+
+
+
+This specification is a sub-type of the JSON format, and
+consequently the security considerations are generally the same as RFC
+4627. However, an additional issue is that when link relation of "self"
+is used to denote a full representation of an object, the user agent
+SHOULD NOT consider the representation to be the authoritative representation
+of the resource denoted by the target URI if the target URI is not
+equivalent to or a sub-path of the the URI used to request the resource
+representation which contains the target URI with the "self" link.
+For example, if a hyper schema was defined:
+
+
+
+
+And a resource was requested from somesite.com:
+
+
+
+
+
+With a response of:
+
+
+
+
+
+
+
+
+ The proposed MIME media type for JSON Schema is application/schema+json
+
+
+ Type name: application
+
+
+ Subtype name: schema+json
+
+
+ Required parameters: profile
+
+
+ The value of the profile parameter should be a URI (relative or absolute) that
+ refers to the schema used to define the structure of this structure (the
+ meta-schema). Normally the value would be http://json-schema.org/hyper-schema,
+ but it is allowable to use other schemas that extend the hyper schema's meta-
+ schema.
+
+
+ Optional parameters: pretty
+
+
+ The value of the pretty parameter may be true or false to indicate if additional
+ whitespace has been included to make the JSON representation easier to read.
+
+
+
+
+This registry is maintained by IANA per RFC 4287 and this specification adds
+three values: "full", "create", "instances". New
+ assignments are subject to IESG Approval, as outlined in [RFC5226].
+ Requests should be made by email to IANA, which will then forward the
+ request to the IESG, requesting approval.
+
+
+
+
+
+
+
+
+
+
+
+
+ &rfc3986;
+ &rfc2119;
+ &rfc4287;
+ &rfc3339;
+ &rfc2045;
+
+
+
+ &rfc4627;
+ &rfc2616;
+ &rfc5226;
+ &iddiscovery;
+ &uritemplate;
+ &linkheader;
+ &html401;
+
+
+
+
+
+ -02
+
+
+ Replaced maxDecimal attribute with divisibleBy attribute
+ Added slash-delimited fragment resolution protocol and made it the default.
+ Added language about using links outside of schemas by referencing it's normative URI.
+ Added uniqueItems attribute
+ Added targetSchema attribute to link description object
+
+
+
+ -01
+
+
+ Fixed category and updates from template
+
+
+ -00
+
+
+ Initial draft
+
+
+
+
+
+
+ Should we give a preference to MIME headers over Link headers (or only use one)?
+ Should we use "profile" as the media type parameter instead?
+ Should "root" be a MIME parameter instead of a schema attribute?
+ Should "format" be renamed to "mediaType" or "contentType" to reflect the usage MIME media types that are allowed.
+ I still do not like how dates are handled.
+ Should "slash-delimited" or "dot-delimited" be the default fragment resolution protocol?
+
+
+
+
+
+
diff --git a/draft-zyp-json-schema-03.txt b/draft-zyp-json-schema-03.txt
new file mode 100644
index 00000000..e41724b2
--- /dev/null
+++ b/draft-zyp-json-schema-03.txt
@@ -0,0 +1,1569 @@
+
+
+
+Internet Engineering Task Force K. Zyp, Ed.
+Internet-Draft SitePen (USA)
+Intended status: Informational G. Court
+Expires: May 26, 2011 November 22, 2010
+
+
+ A JSON Media Type for Describing the Structure and Meaning of JSON
+ Documents
+ draft-zyp-json-schema-03
+
+Abstract
+
+ JSON (JavaScript Object Notation) Schema defines the media type
+ "application/schema+json", a JSON based format for defining the
+ structure of JSON data. JSON Schema provides a contract for what
+ JSON data is required for a given application and how to interact
+ with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+Status of This Memo
+
+ 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 May 26, 2011.
+
+Copyright Notice
+
+ Copyright (c) 2010 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
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 1]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Design Considerations . . . . . . . . . . . . . . . . . . 6
+ 4. Schema/Instance Association . . . . . . . . . . . . . . . . . 6
+ 4.1. Self-Descriptive Schema . . . . . . . . . . . . . . . . . 7
+ 5. Core Schema Definition . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. type . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2. properties . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.3. patternProperties . . . . . . . . . . . . . . . . . . . . 9
+ 5.4. additionalProperties . . . . . . . . . . . . . . . . . . . 9
+ 5.5. items . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.6. additionalItems . . . . . . . . . . . . . . . . . . . . . 10
+ 5.7. required . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.8. dependencies . . . . . . . . . . . . . . . . . . . . . . . 10
+ 5.9. minimum . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.10. maximum . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.11. exclusiveMinimum . . . . . . . . . . . . . . . . . . . . . 11
+ 5.12. exclusiveMaximum . . . . . . . . . . . . . . . . . . . . . 11
+ 5.13. minItems . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.14. maxItems . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.15. uniqueItems . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.16. pattern . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.17. minLength . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.18. maxLength . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.19. enum . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.20. default . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.21. title . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.22. description . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.23. format . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.24. divisibleBy . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.25. disallow . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.26. extends . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.27. id . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.28. $ref . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.29. $schema . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6. Hyper Schema . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.1. links . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.1.1. Link Description Object . . . . . . . . . . . . . . . 16
+ 6.2. fragmentResolution . . . . . . . . . . . . . . . . . . . . 20
+ 6.2.1. slash-delimited fragment resolution . . . . . . . . . 20
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 2]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ 6.2.2. dot-delimited fragment resolution . . . . . . . . . . 21
+ 6.3. readonly . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.4. contentEncoding . . . . . . . . . . . . . . . . . . . . . 22
+ 6.5. pathStart . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 6.6. mediaType . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
+ 8.1. Registry of Link Relations . . . . . . . . . . . . . . . . 24
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
+ Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
+ Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 3]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+1. Introduction
+
+ JSON (JavaScript Object Notation) Schema is a JSON media type for
+ defining the structure of JSON data. JSON Schema provides a contract
+ for what JSON data is required for a given application and how to
+ interact with it. JSON Schema is intended to define validation,
+ documentation, hyperlink navigation, and interaction control of JSON
+ data.
+
+2. Conventions
+
+ 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].
+
+3. Overview
+
+ JSON Schema defines the media type "application/schema+json" for
+ describing the structure of other JSON documents. JSON Schema is
+ JSON-based and includes facilities for describing the structure of
+ JSON documents in terms of allowable values, descriptions, and
+ interpreting relations with other resources.
+
+ JSON Schema format is organized into several separate definitions.
+ The first definition is the core schema specification. This
+ definition is primary concerned with describing a JSON structure and
+ specifying valid elements in the structure. The second definition is
+ the Hyper Schema specification which is intended define elements in a
+ structure that can be interpreted as hyperlinks. Hyper Schema builds
+ on JSON Schema to describe the hyperlink structure of other JSON
+ documents and elements of interaction. This allows user agents to be
+ able to successfully navigate JSON documents based on their schemas.
+
+ Cumulatively JSON Schema acts as a meta-document that can be used to
+ define the required type and constraints on property values, as well
+ as define the meaning of the property values for the purpose of
+ describing a resource and determining hyperlinks within the
+ representation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 4]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ An example JSON Schema that describes products might look like:
+
+ {
+ "name":"Product",
+ "properties":{
+ "id":{
+ "type":"number",
+ "description":"Product identifier",
+ "required":true
+ },
+ "name":{
+ "description":"Name of the product",
+ "type":"string",
+ "required":true
+ },
+ "price":{
+ "required":true,
+ "type": "number",
+ "minimum":0,
+ "required":true
+ },
+ "tags":{
+ "type":"array",
+ "items":{
+ "type":"string"
+ }
+ }
+ },
+ "links":[
+ {
+ "rel":"full",
+ "href":"{id}"
+ },
+ {
+ "rel":"comments",
+ "href":"comments/?id={id}"
+ }
+ ]
+ }
+
+ This schema defines the properties of the instance JSON documents,
+ the required properties (id, name, and price), as well as an optional
+ property (tags). This also defines the link relations of the
+ instance JSON documents.
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 5]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+3.1. Terminology
+
+ For this specification, *schema* will be used to denote a JSON Schema
+ definition, and an *instance* refers to a JSON value that the schema
+ will be describing and validating.
+
+3.2. Design Considerations
+
+ The JSON Schema media type does not attempt to dictate the structure
+ of JSON representations that contain data, but rather provides a
+ separate format for flexibly communicating how a JSON representation
+ should be interpreted and validated, such that user agents can
+ properly understand acceptable structures and extrapolate hyperlink
+ information with the JSON document. It is acknowledged that JSON
+ documents come in a variety of structures, and JSON is unique in that
+ the structure of stored data structures often prescribes a non-
+ ambiguous definite JSON representation. Attempting to force a
+ specific structure is generally not viable, and therefore JSON Schema
+ allows for a great flexibility in the structure of the JSON data that
+ it describes.
+
+ This specification is protocol agnostic. The underlying protocol
+ (such as HTTP) should sufficiently define the semantics of the
+ client-server interface, the retrieval of resource representations
+ linked to by JSON representations, and modification of those
+ resources. The goal of this format is to sufficiently describe JSON
+ structures such that one can utilize existing information available
+ in existing JSON representations from a large variety of services
+ that leverage a representational state transfer architecture using
+ existing protocols.
+
+4. Schema/Instance Association
+
+ JSON Schema instances are correlated to their schema by the
+ "describedby" relation, where the schema is defined to be the target
+ of the relation. Instance representations may be of the
+ "application/json" media type or any other subtype. Consequently,
+ dictating how an instance representation should specify the relation
+ to the schema is beyond the normative scope of this document (since
+ this document specifically defines the JSON Schema media type, and no
+ other), but it is recommended that instances specify their schema so
+ that user agents can interpret the instance representation and
+ messages may retain the self-descriptive characteristic, avoiding the
+ need for out-of-band information about instance data. Two approaches
+ are recommended for declaring the relation to the schema that
+ describes the meaning of a JSON instance's (or collection of
+ instances) structure. A MIME type parameter named "profile" or a
+ relation of "describedby" (which could be defined by a Link header)
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 6]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ may be used:
+
+ Content-Type: application/my-media-type+json;
+ profile=http://json.com/my-hyper-schema
+
+ or if the content is being transferred by a protocol (such as HTTP)
+ that provides headers, a Link header can be used:
+
+ Link: ; rel="describedby"
+
+ Instances MAY specify multiple schemas, to indicate all the schemas
+ that are applicable to the data, and the data SHOULD be valid by all
+ the schemas. The instance data MAY have multiple schemas that it is
+ defined by (the instance data SHOULD be valid for those schemas). Or
+ if the document is a collection of instances, the collection MAY
+ contain instances from different schemas. When collections contain
+ heterogeneous instances, the "pathStart" attribute MAY be specified
+ in the schema to disambiguate which schema should be applied for each
+ item in the collection. However, ultimately, the mechanism for
+ referencing a schema is up to the media type of the instance
+ documents (if they choose to specify that schemas can be referenced).
+
+4.1. Self-Descriptive Schema
+
+ JSON Schemas can themselves be described using JSON Schemas. A self-
+ describing JSON Schema for the core JSON Schema can be found at
+ http://json-schema.org/schema for the latest version or
+ http://json-schema.org/draft-03/schema for the draft-03 version. The
+ hyper schema self-description can be found at
+ http://json-schema.org/hyper-schema or
+ http://json-schema.org/draft-03/hyper-schema. All schemas used
+ within a protocol with media type definitions SHOULD include a MIME
+ parameter that refers to the self-descriptive hyper schema or another
+ schema that extends this hyper schema:
+
+ Content-Type: application/json;
+ profile=http://json-schema.org/draft-03/hyper-schema
+
+5. Core Schema Definition
+
+ A JSON Schema is a JSON Object that defines various attributes
+ (including usage and valid values) of a JSON value. JSON Schema has
+ recursive capabilities; there are a number of elements in the
+ structure that allow for nested JSON Schemas.
+
+ An example JSON Schema definition could look like:
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 7]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ {
+ "description":"A person",
+ "type":"object",
+
+ "properties":{
+ "name":{"type":"string"},
+ "age" :{
+ "type":"integer",
+ "maximum":125
+ }
+ }
+ }
+
+ A JSON Schema object may have any of the following properties, called
+ schema attributes (all attributes are optional):
+
+5.1. type
+
+ This attribute defines what the primitive type or the schema of the
+ instance MUST be in order to validate. This attribute can take one
+ of two forms:
+
+ Simple Types A string indicating a primitive or simple type. The
+ following are acceptable string values:
+
+ string Value MUST be a string.
+
+ number Value MUST be a number, floating point numbers are
+ allowed.
+
+ integer Value MUST be an integer, no floating point numbers are
+ allowed. This is a subset of the number type.
+
+ boolean Value MUST be a boolean.
+
+ object Value MUST be an object.
+
+ array Value MUST be an array.
+
+ null Value MUST be null. Note this is mainly for purpose of
+ being able use union types to define nullability. If this type
+ is not included in a union, null values are not allowed (the
+ primitives listed above do not allow nulls on their own).
+
+ any Value MAY be of any type including null.
+
+ If the property is not defined or is not in this list, then any
+ type of value is acceptable. Other type values MAY be used for
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 8]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ custom purposes, but minimal validators of the specification
+ implementation can allow any instance value on unknown type
+ values.
+
+ Union Types An array of two or more simple type definitions. Each
+ item in the array MUST be a simple type definition or a schema.
+ The instance value is valid if it is of the same type as one of
+ the simple type definitions, or valid by one of the schemas, in
+ the array.
+
+ For example, a schema that defines if an instance can be a string or
+ a number would be:
+
+ {"type":["string","number"]}
+
+5.2. properties
+
+ This attribute is an object with property definitions that define the
+ valid values of instance object property values. When the instance
+ value is an object, the property values of the instance object MUST
+ conform to the property definitions in this object. In this object,
+ each property definition's value MUST be a schema, and the property's
+ name MUST be the name of the instance property that it defines. The
+ instance property value MUST be valid according to the schema from
+ the property definition. Properties are considered unordered, the
+ order of the instance properties MAY be in any order.
+
+5.3. patternProperties
+
+ This attribute is an object that defines the schema for a set of
+ property names of an object instance. The name of each property of
+ this attribute's object is a regular expression pattern in the ECMA
+ 262/Perl 5 format, while the value is a schema. If the pattern
+ matches the name of a property on the instance object, the value of
+ the instance's property MUST be valid against the pattern name's
+ schema value.
+
+5.4. additionalProperties
+
+ This attribute defines a schema for all properties that are not
+ explicitly defined in an object type definition. If specified, the
+ value MUST be a schema or a boolean. If false is provided, no
+ additional properties are allowed beyond the properties defined in
+ the schema. The default value is an empty schema which allows any
+ value for additional properties.
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 9]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+5.5. items
+
+ This attribute defines the allowed items in an instance array, and
+ MUST be a schema or an array of schemas. The default value is an
+ empty schema which allows any value for items in the instance array.
+
+ When this attribute value is a schema and the instance value is an
+ array, then all the items in the array MUST be valid according to the
+ schema.
+
+ When this attribute value is an array of schemas and the instance
+ value is an array, each position in the instance array MUST conform
+ to the schema in the corresponding position for this array. This
+ called tuple typing. When tuple typing is used, additional items are
+ allowed, disallowed, or constrained by the "additionalItems"
+ (Section 5.6) attribute using the same rules as
+ "additionalProperties" (Section 5.4) for objects.
+
+5.6. additionalItems
+
+ This provides a definition for additional items in an array instance
+ when tuple definitions of the items is provided. This can be false
+ to indicate additional items in the array are not allowed, or it can
+ be a schema that defines the schema of the additional items.
+
+5.7. required
+
+ This attribute indicates if the instance must have a value, and not
+ be undefined. This is false by default, making the instance
+ optional.
+
+5.8. dependencies
+
+ This attribute is an object that defines the requirements of a
+ property on an instance object. If an object instance has a property
+ with the same name as a property in this attribute's object, then the
+ instance must be valid against the attribute's property value
+ (hereafter referred to as the "dependency value").
+
+ The dependency value can take one of two forms:
+
+ Simple Dependency If the dependency value is a string, then the
+ instance object MUST have a property with the same name as the
+ dependency value. If the dependency value is an array of strings,
+ then the instance object MUST have a property with the same name
+ as each string in the dependency value's array.
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 10]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ Schema Dependency If the dependency value is a schema, then the
+ instance object MUST be valid against the schema.
+
+5.9. minimum
+
+ This attribute defines the minimum value of the instance property
+ when the type of the instance value is a number.
+
+5.10. maximum
+
+ This attribute defines the maximum value of the instance property
+ when the type of the instance value is a number.
+
+5.11. exclusiveMinimum
+
+ This attribute indicates if the value of the instance (if the
+ instance is a number) can not equal the number defined by the
+ "minimum" attribute. This is false by default, meaning the instance
+ value can be greater then or equal to the minimum value.
+
+5.12. exclusiveMaximum
+
+ This attribute indicates if the value of the instance (if the
+ instance is a number) can not equal the number defined by the
+ "maximum" attribute. This is false by default, meaning the instance
+ value can be less then or equal to the maximum value.
+
+5.13. minItems
+
+ This attribute defines the minimum number of values in an array when
+ the array is the instance value.
+
+5.14. maxItems
+
+ This attribute defines the maximum number of values in an array when
+ the array is the instance value.
+
+5.15. uniqueItems
+
+ This attribute indicates that all items in an array instance MUST be
+ unique (contains no two identical values).
+
+ Two instance are consider equal if they are both of the same type
+ and:
+
+ are null; or
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 11]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ are booleans/numbers/strings and have the same value; or
+
+ are arrays, contains the same number of items, and each item in
+ the array is equal to the corresponding item in the other array;
+ or
+
+ are objects, contains the same property names, and each property
+ in the object is equal to the corresponding property in the other
+ object.
+
+5.16. pattern
+
+ When the instance value is a string, this provides a regular
+ expression that a string instance MUST match in order to be valid.
+ Regular expressions SHOULD follow the regular expression
+ specification from ECMA 262/Perl 5
+
+5.17. minLength
+
+ When the instance value is a string, this defines the minimum length
+ of the string.
+
+5.18. maxLength
+
+ When the instance value is a string, this defines the maximum length
+ of the string.
+
+5.19. enum
+
+ This provides an enumeration of all possible values that are valid
+ for the instance property. This MUST be an array, and each item in
+ the array represents a possible value for the instance value. If
+ this attribute is defined, the instance value MUST be one of the
+ values in the array in order for the schema to be valid. Comparison
+ of enum values uses the same algorithm as defined in "uniqueItems"
+ (Section 5.15).
+
+5.20. default
+
+ This attribute defines the default value of the instance when the
+ instance is undefined.
+
+5.21. title
+
+ This attribute is a string that provides a short description of the
+ instance property.
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 12]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+5.22. description
+
+ This attribute is a string that provides a full description of the of
+ purpose the instance property.
+
+5.23. format
+
+ This property defines the type of data, content type, or microformat
+ to be expected in the instance property values. A format attribute
+ MAY be one of the values listed below, and if so, SHOULD adhere to
+ the semantics describing for the format. A format SHOULD only be
+ used to give meaning to primitive types (string, integer, number, or
+ boolean). Validators MAY (but are not required to) validate that the
+ instance values conform to a format. The following formats are
+ predefined:
+
+ date-time This SHOULD be a date in ISO 8601 format of YYYY-MM-
+ DDThh:mm:ssZ in UTC time. This is the recommended form of date/
+ timestamp.
+
+ date This SHOULD be a date in the format of YYYY-MM-DD. It is
+ recommended that you use the "date-time" format instead of "date"
+ unless you need to transfer only the date part.
+
+ time This SHOULD be a time in the format of hh:mm:ss. It is
+ recommended that you use the "date-time" format instead of "time"
+ unless you need to transfer only the time part.
+
+ utc-millisec This SHOULD be the difference, measured in
+ milliseconds, between the specified time and midnight, 00:00 of
+ January 1, 1970 UTC. The value SHOULD be a number (integer or
+ float).
+
+ regex A regular expression, following the regular expression
+ specification from ECMA 262/Perl 5.
+
+ color This is a CSS color (like "#FF0000" or "red"), based on CSS
+ 2.1 [W3C.CR-CSS21-20070719].
+
+ style This is a CSS style definition (like "color: red; background-
+ color:#FFF"), based on CSS 2.1 [W3C.CR-CSS21-20070719].
+
+ phone This SHOULD be a phone number (format MAY follow E.123).
+
+ uri This value SHOULD be a URI..
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 13]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ email This SHOULD be an email address.
+
+ ip-address This SHOULD be an ip version 4 address.
+
+ ipv6 This SHOULD be an ip version 6 address.
+
+ host-name This SHOULD be a host-name.
+
+ Additional custom formats MAY be created. These custom formats MAY
+ be expressed as an URI, and this URI MAY reference a schema of that
+ format.
+
+5.24. divisibleBy
+
+ This attribute defines what value the number instance must be
+ divisible by with no remainder (the result of the division must be an
+ integer.) The value of this attribute SHOULD NOT be 0.
+
+5.25. disallow
+
+ This attribute takes the same values as the "type" attribute, however
+ if the instance matches the type or if this value is an array and the
+ instance matches any type or schema in the array, then this instance
+ is not valid.
+
+5.26. extends
+
+ The value of this property MUST be another schema which will provide
+ a base schema which the current schema will inherit from. The
+ inheritance rules are such that any instance that is valid according
+ to the current schema MUST be valid according to the referenced
+ schema. This MAY also be an array, in which case, the instance MUST
+ be valid for all the schemas in the array. A schema that extends
+ another schema MAY define additional attributes, constrain existing
+ attributes, or add other constraints.
+
+ Conceptually, the behavior of extends can be seen as validating an
+ instance against all constraints in the extending schema as well as
+ the extended schema(s). More optimized implementations that merge
+ schemas are possible, but are not required. An example of using
+ "extends":
+
+ {
+ "description":"An adult",
+ "properties":{"age":{"minimum": 21}},
+ "extends":"person"
+ }
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 14]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ {
+ "description":"Extended schema",
+ "properties":{"deprecated":{"type": "boolean"}},
+ "extends":"http://json-schema.org/draft-03/schema"
+ }
+
+5.27. id
+
+ This attribute defines the current URI of this schema (this attribute
+ is effectively a "self" link). This URI MAY be relative or absolute.
+ If the URI is relative it is resolved against the current URI of the
+ parent schema it is contained in. If this schema is not contained in
+ any parent schema, the current URI of the parent schema is held to be
+ the URI under which this schema was addressed. If id is missing, the
+ current URI of a schema is defined to be that of the parent schema.
+ The current URI of the schema is also used to construct relative
+ references such as for $ref.
+
+5.28. $ref
+
+ This attribute defines a URI of a schema that contains the full
+ representation of this schema. When a validator encounters this
+ attribute, it SHOULD replace the current schema with the schema
+ referenced by the value's URI (if known and available) and re-
+ validate the instance. This URI MAY be relative or absolute, and
+ relative URIs SHOULD be resolved against the URI of the current
+ schema.
+
+5.29. $schema
+
+ This attribute defines a URI of a JSON Schema that is the schema of
+ the current schema. When this attribute is defined, a validator
+ SHOULD use the schema referenced by the value's URI (if known and
+ available) when resolving Hyper Schema (Section 6) links
+ (Section 6.1).
+
+ A validator MAY use this attribute's value to determine which version
+ of JSON Schema the current schema is written in, and provide the
+ appropriate validation features and behavior. Therefore, it is
+ RECOMMENDED that all schema authors include this attribute in their
+ schemas to prevent conflicts with future JSON Schema specification
+ changes.
+
+6. Hyper Schema
+
+ The following attributes are specified in addition to those
+ attributes that already provided by the core schema with the specific
+ purpose of informing user agents of relations between resources based
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 15]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ on JSON data. Just as with JSON schema attributes, all the
+ attributes in hyper schemas are optional. Therefore, an empty object
+ is a valid (non-informative) schema, and essentially describes plain
+ JSON (no constraints on the structures). Addition of attributes
+ provides additive information for user agents.
+
+6.1. links
+
+ The value of the links property MUST be an array, where each item in
+ the array is a link description object which describes the link
+ relations of the instances.
+
+6.1.1. Link Description Object
+
+ A link description object is used to describe link relations. In the
+ context of a schema, it defines the link relations of the instances
+ of the schema, and can be parameterized by the instance values. The
+ link description format can be used on its own in regular (non-schema
+ documents), and use of this format can be declared by referencing the
+ normative link description schema as the the schema for the data
+ structure that uses the links. The URI of the normative link
+ description schema is: http://json-schema.org/links (latest version)
+ or http://json-schema.org/draft-03/links (draft-03 version).
+
+6.1.1.1. href
+
+ The value of the "href" link description property indicates the
+ target URI of the related resource. The value of the instance
+ property SHOULD be resolved as a URI-Reference per RFC 3986 [RFC3986]
+ and MAY be a relative URI. The base URI to be used for relative
+ resolution SHOULD be the URI used to retrieve the instance object
+ (not the schema) when used within a schema. Also, when links are
+ used within a schema, the URI SHOULD be parametrized by the property
+ values of the instance object, if property values exist for the
+ corresponding variables in the template (otherwise they MAY be
+ provided from alternate sources, like user input).
+
+ Instance property values SHOULD be substituted into the URIs where
+ matching braces ('{', '}') are found surrounding zero or more
+ characters, creating an expanded URI. Instance property value
+ substitutions are resolved by using the text between the braces to
+ denote the property name from the instance to get the value to
+ substitute. For example, if an href value is defined:
+
+ http://somesite.com/{id}
+
+ Then it would be resolved by replace the value of the "id" property
+ value from the instance object. If the value of the "id" property
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 16]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ was "45", the expanded URI would be:
+
+ http://somesite.com/45
+
+ If matching braces are found with the string "@" (no quotes) between
+ the braces, then the actual instance value SHOULD be used to replace
+ the braces, rather than a property value. This should only be used
+ in situations where the instance is a scalar (string, boolean, or
+ number), and not for objects or arrays.
+
+6.1.1.2. rel
+
+ The value of the "rel" property indicates the name of the relation to
+ the target resource. The relation to the target SHOULD be
+ interpreted as specifically from the instance object that the schema
+ (or sub-schema) applies to, not just the top level resource that
+ contains the object within its hierarchy. If a resource JSON
+ representation contains a sub object with a property interpreted as a
+ link, that sub-object holds the relation with the target. A relation
+ to target from the top level resource MUST be indicated with the
+ schema describing the top level JSON representation.
+
+ Relationship definitions SHOULD NOT be media type dependent, and
+ users are encouraged to utilize existing accepted relation
+ definitions, including those in existing relation registries (see RFC
+ 4287 [RFC4287]). However, we define these relations here for clarity
+ of normative interpretation within the context of JSON hyper schema
+ defined relations:
+
+ self If the relation value is "self", when this property is
+ encountered in the instance object, the object represents a
+ resource and the instance object is treated as a full
+ representation of the target resource identified by the specified
+ URI.
+
+ full This indicates that the target of the link is the full
+ representation for the instance object. The object that contains
+ this link possibly may not be the full representation.
+
+ describedby This indicates the target of the link is the schema for
+ the instance object. This MAY be used to specifically denote the
+ schemas of objects within a JSON object hierarchy, facilitating
+ polymorphic type data structures.
+
+ root This relation indicates that the target of the link SHOULD be
+ treated as the root or the body of the representation for the
+ purposes of user agent interaction or fragment resolution. All
+ other properties of the instance objects can be regarded as meta-
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 17]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ data descriptions for the data.
+
+ The following relations are applicable for schemas (the schema as the
+ "from" resource in the relation):
+
+ instances This indicates the target resource that represents
+ collection of instances of a schema.
+
+ create This indicates a target to use for creating new instances of
+ a schema. This link definition SHOULD be a submission link with a
+ non-safe method (like POST).
+
+ For example, if a schema is defined:
+
+ {
+ "links": [
+ {
+ "rel": "self"
+ "href": "{id}"
+ },
+ {
+ "rel": "up"
+ "href": "{upId}"
+ },
+ {
+ "rel": "children"
+ "href": "?upId={id}"
+ }
+ ]
+ }
+
+ And if a collection of instance resource's JSON representation was
+ retrieved:
+
+ GET /Resource/
+
+ [
+ {
+ "id": "thing",
+ "upId": "parent"
+ },
+ {
+ "id": "thing2",
+ "upId": "parent"
+ }
+ ]
+
+ This would indicate that for the first item in the collection, its
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 18]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ own (self) URI would resolve to "/Resource/thing" and the first
+ item's "up" relation SHOULD be resolved to the resource at
+ "/Resource/parent". The "children" collection would be located at
+ "/Resource/?upId=thing".
+
+6.1.1.3. targetSchema
+
+ This property value is a schema that defines the expected structure
+ of the JSON representation of the target of the link.
+
+6.1.1.4. Submission Link Properties
+
+ The following properties also apply to link definition objects, and
+ provide functionality analogous to HTML forms, in providing a means
+ for submitting extra (often user supplied) information to send to a
+ server.
+
+6.1.1.4.1. method
+
+ This attribute defines which method can be used to access the target
+ resource. In an HTTP environment, this would be "GET" or "POST"
+ (other HTTP methods such as "PUT" and "DELETE" have semantics that
+ are clearly implied by accessed resources, and do not need to be
+ defined here). This defaults to "GET".
+
+6.1.1.4.2. enctype
+
+ If present, this property indicates a query media type format that
+ the server supports for querying or posting to the collection of
+ instances at the target resource. The query can be suffixed to the
+ target URI to query the collection with property-based constraints on
+ the resources that SHOULD be returned from the server or used to post
+ data to the resource (depending on the method). For example, with
+ the following schema:
+
+ {
+ "links":[
+ {
+ "enctype":"application/x-www-form-urlencoded",
+ "method":"GET",
+ "href":"/Product/",
+ "properties":{
+ "name":{"description":"name of the product"}
+ }
+ }
+ ]
+ }
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 19]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ This indicates that the client can query the server for instances
+ that have a specific name:
+
+ /Product/?name=Slinky
+
+ If no enctype or method is specified, only the single URI specified
+ by the href property is defined. If the method is POST,
+ "application/json" is the default media type.
+
+6.1.1.4.3. schema
+
+ This attribute contains a schema which defines the acceptable
+ structure of the submitted request (for a GET request, this schema
+ would define the properties for the query string and for a POST
+ request, this would define the body).
+
+6.2. fragmentResolution
+
+ This property indicates the fragment resolution protocol to use for
+ resolving fragment identifiers in URIs within the instance
+ representations. This applies to the instance object URIs and all
+ children of the instance object's URIs. The default fragment
+ resolution protocol is "slash-delimited", which is defined below.
+ Other fragment resolution protocols MAY be used, but are not defined
+ in this document.
+
+ The fragment identifier is based on RFC 2396, Sec 5 [RFC2396], and
+ defines the mechanism for resolving references to entities within a
+ document.
+
+6.2.1. slash-delimited fragment resolution
+
+ With the slash-delimited fragment resolution protocol, the fragment
+ identifier is interpreted as a series of property reference tokens
+ that start with and are delimited by the "/" character (\x2F). Each
+ property reference token is a series of unreserved or escaped URI
+ characters. Each property reference token SHOULD be interpreted,
+ starting from the beginning of the fragment identifier, as a path
+ reference in the target JSON structure. The final target value of
+ the fragment can be determined by starting with the root of the JSON
+ structure from the representation of the resource identified by the
+ pre-fragment URI. If the target is a JSON object, then the new
+ target is the value of the property with the name identified by the
+ next property reference token in the fragment. If the target is a
+ JSON array, then the target is determined by finding the item in
+ array the array with the index defined by the next property reference
+ token (which MUST be a number). The target is successively updated
+ for each property reference token, until the entire fragment has been
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 20]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ traversed.
+
+ Property names SHOULD be URI-encoded. In particular, any "/" in a
+ property name MUST be encoded to avoid being interpreted as a
+ property delimiter.
+
+ For example, for the following JSON representation:
+
+ {
+ "foo":{
+ "anArray":[
+ {"prop":44}
+ ],
+ "another prop":{
+ "baz":"A string"
+ }
+ }
+ }
+
+ The following fragment identifiers would be resolved:
+
+ fragment identifier resolution
+ ------------------- ----------
+ # self, the root of the resource itself
+ #/foo the object referred to by the foo property
+ #/foo/another%20prop the object referred to by the "another prop"
+ property of the object referred to by the
+ "foo" property
+ #/foo/another%20prop/baz the string referred to by the value of "baz"
+ property of the "another prop" property of
+ the object referred to by the "foo" property
+ #/foo/anArray/0 the first object in the "anArray" array
+
+6.2.2. dot-delimited fragment resolution
+
+ The dot-delimited fragment resolution protocol is the same as slash-
+ delimited fragment resolution protocol except that the "." character
+ (\x2E) is used as the delimiter between property names (instead of
+ "/") and the path does not need to start with a ".". For example,
+ #.foo and #foo are a valid fragment identifiers for referencing the
+ value of the foo propery.
+
+6.3. readonly
+
+ This attribute indicates that the instance property SHOULD NOT be
+ changed. Attempts by a user agent to modify the value of this
+ property are expected to be rejected by a server.
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 21]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+6.4. contentEncoding
+
+ If the instance property value is a string, this attribute defines
+ that the string SHOULD be interpreted as binary data and decoded
+ using the encoding named by this schema property. RFC 2045, Sec 6.1
+ [RFC2045] lists the possible values for this property.
+
+6.5. pathStart
+
+ This attribute is a URI that defines what the instance's URI MUST
+ start with in order to validate. The value of the "pathStart"
+ attribute MUST be resolved as per RFC 3986, Sec 5 [RFC3986], and is
+ relative to the instance's URI.
+
+ When multiple schemas have been referenced for an instance, the user
+ agent can determine if this schema is applicable for a particular
+ instance by determining if the URI of the instance begins with the
+ the value of the "pathStart" attribute. If the URI of the instance
+ does not start with this URI, or if another schema specifies a
+ starting URI that is longer and also matches the instance, this
+ schema SHOULD NOT be applied to the instance. Any schema that does
+ not have a pathStart attribute SHOULD be considered applicable to all
+ the instances for which it is referenced.
+
+6.6. mediaType
+
+ This attribute defines the media type of the instance representations
+ that this schema is defining.
+
+7. Security Considerations
+
+ This specification is a sub-type of the JSON format, and consequently
+ the security considerations are generally the same as RFC 4627
+ [RFC4627]. However, an additional issue is that when link relation
+ of "self" is used to denote a full representation of an object, the
+ user agent SHOULD NOT consider the representation to be the
+ authoritative representation of the resource denoted by the target
+ URI if the target URI is not equivalent to or a sub-path of the the
+ URI used to request the resource representation which contains the
+ target URI with the "self" link. For example, if a hyper schema was
+ defined:
+
+
+
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 22]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ {
+ "links":[
+ {
+ "rel":"self",
+ "href":"{id}"
+ }
+ ]
+ }
+
+ And a resource was requested from somesite.com:
+
+ GET /foo/
+
+ With a response of:
+
+Content-Type: application/json; profile=/schema-for-this-data
+[
+ {"id":"bar", "name":"This representation can be safely treated \
+ as authoritative "},
+ {"id":"/baz", "name":"This representation should not be treated as \
+ authoritative the user agent should make request the resource\
+ from "/baz" to ensure it has the authoritative representation"},
+ {"id":"http://othersite.com/something", "name":"This representation\
+ should also not be treated as authoritative and the target\
+ resource representation should be retrieved for the\
+ authoritative representation"}
+]
+
+8. IANA Considerations
+
+ The proposed MIME media type for JSON Schema is "application/
+ schema+json".
+
+ Type name: application
+
+ Subtype name: schema+json
+
+ Required parameters: profile
+
+ The value of the profile parameter SHOULD be a URI (relative or
+ absolute) that refers to the schema used to define the structure of
+ this structure (the meta-schema). Normally the value would be
+ http://json-schema.org/draft-03/hyper-schema, but it is allowable to
+ use other schemas that extend the hyper schema's meta- schema.
+
+ Optional parameters: pretty
+
+ The value of the pretty parameter MAY be true or false to indicate if
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 23]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ additional whitespace has been included to make the JSON
+ representation easier to read.
+
+8.1. Registry of Link Relations
+
+ This registry is maintained by IANA per RFC 4287 [RFC4287] and this
+ specification adds four values: "full", "create", "instances",
+ "root". New assignments are subject to IESG Approval, as outlined in
+ RFC 5226 [RFC5226]. Requests should be made by email to IANA, which
+ will then forward the request to the IESG, requesting approval.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2045] Freed, N. and N. Borenstein,
+ "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format
+ of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in
+ RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC2396] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic
+ Syntax", RFC 2396, August 1998.
+
+ [RFC3339] Klyne, G., Ed. and C. Newman,
+ "Date and Time on the Internet:
+ Timestamps", RFC 3339, July 2002.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC4287] Nottingham, M., Ed. and R. Sayre,
+ Ed., "The Atom Syndication
+ Format", RFC 4287, December 2005.
+
+9.2. Informative References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul,
+ J., Frystyk, H., Masinter, L.,
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 24]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ Leach, P., and T. Berners-Lee,
+ "Hypertext Transfer Protocol --
+ HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC4627] Crockford, D., "The application/
+ json Media Type for JavaScript
+ Object Notation (JSON)", RFC 4627,
+ July 2006.
+
+ [RFC5226] Narten, T. and H. Alvestrand,
+ "Guidelines for Writing an IANA
+ Considerations Section in RFCs",
+ BCP 26, RFC 5226, May 2008.
+
+ [I-D.hammer-discovery] Hammer-Lahav, E., "LRDD: Link-
+ based Resource Descriptor
+ Discovery",
+ draft-hammer-discovery-06 (work in
+ progress), May 2010.
+
+ [I-D.gregorio-uritemplate] Gregorio, J., Fielding, R.,
+ Hadley, M., and M. Nottingham,
+ "URI Template",
+ draft-gregorio-uritemplate-04
+ (work in progress), March 2010.
+
+ [I-D.nottingham-http-link-header] Nottingham, M., "Web Linking", dra
+ ft-nottingham-http-link-header-10
+ (work in progress), May 2010.
+
+ [W3C.REC-html401-19991224] Raggett, D., Hors, A., and I.
+ Jacobs, "HTML 4.01 Specification",
+ World Wide Web Consortium Recommen
+ dation REC-html401-19991224,
+ December 1999, .
+
+ [W3C.CR-CSS21-20070719] Hickson, I., Lie, H., Celik, T.,
+ and B. Bos, "Cascading Style
+ Sheets Level 2 Revision 1 (CSS
+ 2.1) Specification", World Wide
+ Web Consortium CR CR-CSS21-
+ 20070719, July 2007, .
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 25]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+Appendix A. Change Log
+
+ draft-03
+
+ * Added example and verbiage to "extends" attribute.
+
+ * Defined slash-delimited to use a leading slash.
+
+ * Made "root" a relation instead of an attribute.
+
+ * Removed address values, and MIME media type from format to
+ reduce confusion (mediaType already exists, so it can be used
+ for MIME types).
+
+ * Added more explanation of nullability.
+
+ * Removed "alternate" attribute.
+
+ * Upper cased many normative usages of must, may, and should.
+
+ * Replaced the link submission "properties" attribute to "schema"
+ attribute.
+
+ * Replaced "optional" attribute with "required" attribute.
+
+ * Replaced "maximumCanEqual" attribute with "exclusiveMaximum"
+ attribute.
+
+ * Replaced "minimumCanEqual" attribute with "exclusiveMinimum"
+ attribute.
+
+ * Replaced "requires" attribute with "dependencies" attribute.
+
+ * Moved "contentEncoding" attribute to hyper schema.
+
+ * Added "additionalItems" attribute.
+
+ * Added "id" attribute.
+
+ * Switched self-referencing variable substitution from "-this" to
+ "@" to align with reserved characters in URI template.
+
+ * Added "patternProperties" attribute.
+
+ * Schema URIs are now namespace versioned.
+
+ * Added "$ref" and "$schema" attributes.
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 26]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ draft-02
+
+ * Replaced "maxDecimal" attribute with "divisibleBy" attribute.
+
+ * Added slash-delimited fragment resolution protocol and made it
+ the default.
+
+ * Added language about using links outside of schemas by
+ referencing its normative URI.
+
+ * Added "uniqueItems" attribute.
+
+ * Added "targetSchema" attribute to link description object.
+
+ draft-01
+
+ * Fixed category and updates from template.
+
+ draft-00
+
+ * Initial draft.
+
+Appendix B. Open Issues
+
+ Should we give a preference to MIME headers over Link headers (or
+ only use one)?
+
+ Should "root" be a MIME parameter?
+
+ Should "format" be renamed to "mediaType" or "contentType" to
+ reflect the usage MIME media types that are allowed?
+
+ How should dates be handled?
+
+Authors' Addresses
+
+ Kris Zyp (editor)
+ SitePen (USA)
+ 530 Lytton Avenue
+ Palo Alto, CA 94301
+ USA
+
+ Phone: +1 650 968 8787
+ EMail: kris@sitepen.com
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 27]
+
+Internet-Draft JSON Schema Media Type November 2010
+
+
+ Gary Court
+ Calgary, AB
+ Canada
+
+ EMail: gary.court@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zyp & Court Expires May 26, 2011 [Page 28]
+
+
diff --git a/geo b/geo
new file mode 100644
index 00000000..73a9851b
--- /dev/null
+++ b/geo
@@ -0,0 +1,7 @@
+{"description":"A geographical coordinate",
+ "type":"object",
+ "properties":{
+ "latitude":{"type":"number"},
+ "longitude":{"type":"number"}
+ }
+}
\ No newline at end of file
diff --git a/geo-v2 b/geo-v2
new file mode 100644
index 00000000..73a9851b
--- /dev/null
+++ b/geo-v2
@@ -0,0 +1,7 @@
+{"description":"A geographical coordinate",
+ "type":"object",
+ "properties":{
+ "latitude":{"type":"number"},
+ "longitude":{"type":"number"}
+ }
+}
\ No newline at end of file
diff --git a/geo.properties b/geo.properties
new file mode 100644
index 00000000..3449cd06
--- /dev/null
+++ b/geo.properties
@@ -0,0 +1,4 @@
+{
+"latitude":{"type":"number"},
+"longitude":{"type":"number"}
+}
diff --git a/hyper-schema b/hyper-schema
new file mode 100644
index 00000000..3fedec1e
--- /dev/null
+++ b/hyper-schema
@@ -0,0 +1,107 @@
+{
+ "id" : "http://json-schema.org/hyper-schema",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : "http://json-schema.org/links"
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "default" : "slash-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : "http://json-schema.org/hyper-schema-or-uri"
+ },
+
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
+ "items" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ },
+ "additionalProperties" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
+ "default" : {}
+ },
+ "additionalItems" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"],
+ "default" : {}
+ },
+ "contentEncoding" : {
+ "type" : "string"
+ },
+
+ "default" : {
+ },
+
+ "requires" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "disallow" : {
+ "type" : ["string", "array", "http://json-schema.org/hyper-schema-or-uri"],
+ "items" : {
+ "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"]
+ },
+ "uniqueItems" : true
+ },
+ "extends" : {
+ "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"],
+ "items" : "http://json-schema.org/hyper-schema-or-uri",
+ "default" : {}
+ }
+
+ },
+
+ "links" : [
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited",
+ "extends" : "http://json-schema.org/schema"
+}
\ No newline at end of file
diff --git a/hyper-schema-or-uri b/hyper-schema-or-uri
new file mode 100644
index 00000000..8d2a3c18
--- /dev/null
+++ b/hyper-schema-or-uri
@@ -0,0 +1,10 @@
+{
+ "id" : "http://json-schema.org/hyper-schema-or-uri",
+ "type" : [{
+ "type": "string",
+ "links": [{
+ "rel": "full",
+ "href": "{@}"
+ }]},
+ "http://json-schema.org/hyper-schema"]
+}
\ No newline at end of file
diff --git a/hyper-schema-v2 b/hyper-schema-v2
new file mode 100644
index 00000000..b995b83f
--- /dev/null
+++ b/hyper-schema-v2
@@ -0,0 +1,68 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema#",
+ "id" : "http://json-schema.org/hyper-schema#",
+
+ "properties" : {
+ "links" : {
+ "type" : "array",
+ "items" : {"$ref" : "http://json-schema.org/links#"},
+ "optional" : true
+ },
+
+ "fragmentResolution" : {
+ "type" : "string",
+ "optional" : true,
+ "default" : "slash-delimited"
+ },
+
+ "root" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "readonly" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pathStart" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "uri"
+ },
+
+ "mediaType" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "media-type"
+ },
+
+ "alternate" : {
+ "type" : "array",
+ "items" : {"$ref" : "#"},
+ "optional" : true
+ }
+ },
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited",
+ "extends" : {"$ref" : "http://json-schema.org/schema#"}
+}
\ No newline at end of file
diff --git a/hypertextSchema b/hypertextSchema
new file mode 100644
index 00000000..e4767e57
--- /dev/null
+++ b/hypertextSchema
@@ -0,0 +1,254 @@
+Content-Type: application/json; schema="#"
+{
+ "extends": {"href":"http://json-schema.org/schema"},
+ "description": "A schema for schemas that define how hypertext information is interpreted from instance objects",
+ "schema": {"href":"#"},
+ "hrefProperty":"href",
+ "properties":{
+ "hrefProperty":{
+ "type":"string",
+ "description":"This defines the name of the property that indicates a hyperlink. When this property is encountered in the instance object or any of it's child objects, the value of the property indicates target URI of the hyperlink and is resolved per RFC 1808. The object may include other properties providing a partial/summary representation of the target resource",
+ "optional":true,
+ "default":"href"
+ }
+ "locatorProperty":{
+ "type":"string",
+ "description":"This defines the name of the property that indicates the location of the object. When this property is encountered in the instance object or any of it's child objects, the object represents a resource, whose URI is indicated by the value of the property and is resolved per RFC 1808. The object is treated as a full representation of the target resource",
+ "optional":true,
+ "default":"id"
+ },
+ "data":{
+ "type":"array",
+ "description":"This should refer to the collection of instances of this defined schema"
+ },
+ "baseUrl":{
+ "type":"string",
+ "description":"This defines the base URL to be used for resolving hyperlinks and locator property values. When this property is not present, the URL that was used to retrieve the representation of resource is used",
+ "optional":true
+ },
+ "envelopeFor":{
+ "type":"string",
+ "description":"This presence of this property indicates that the instance object is an envelope for the real representation of the resource. This defines the name of property that refers to the actual data of the real representation. All other properties of the instance object are considered metadata"
+ "optional": true,
+ "default": "data"
+ },
+ "queryEncoding":{
+ "type":"string",
+ "description":"This property indicates the query encoding format that should be used for querying the collection of instances",
+ "options":[
+ {"name":"Form URL Encoded", "value": "application/x-www-form-urlencoded"},
+ {"name":"JSONQuery URL Encoded", "value": "application/x-jsonquery-urlencoded"}
+ ],
+ "optional": true,
+ "default": "application/x-www-form-urlencoded"
+ },
+ "versionProperty":
+ "type":"string",
+ "description":"This property indicates the version of the instance. Any modification to the instance must cause a change in the version value",
+ "optional": true
+ }
+ }
+}
+
+restSchema
+Content-Type: application/json; schema="http://json-schema.org/hyper-schema"
+{
+ "description": "A schema for providing RESTful metadata of resources",
+ "schema": {"href":"http://json-schema.org/hyper-schema"},
+ "hrefProperty": "href",
+ "envelopeFor": "members",
+ "properties":{
+ "version":{
+ "description":"identifies this version of the collection"
+ },
+ "type":{
+ "description":"the media type of the members of this collection"
+ }
+ },
+ "items":{
+ "envelopeFor": "value",
+ "properties":{
+ "precis":{
+ "description":"A summary of the item"
+ }
+ }
+ }
+}
+
+
+
+Kris Zyp wrote:
+> Another thought, one could also approach the data-schema relationship
+> from the other direction. That is, a user could access a schema first,
+> and then access the data (instances of that schema) as a link from the
+> schema, where the link relationship is "data" or "collection" . That is
+> a schema could have:
+>
+> {
+> "data":{"href":"/Project/"} # points to the collection of instances of this schema
+> "metadata": {
+> ...
+> },
+> "properties":{
+> ...
+> },
+>
+> }
+> This could easily be added to the schema since it is well-defined
+> structure. One could even define the forward and reverse relationship in
+> the schema:
+>
+> {
+> "data":{"href":"/Project/", "schema":{"href":"#"}},
+> ...
+>
+> The advantage of this you wouldn't need to rely MIME-type parameters. However, referencing data instances from the schema and schemas from the data don't necessarily need to be mutually exclusive, and if data relies on a schema, not having a link may be an REST anti-pattern since it would prevent intelligible bookmarkability of data resources.
+>
+> From a hypertext navigation perspective, starting with a list of schemas as an entry point to JSON-based site makes a lot of sense, it allows users to see the structure and descriptions of the available data and then drill down into the actual data instances from there.
+> Kris
+>
+> Kris Zyp wrote:
+>> I wanted to propose another possible approach for defining a JSON
+>> structure for RESTful interaction. I have previously suggested the
+>> importance of unobtrusively allowing JSON to preserve to it's natural
+>> structure within a RESTful architecture; alternate JSON media sub-types
+>> and structures should certainly be usable within a JSON-base REST
+>> architecture, as alternate media-types are a core aspect of REST. At the
+>> same time, others have expressed the desire to be able to include
+>> resource metadata within JSON data structures. Perhaps the best approach
+>> would be rather than enforcing a certain structure for resource
+>> metadata, allow JSON representations to define their own structure or
+>> schema and ascribe their own meaning for the hierarchy of their
+>> structure. A JSON Schema [1] definition of data could be used (which
+>> also provides definitions of allowable data types, very useful for
+>> modifying data) and augmented with resource metadata types that could be
+>> assigned to different properties. Additionally, this would permit
+>> servers to define their own properties to use for hyperlinks and
+>> resource identification. I believe it is one of our goals that we should
+>> make it easy as possible for existing implementations to become
+>> interoperable without forcing them to create their own backwards
+>> incompatibility issues. Essentially this approach would mean they we
+>> would be creating a meta-specification for defining how to specify
+>> RESTful JSON.
+>>
+>> There are several advantages to this approach:
+>> 1. Maintain unobtrusive natural JSON representations. Servers can
+>> describe the structure and meaning of their JSON in terms of how it maps
+>> to REST concepts (URLs, content types, etc.), rather than being forced
+>> to follow a certain structure. Virtually any JSON structure that
+>> contains RESTful information can be understood by clients with modifying
+>> the structure. Existing implementations can conform by providing a
+>> schema (and pointing to it in the MIME parameter) without any
+>> modification of their outputted data.
+>> 2. We can include metadata within JSON representations without needing
+>> separate content types
+>> 3. JSON Schemas on their own are an invaluable resource for user agents
+>> that may be modifying resources based on JSON representations. Schemas
+>> can be used to user agents to understand what are valid values for
+>> different properties and properly constrain and guide the user in
+>> updating data. A schema can be central resource for guiding the user
+>> agent in both property constraints as well understanding the REST
+>> mappings of the properties.
+>>
+>> The main disadvantage is that it increases the complexity of user
+>> agents, and what they must understand (they can't hardcode the property
+>> names for references/links for example).
+>>
+>> There are a number of ways that one could specify the applicable schema
+>> for a JSON representation, but like I had suggested with the "locator"
+>> property, I believe a MIME type parameter is most appropriate since it
+>> does not impose on the representation format. For example, an object
+>> representation could look like:
+>>
+>> GET /Project/proposal
+>>
+>> Content-Type: application/project+json; schema="/projectSchema"
+>> {
+>> // metadata:
+>> "type": "application/project+json",
+>> "href": "proposal",
+>> "id": "proposal",
+>> // data:
+>> "data": {
+>> "projectOwner": {
+>> // metadata:
+>> "href": "/Person/kris",
+>> "id":"kris",
+>> // data:
+>> "name":"Kris Zyp"
+>> }
+>> }
+>> }
+>>
+>> And we could define a schema:
+>> Content-Type: application/schema+json;
+>> schema="http://json-schema.org/schema"
+>> {
+>> "metadata": { # mappings of our properties to REST metadata
+>> "contentTypeProperty":"type",
+>> "hrefProperty":"href"
+>> },
+>> "envelopeFor": "data", # indicating that the value of the data is
+>> the real representation
+>> "properties":{
+>> "projectOwner":{ # schema for projectOwner values
+>> "properties:"{
+>> "name":{"type":"string"} # this is a JSON Schema
+>> property constraint (value must be a string)
+>> }
+>> }
+>> }
+>> }
+>>
+>> This schema provides all the information necessary for a user agent to
+>> understand the properties of the instance (/Project/proposal).
+>>
+>> An example of a collection:
+>> GET /Project/
+>> Content-Type: application/myapp+json; schema="/projectCollectionSchema"
+>> {
+>> "lastModified":"some date",
+>> "members":[
+>> {
+>> // metadata:
+>> "type": "application/project+json",
+>> "href": "proposal",
+>> "id": "proposal",
+>> ....
+>>
+>> ]
+>> }
+>>
+>> And a schema for the collection:
+>> GET /projectCollectionSchema
+>> Content-Type: application/schema+json;
+>> schema="http://json-schema.org/schema"
+>> {
+>> "metadata": { # mappings of our properties to REST metadata
+>> "lastModifiedProperty":"lastModified"
+>> },
+>> "envelopeFor": "members", # indicating that the value of the members
+>> is the "real" representation
+>> "items":{ # definition of the items in the array/collection
+>> # hyperlink to the schema for each project object
+>> # using the hyperlink property defined at
+>> http://json-schema.org/schema
+>> "$ref":"projectSchema"
+>> }
+>> }
+>>
+>> Additional definitions that could be provided in the schema (and not
+>> shown in these examples) could be differenting between a URL property
+>> that does provide a full object representation (locator) vs one that
+>> points to another location to retrieve the data (href), and perhaps
+>> includes a partial/summary representation. Also, a baseUrl could be
+>> defined for subobjects to support leveraging existing identifier
+>> properties in more complex URL schemes (like those used by Rails).
+>>
+>> Thanks,
+>> Kris
+>>
+>> [1] http://json-schema.org and http://groups.google.com/group/json-schema
+>>
+>>
+>>
diff --git a/implementations.html b/implementations.html
new file mode 100644
index 00000000..b90e9c1a
--- /dev/null
+++ b/implementations.html
@@ -0,0 +1,22 @@
+
+
+ JSON Schema Implementations
+
+
+
Card - A schema for microformat style representation of a person, company, organization, or place.
+
Calendar - A schema for microformat style representation of an event.
+
Address - A schema for microformat style representation of an address.
+
+
+
Tools
+
A list of JSON Schema implementations can be found here.
+
Discussion
+
Discussion about usage and development of JSON Schema can be found at the json-schema google group.
+
+
\ No newline at end of file
diff --git a/interfaces b/interfaces
new file mode 100644
index 00000000..c1c08fc3
--- /dev/null
+++ b/interfaces
@@ -0,0 +1,23 @@
+{
+ "extends":"http://json-schema.org/hyper-schema",
+ "description":"A schema for schema interface definitions that describe programmatic class structures using JSON schema syntax",
+ "properties":{
+ "methods":{
+ "type":"object",
+ "description":"This defines the set of methods available to the class instances",
+ "additionalProperties":{
+ "type":"object",
+ "description":"The definition of the method",
+ "properties":{
+ "parameters":{
+ "type":"array",
+ "description":"The set of parameters that should be passed to the method when it is called",
+ "items":"#",
+ "required": true
+ },
+ "returns":"#"
+ }
+ }
+ }
+ }
+}
diff --git a/interfaces-v2 b/interfaces-v2
new file mode 100644
index 00000000..7118195b
--- /dev/null
+++ b/interfaces-v2
@@ -0,0 +1,23 @@
+{
+ "extends":{"$ref":"http://json-schema.org/hyper-schema"},
+ "description":"A schema for schema interface definitions that describe programmatic class structures using JSON schema syntax",
+ "properties":{
+ "methods":{
+ "type":"object",
+ "description":"This defines the set of methods available to the class instances",
+ "optional":true,
+ "additionalProperties":{
+ "type":"object",
+ "description":"The definition of the method",
+ "properties":{
+ "parameters":{
+ "type":"array",
+ "description":"The set of parameters that should be passed to the method when it is called",
+ "items":{"$ref":"#"}
+ },
+ "returns":{"$ref":"#"}
+ }
+ }
+ }
+ }
+}
diff --git a/json-ref b/json-ref
new file mode 100644
index 00000000..323df0c6
--- /dev/null
+++ b/json-ref
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema",
+ "id" : "http://json-schema.org/json-ref",
+
+ "items" : "#",
+ "additionalProperties" : "#",
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/json-ref-v2 b/json-ref-v2
new file mode 100644
index 00000000..9b12616e
--- /dev/null
+++ b/json-ref-v2
@@ -0,0 +1,26 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema#",
+ "id" : "http://json-schema.org/json-ref#",
+
+ "items" : {"$ref" : "#"},
+ "additionalProperties" : {"$ref" : "#"},
+
+ "links" : [
+ {
+ "href" : "{$ref}",
+ "rel" : "full"
+ },
+
+ {
+ "href" : "{$schema}",
+ "rel" : "describedby"
+ },
+
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "fragmentResolution" : "dot-delimited"
+}
\ No newline at end of file
diff --git a/links b/links
new file mode 100644
index 00000000..27041005
--- /dev/null
+++ b/links
@@ -0,0 +1,34 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema",
+ "id" : "http://json-schema.org/links",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string",
+ "required": true
+ },
+
+ "rel" : {
+ "type" : "string",
+ "required": true
+ },
+
+ "targetSchema" : "http://json-schema.org/hyper-schema",
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET"
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "http://json-schema.org/hyper-schema"
+ }
+ }
+}
\ No newline at end of file
diff --git a/links-v2 b/links-v2
new file mode 100644
index 00000000..6989b6d1
--- /dev/null
+++ b/links-v2
@@ -0,0 +1,35 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema#",
+ "id" : "http://json-schema.org/links#",
+ "type" : "object",
+
+ "properties" : {
+ "href" : {
+ "type" : "string"
+ },
+
+ "rel" : {
+ "type" : "string"
+ },
+
+ "targetSchema" : {"$ref" : "http://json-schema.org/hyper-schema#"},
+
+ "method" : {
+ "type" : "string",
+ "default" : "GET",
+ "optional" : true
+ },
+
+ "enctype" : {
+ "type" : "string",
+ "requires" : "method",
+ "optional" : true
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "http://json-schema.org/hyper-schema#"},
+ "optional" : true
+ }
+ }
+}
\ No newline at end of file
diff --git a/schema b/schema
new file mode 100644
index 00000000..dd0d1cee
--- /dev/null
+++ b/schema
@@ -0,0 +1,137 @@
+{
+ "id" : "http://json-schema.org/schema#",
+ "type" : ["object","string"],
+ "format": "uri",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", "#"]
+ },
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : "#",
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : ["#", "array"],
+ "items" : "#",
+ "default" : {}
+ },
+
+ "required" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : ["#", "boolean"],
+ "default" : {}
+ },
+ "additionalItems" : {
+ "type" : ["#", "boolean"],
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", "#"]
+ },
+
+ "minimum" : {
+ "type" : "number"
+ },
+
+ "maximum" : {
+ "type" : "number"
+ },
+
+ "exclusiveMinimum" : {
+ "type" : "number"
+ },
+
+ "exclusiveMaximum" : {
+ "type" : "number"
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer"
+ },
+
+ "uniqueItems" : {
+ "type" : "boolean",
+ "default" : false
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer"
+ },
+
+ "enum" : {
+ "type" : "array",
+ "minItems" : 1,
+ "uniqueItems" : true
+ },
+
+ "title" : {
+ "type" : "string"
+ },
+
+ "description" : {
+ "type" : "string"
+ },
+
+ "format" : {
+ "type" : "string"
+ },
+
+ "maxDecimal" : {
+ "type" : "number",
+ "minimum" : 0
+ },
+
+ "disallow" : {
+ "type" : ["string", "array", "#"],
+ "items" : {
+ "type" : ["string", "#"]
+ },
+ "uniqueItems" : true
+ },
+
+ "extends" : {
+ "type" : ["#", "array"],
+ "items" : "#",
+ "default" : {}
+ }
+ },
+ "links" : [
+ {
+ "href" : "{id}",
+ "rel" : "self"
+ }
+ ],
+
+ "default" : {}
+}
\ No newline at end of file
diff --git a/schema-v2 b/schema-v2
new file mode 100644
index 00000000..f9d1a011
--- /dev/null
+++ b/schema-v2
@@ -0,0 +1,165 @@
+{
+ "$schema" : "http://json-schema.org/hyper-schema#",
+ "id" : "http://json-schema.org/schema#",
+ "type" : "object",
+
+ "properties" : {
+ "type" : {
+ "type" : ["string", "array"],
+ "items" : {
+ "type" : ["string", {"$ref" : "#"}]
+ },
+ "optional" : true,
+ "uniqueItems" : true,
+ "default" : "any"
+ },
+
+ "properties" : {
+ "type" : "object",
+ "additionalProperties" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "items" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ },
+
+ "optional" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "additionalProperties" : {
+ "type" : [{"$ref" : "#"}, "boolean"],
+ "optional" : true,
+ "default" : {}
+ },
+
+ "requires" : {
+ "type" : ["string", {"$ref" : "#"}],
+ "optional" : true
+ },
+
+ "minimum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "maximum" : {
+ "type" : "number",
+ "optional" : true
+ },
+
+ "minimumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "minimum",
+ "default" : true
+ },
+
+ "maximumCanEqual" : {
+ "type" : "boolean",
+ "optional" : true,
+ "requires" : "maximum",
+ "default" : true
+ },
+
+ "minItems" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxItems" : {
+ "type" : "integer",
+ "optional" : true
+ },
+
+ "uniqueItems" : {
+ "type" : "boolean",
+ "optional" : true,
+ "default" : false
+ },
+
+ "pattern" : {
+ "type" : "string",
+ "optional" : true,
+ "format" : "regex"
+ },
+
+ "minLength" : {
+ "type" : "integer",
+ "optional" : true,
+ "minimum" : 0,
+ "default" : 0
+ },
+
+ "maxLength" : {
+ "type" : "integer",
+ "optional" : true
+ },
+
+ "enum" : {
+ "type" : "array",
+ "optional" : true,
+ "minItems" : 1,
+ "uniqueItems" : true
+ },
+
+ "title" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "description" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "format" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "contentEncoding" : {
+ "type" : "string",
+ "optional" : true
+ },
+
+ "default" : {
+ "type" : "any",
+ "optional" : true
+ },
+
+ "divisibleBy" : {
+ "type" : "number",
+ "minimum" : 0,
+ "minimumCanEqual" : false,
+ "optional" : true,
+ "default" : 1
+ },
+
+ "disallow" : {
+ "type" : ["string", "array"],
+ "items" : {"type" : "string"},
+ "optional" : true,
+ "uniqueItems" : true
+ },
+
+ "extends" : {
+ "type" : [{"$ref" : "#"}, "array"],
+ "items" : {"$ref" : "#"},
+ "optional" : true,
+ "default" : {}
+ }
+ },
+
+ "optional" : true,
+ "default" : {}
+}
\ No newline at end of file
diff --git a/schema.properties b/schema.properties
new file mode 100644
index 00000000..3f4041ab
--- /dev/null
+++ b/schema.properties
@@ -0,0 +1,136 @@
+{
+ "type":{
+ "type":["string","array"],
+ "items":{"$ref":"$.properties.type"},
+ "description":"This is a type definition value. This can be a simple type, or a union type",
+ "options":[{"value":"string"},{"value":"object"},{"value":"array"},{"value":"boolean"},{"value":"number"},{"value":"integer"},{"value":"null"},{"value":"any"}],
+ "unconstrained":true,
+ "optional":true,
+ "default":"any"},
+ "optional":{
+ "type":"boolean",
+ "description":"This indicates that the instance property in the instance object is not required.",
+ "optional":true,
+ "default":false},
+ "properties":{
+ "type":"object",
+ "additionalProperties":{"$ref":"$"},
+ "description":"This is a definition for the properties of an object value",
+ "optional":true,
+ "default":{}
+ },
+ "items":{
+ "type":"object",
+ "properties":{"$ref":"$.properties"},
+ "description":"When the value is an array, this indicates the schema to use to validate each item in an array",
+ "optional":true,
+ "default":{}},
+ "additionalProperties":{
+ "type":["boolean","object"],
+ "properties":{"$ref":"$.properties"},
+ "description":"This provides a default property definition for all properties that are not explicitly defined in an object type definition.",
+ "optional":true,
+ "default":{}},
+ "specificity":{
+ "type":"number",
+ "description":"This indicates an order of specificity of properties. If an instance defines another property with a higher specificity than this one, than this instance property is required.",
+ "optional":true,
+ "default":false},
+ "identity":{
+ "type":"boolean",
+ "description":"This indicates that the instance property is an identity property and can be used to uniquely identify this instance.",
+ "optional":true,
+ "default":false},
+ "minimum":{
+ "type":"number",
+ "optional":true,
+ "description":"This indicates the minimum value for the instance property when the type of the instance value is a number, or it indicates the minimum number of values in an array when an array is the instance value."},
+ "maximum":{
+ "type":"number",
+ "optional":true,
+ "description":"This indicates the maximum value for the instance property when the type of the instance value is a number, or it indicates the maximum number of values in an array when an array is the instance value."},
+ "pattern":{
+ "type":"string",
+ "format":"regex",
+ "description":"When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid.",
+ "optional":true,
+ "default":".*"},
+ "maxLength" :{
+ "type":"number",
+ "optional":true,
+ "description":"When the instance value is a string, this indicates maximum length of the string."},
+ "minLength" :{
+ "type":"number",
+ "optional":true,
+ "description":"When the instance value is a string, this indicates minimum length of the string."},
+ "maxItems" :{
+ "type":"number",
+ "optional":true,
+ "description":"When the instance value is an array, this indicates maximum number of items."},
+ "minItems" :{
+ "type":"number",
+ "optional":true,
+ "description":"When the instance value is an array, this indicates minimum number of items."},
+ "enum" : {
+ "type":"array",
+ "optional":true,
+ "description":"This provides an enumeration of possible values that are valid for the instance property."},
+ "options" : {
+ "type":"array",
+ "items":{
+ "properties":{
+ "label":{
+ "type":"string",
+ "description":"This is the label for this option",
+ "optional":true
+ },
+ "value":{
+ "description":"This is the value for this option"
+ }
+ },
+ "description":"This is an option for list of possible values"
+ },
+ "optional":true,
+ "description":"This provides a list of suggested options for the instance property."},
+ "readonly":{
+ "type":"boolean",
+ "description":"This indicates that the instance property should not be changed (this is only for interaction, it has no effect for standalone validation).",
+ "optional":true,
+ "default":false},
+ "description":{
+ "type":"string",
+ "optional":true,
+ "description":"This provides a description of the purpose the instance property. The value can be a string or it can be an object with properties corresponding to various different instance languages (with an optional default property indicating the default description)."},
+ "format":{
+ "type":"string",
+ "optional":true,
+ "description":"This indicates what format the data is among some predefined formats which may include:\n\ndate - a string following the ISO format \naddress \nschema - a schema definition object \nperson \npage \nhtml - a string representing HTML"},
+ "default":{
+ "type":"any",
+ "optional":true,
+ "description":"This indicates the default for the instance property."},
+ "transient":{
+ "type":"boolean",
+ "optional":true,
+ "description":"This indicates that the property will be used for transient/volatile values that should not be persisted.",
+ "default":false},
+ "maxDecimal":{
+ "type":"integer",
+ "optional":true,
+ "description":"This indicates the maximum number of decimal places in a floating point number."},
+ "hidden":{
+ "type":"boolean",
+ "optional":true,
+ "description":"This indicates whether the property should be hidden in user interfaces."},
+ "extends":{
+ "type":"object",
+ "properties":{"$ref":"$.properties"},
+ "description":"This indicates the schema extends the given schema. All instances of this schema must be valid to by the extended schema also.",
+ "optional":true,
+ "default":{}},
+ "id":{
+ "type":["string","number"],
+ "optional":true,
+ "format":"url",
+ "identity":true}
+}
\ No newline at end of file
diff --git a/schema.type b/schema.type
new file mode 100644
index 00000000..67b6afd0
--- /dev/null
+++ b/schema.type
@@ -0,0 +1,73 @@
+{
+ "type":{
+ "type":["string",{},[]],
+ "additionalProperties":{"$ref":"$"},
+ "description":"This is a type definition value. This can be an object type definition, an array type definition, simple type, or a union type",
+ "options":[{"value":"string"},{"value":"object"},{"value":"array"},{"value":"boolean"},{"value":"number"},{"value":"integer"},{"value":"null"},{"value":"any"}],
+ "unconstrained":true,
+ "default":"any"},
+ "optional":{
+ "type":"boolean",
+ "description":"This indicates that the instance property in the instance object is not required.",
+ "default":false},
+ "additionalProperties":{
+ "type":{"$ref":"$"},
+ "description":"This provides a default property definition for all properties that are not explicitly defined in an object type definition.",
+ "default":{}},
+ "final":{
+ "type":"boolean",
+ "description":"This indicates that the instance objects should not have any additional properties beyond what is defined in the object type definition, and the schema definition should not be extended.",
+ "default":false},
+ "specificity":{
+ "type":"number",
+ "description":"This indicates an order of specificity of properties. If an instance defines another property with a higher specificity than this one, than this instance property is required.",
+ "default":false},
+ "unique":{
+ "type":"boolean",
+ "description":"This indicates that the instance property should have unique values. No other property with the same name in the instance object tree should have the same value.",
+ "default":false},
+ "minimum":{
+ "type":"number",
+ "description":"This indicates the minimum value for the instance property when the type of the instance value is a number, or it indicates the minimum number of values in an array when an array is the instance value."},
+ "maximum":{
+ "type":"number",
+ "description":"This indicates the maximum value for the instance property when the type of the instance value is a number, or it indicates the maximum number of values in an array when an array is the instance value."},
+ "pattern":{
+ "type":"string",
+ "format":"regex",
+ "description":"When the instance value is a string, this provides a regular expression that a instance string value should match in order to be valid.",
+ "default":".*"},
+ "maxLength" :{
+ "type":"number",
+ "description":"When the instance value is a string, this indicates maximum length of the string."},
+ "minLength" :{
+ "type":"number",
+ "description":"When the instance value is a string, this indicates minimum length of the string."},
+ "options" : {
+ "type":[],
+ "description":"This provides an enumeration of possible values that are valid for the instance property."},
+ "unconstrained":{
+ "type":"boolean",
+ "description":"When used in conjunction with the options property, this indicates a value can be used that is not in the list of options. This has no meaning when the options property is not a sibling.",
+ "default":false},
+ "readonly":{
+ "type":"boolean",
+ "description":"This indicates that the instance property should not be changed (this is only for interaction, it has no effect for standalone validation).",
+ "default":false},
+ "description":{
+ "type":"string",
+ "description":"This provides a description of the purpose the instance property. The value can be a string or it can be an object with properties corresponding to various different instance languages (with an optional default property indicating the default description)."},
+ "format":{
+ "type":"string",
+ "description":"This indicates what format the data is among some predefined formats which may include:\n\ndate - a string following the ISO format \naddress \nschema - a schema definition object \nperson \npage \nhtml - a string representing HTML"},
+ "default":{
+ "type":"any",
+ "description":"This indicates the default for the instance property."},
+ "transient":{
+ "type":"boolean",
+ "description":"This indicates that the property will be used for transient/volatile values that should not be persisted.",
+ "default":false},
+ "maxDecimal":{
+ "type":"integer",
+ "description":"This indicates the maximum number of decimal places in a floating point number."}
+}
\ No newline at end of file
diff --git a/shared.html b/shared.html
new file mode 100644
index 00000000..cc51cb05
--- /dev/null
+++ b/shared.html
@@ -0,0 +1,58 @@
+
+
+Common JSON Schema Definitions
+
+
+
+
The following are a list of some of the future common JSON Schema definitions. Included is the URL to reference and download the schema and object type definition. These shared definitions can be referenced in JSON Schemas and SMDs using JSON referencing (here is a suggested method).