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 numbers 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) 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 Force JSON - Schema - + JavaScript + Object + Notation Hyper 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 numbers 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 Added "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 numbers 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. 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 Schema links. + + +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 numbers 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. 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 numbers 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 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 numbers 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. 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 Schema links. - - -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 Schema links. + + +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 Schema links. - - -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; 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 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. 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; 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 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. 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 Force JSON @@ -57,48 +57,48 @@ 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 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: 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 + 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 @@ -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; 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. + 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, + 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. + 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 Force JSON @@ -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#bar http://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; or both 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; or both 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; 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 numbers, and have the same JSON representation; or both 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; 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 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: 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; or 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 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); 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 both 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; 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; 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; 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 both 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 Force JSON @@ -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; 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 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); 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 both 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 Force JSON @@ -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; 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; 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; 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 - 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 + + + + + + + +
 TOC 
+
+ + + + + +
Internet Engineering Task ForceK. Zyp, Ed.
Internet-DraftSitePen (USA)
Intended status: InformationalG. Court
Expires: March 30, 2013G. 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.

+

+

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
+

+
+ +

+
 TOC 
+

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. + +

+

+
 TOC 
+

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. + +

+

+ This specification also uses the following defined terms: + +

+
+
schema
+
A JSON Schema object. +
+
instance
+
Equivalent to "JSON value" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
+
property
+
Equivalent to "member" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
+
item
+
Equivalent to "element" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
+
attribute
+
A property of a JSON Schema object. +
+

+ +

+

+
 TOC 
+

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. + +

+

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. + +

+

+
 TOC 
+

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. + +

+

+
 TOC 
+

4.  +Keywords

+ +

+ The following properties are defined for JSON Schema objects: + +

+

+
 TOC 
+

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}"
+        }
+    ]
+}
+
+
+

+
 TOC 
+

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). + +

+

+
 TOC 
+

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 (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. + + +

+
 TOC 
+

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. +

+

+
 TOC 
+

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 (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. + +

+

+ +

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 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 (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header]. +

+

+
 TOC 
+

4.1.1.3.  +template

+ +

+ This property value is a string that defines the templating language used in the "href" (href) attribute. + If no templating language is defined, then the default Link Description Object templating language (href) is used. + +

+

+
 TOC 
+

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. + +

+

+
 TOC 
+

4.1.1.5.  +mediaType

+ +

+ The value of this property is advisory only, and represents the media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616]. + +

+

+ 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 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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [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. + + +

+ 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. + +

+

+
 TOC 
+

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 (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. + +

+

+
 TOC 
+

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. + +

+

+
 TOC 
+

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". + +

+

+
 TOC 
+

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 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. + + +

+
 TOC 
+

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. + +

+

+
 TOC 
+

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

+

+
 TOC 
+

4.2.1.  +json-pointer fragment resolution

+ +

+ The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations. + +

+

+
 TOC 
+

4.3.  +media

+ +

+ The value of this attribute MUST be an object. It MAY contain any of the following properties: + +

+

+
 TOC 
+

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 (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. + +

+

+
 TOC 
+

4.3.2.  +mediaType

+ +

+ The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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. + +

+

+ +

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. +

+ + +

+
 TOC 
+

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

+

+
 TOC 
+

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 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. + However, there are additional security concerns when using the hyperlink definitions. + +

+

+
 TOC 
+

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/
+
+
+ + +

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"
+}]
+
+
+ + +

+
 TOC 
+

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). + +

+

+
 TOC 
+

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. + +

+

+
 TOC 
+

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. + +

+

+
 TOC 
+

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. +

+

+
 TOC 
+

6.1.  +Registry of Link Relations

+ +

+ This registry is maintained by IANA per RFC 4287 (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287] and this specification adds four values: "full", "create", "instances", "root". + New assignments are subject to IESG Approval, as outlined in RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226]. + Requests should be made by email to IANA, which will then forward the request to the IESG, requesting approval. + +

+

+
 TOC 
+

7.  +References

+ +

+
 TOC 
+

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 (TXT).
[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3339]Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC4287]Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
[json-pointer]Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.
+ +

+
 TOC 
+

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 (TXT, PS, PDF, HTML, XML).
[RFC4627]Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
[RFC5226]Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[RFC2046]Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT).
[I-D.hammer-discovery]Hammer-Lahav, E., “LRDD: Link-based Resource Descriptor Discovery,” draft-hammer-discovery-06 (work in progress), May 2010 (TXT).
[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 (TXT).
[I-D.nottingham-http-link-header]Nottingham, M., “Web Linking,” draft-nottingham-http-link-header-10 (work in progress), May 2010 (TXT).
[W3C.REC-html401-19991224]Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
[W3C.CR-CSS21-20070719]Hickson, I., Lie, H., Çelik, 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 (HTML).
+ +

+
 TOC 
+

Appendix A.  +Change Log

+ +

+

+
+
draft-04
+
+ +
    +
  • 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. +
  • +
+ +
+
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. +
  • +
+ +
+
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. +
  • +
+ +
+

+ +

+

+
 TOC 
+

Authors' Addresses

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
 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
  
 Geraint Luff
+ 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; or 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 + both are numbers, and have the same mathematical value; or both 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 ForceK. Zyp, Ed. Internet-DraftSitePen (USA) Intended status: InformationalG. Court -Expires: March 30, 2013G. Luff - September 26, 2012 +Expires: June 21, 2013G. 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.

Copyright Notice

@@ -200,42 +200,64 @@

Table of Contents

    3.1.  Design Considerations
4.  -Keywords
+Schema keywords
    4.1.  links
-        4.1.1.  -Link Description Object
-    4.2.  +    4.2.  fragmentResolution
-        4.2.1.  +        4.2.1.  json-pointer fragment resolution
-    4.3.  +    4.3.  media
-        4.3.1.  +        4.3.1.  contentEncoding
-        4.3.2.  +        4.3.2.  mediaType
-    4.4.  +    4.4.  pathStart
-5.  +5.  +Link Description Object
+    5.1.  +href
+        5.1.1.  +Missing values
+    5.2.  +rel
+    5.3.  +template
+    5.4.  +targetSchema
+    5.5.  +mediaType
+    5.6.  +invalidates
+    5.7.  +Submission Link Properties
+        5.7.1.  +method
+        5.7.2.  +encType
+        5.7.3.  +schema
+6.  Security Considerations
-    5.1.  +    6.1.  "self" links
-    5.2.  +    6.2.  "mediaType" property of Link Description Objects
-    5.3.  +    6.3.  "targetSchema" property of Link Description Objects
-    5.4.  +    6.4.  "invalidates" property of Link Description Objects
-6.  +7.  IANA Considerations
-    6.1.  +    7.1.  Registry of Link Relations
-7.  +8.  References
-    7.1.  +    8.1.  Normative References
-    7.2.  +    8.2.  Informative References
Appendix A.  Change Log
@@ -377,7 +399,7 @@

Table of Contents



 TOC 

4.  -Keywords

+Schema keywords

The following properties are defined for JSON Schema objects: @@ -412,35 +434,148 @@

Table of Contents



 TOC 
-

4.1.1.  -Link Description Object

+

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

+

+
 TOC 
+

4.2.1.  +json-pointer fragment resolution

+ +

+ The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations. + +

+

+
 TOC 
+

4.3.  +media

- 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: + +

+

+
 TOC 
+

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 (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. + +

+

+
 TOC 
+

4.3.2.  +mediaType

+ +

+ The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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. + +

+

+ +

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. +

+ + +

+
 TOC 
+

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

+

+
 TOC 
+

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 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). +



 TOC 
-

4.1.1.1.  +

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 (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. + -

+

 TOC 
-

4.1.1.1.1.  +

5.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.

-

+

 TOC 
-

4.1.1.2.  +

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 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". +

Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].

-

+

 TOC 
-

4.1.1.3.  +

5.3.  template

- This property value is a string that defines the templating language used in the "href" (href) attribute. - If no templating language is defined, then the default Link Description Object templating language (href) is used. - + This property value is a string that defines the templating language used in the "href" (href) attribute. + If no templating language is defined, then the default Link Description Object templating language (href) is used. +

-

+

 TOC 
-

4.1.1.4.  +

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. - + 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. +

-

+

 TOC 
-

4.1.1.5.  +

5.5.  mediaType

- The value of this property is advisory only, and represents the media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616]. - + The value of this property is advisory only, and represents the media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616]. +

- 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 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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [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 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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [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". - + 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. +

-

+

 TOC 
-

4.1.1.6.  +

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. - + 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. +

-

+

 TOC 
-

4.1.1.7.  +

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. - + 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. +

-

+

 TOC 
-

4.1.1.7.1.  +

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" (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". +

-

+

 TOC 
-

4.1.1.7.2.  +

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 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. - - -

-
 TOC 
-

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. - -

-

-
 TOC 
-

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. - -

-

-
 TOC 
-

4.2.1.  -json-pointer fragment resolution

- -

- The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations. - -

-

-
 TOC 
-

4.3.  -media

- -

- The value of this attribute MUST be an object. It MAY contain any of the following properties: - -

-

-
 TOC 
-

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 (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. - -

-

-
 TOC 
-

4.3.2.  -mediaType

- -

- The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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. - -

-

- -

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. -

- + 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. +

 TOC 
-

4.4.  -pathStart

+

5.7.3.  +schema

- 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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. - + 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. +



 TOC 
-

5.  +

6.  Security Considerations

@@ -876,7 +898,7 @@

Table of Contents



 TOC 
-

5.1.  +

6.1.  "self" links

@@ -931,7 +953,7 @@

Table of Contents



 TOC 
-

5.2.  +

6.2.  "mediaType" property of Link Description Objects

@@ -951,7 +973,7 @@

Table of Contents



 TOC 
-

5.3.  +

6.3.  "targetSchema" property of Link Description Objects

@@ -960,7 +982,7 @@

Table of Contents



 TOC 
-

5.4.  +

6.4.  "invalidates" property of Link Description Objects

@@ -975,7 +997,7 @@

Table of Contents



 TOC 
-

6.  +

7.  IANA Considerations

The proposed MIME media type for JSON Schema is "application/schema+json". @@ -998,7 +1020,7 @@

Table of Contents



 TOC 
-

6.1.  +

7.1.  Registry of Link Relations

@@ -1009,12 +1031,12 @@

Table of Contents



 TOC 
-

7.  +

8.  References



 TOC 
-

7.1. Normative References

+

8.1. Normative References

@@ -1032,7 +1054,7 @@

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 (TXT).
 TOC 
-

7.2. Informative References

+

8.2. Informative References

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 @@

Table of Contents

item
Equivalent to "element" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627].
-
attribute
-
A property of a JSON Schema object. -

@@ -331,9 +328,9 @@

Table of Contents

- 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.

@@ -489,7 +486,7 @@

Table of Contents

The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2046]. - This attribute defines the media type of instances which this schema defines. + This property defines the media type of instances which this schema defines.

@@ -535,14 +532,14 @@

Table of Contents

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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986], 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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + 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: - -

-
-
schema
-
A JSON Schema object. -
-
instance
-
Equivalent to "JSON value" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. -
-
property
-
Equivalent to "member" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. -
-
item
-
Equivalent to "element" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. -
-

+ 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 @@

Table of Contents

Overview
    3.1.  Design Considerations
-4.  +        3.1.1.  +Describing interaction
+        3.1.2.  +Hypermedia interpretation
+4.  Schema keywords
-    4.1.  +    4.1.  links
-    4.2.  +    4.2.  fragmentResolution
-        4.2.1.  +        4.2.1.  json-pointer fragment resolution
-    4.3.  +    4.3.  media
-        4.3.1.  +        4.3.1.  contentEncoding
-        4.3.2.  +        4.3.2.  mediaType
-    4.4.  +    4.4.  pathStart
-5.  +5.  Link Description Object
    5.1.  href
-        5.1.1.  +        5.1.1.  Missing values
-    5.2.  +    5.2.  rel
-    5.3.  +    5.3.  template
-    5.4.  +    5.4.  targetSchema
-    5.5.  +    5.5.  mediaType
-    5.6.  +    5.6.  invalidates
-    5.7.  +    5.7.  Submission Link Properties
-        5.7.1.  +        5.7.1.  method
-        5.7.2.  +        5.7.2.  encType
-        5.7.3.  +        5.7.3.  schema
-6.  +6.  Security Considerations
-    6.1.  +    6.1.  "self" links
-    6.2.  +    6.2.  "mediaType" property of Link Description Objects
-    6.3.  +    6.3.  "targetSchema" property of Link Description Objects
-    6.4.  +    6.4.  "invalidates" property of Link Description Objects
-7.  +7.  IANA Considerations
-    7.1.  +    7.1.  Registry of Link Relations
8.  References
@@ -259,7 +263,7 @@

Table of Contents

Normative References
    8.2.  Informative References
-Appendix A.  +Appendix A.  Change Log


@@ -303,18 +307,12 @@

Table of Contents

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. + 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 @@

Table of Contents

"title": "Article Title", "type": "string" }, - "author": { + "authorId": { "type": "integer" }, "imgData": { @@ -343,7 +341,7 @@

Table of Contents

} } }, - "required" : ["id", "title", "author"], + "required" : ["id", "title", "authorId"], "links": [ { "rel": "full", @@ -351,33 +349,66 @@

Table of Contents

}, { "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: +

+
+{
+    "id": 15,
+    "title": "Example data",
+    "authorId": 105,
+    "imgData": "iVBORw...kJggg=="
+}
+
+
+

The base-64 data has been abbreviated for readability.



[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 (TXT, PS, PDF, HTML, XML).
 TOC 

3.1.  Design Considerations

+

+
 TOC 
+

3.1.1.  +Describing interaction

+

- 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. + +

+

+
 TOC 
+

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. + +

+

 TOC 

4.  Schema keywords

@@ -386,7 +417,7 @@

Table of Contents

The following properties are defined for JSON Schema objects:

-

+

 TOC 

4.1.  links

@@ -413,7 +444,7 @@

Table of Contents

}
-

+

 TOC 

4.2.  fragmentResolution

@@ -434,7 +465,7 @@

Table of Contents

The only exception to this is the resolution of "root" links themselves.

-

+

 TOC 

4.2.1.  json-pointer fragment resolution

@@ -443,7 +474,7 @@

Table of Contents

The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations.

-

+

 TOC 

4.3.  media

@@ -452,7 +483,7 @@

Table of Contents

The value of this properties MUST be an object. It MAY contain any of the following properties:

-

+

 TOC 

4.3.1.  contentEncoding

@@ -463,7 +494,7 @@

Table of Contents

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.

-

+

 TOC 

4.3.2.  mediaType

@@ -510,7 +541,7 @@

Table of Contents

-

+

 TOC 

4.4.  pathStart

@@ -526,7 +557,7 @@

Table of Contents

Any schema that does not have a pathStart property SHOULD be considered applicable to all the instances for which it is referenced.

-

+

 TOC 

5.  Link Description Object

@@ -577,7 +608,7 @@

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. -

+

 TOC 

5.1.1.  Missing values

@@ -586,7 +617,7 @@

Table of Contents

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.

-

+

 TOC 

5.2.  rel

@@ -693,7 +724,7 @@

Table of Contents

Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].

-

+

 TOC 

5.3.  template

@@ -703,7 +734,7 @@

Table of Contents

If no templating language is defined, then the default Link Description Object templating language (href) is used.

-

+

 TOC 

5.4.  targetSchema

@@ -712,7 +743,7 @@

Table of Contents

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.

-

+

 TOC 

5.5.  mediaType

@@ -777,7 +808,7 @@

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.

-

+

 TOC 

5.6.  invalidates

@@ -795,7 +826,7 @@

Table of Contents

If this property is an array, then its entries MUST be strings, each of which is treated according to the above behaviour.

-

+

 TOC 

5.7.  Submission Link Properties

@@ -804,7 +835,7 @@

Table of Contents

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.

-

+

 TOC 

5.7.1.  method

@@ -815,7 +846,7 @@

Table of Contents

This defaults to "GET".

-

+

 TOC 

5.7.2.  encType

@@ -857,7 +888,7 @@

Table of Contents

If the method is POST, "application/json" is the default media type. -

+

 TOC 

5.7.3.  schema

@@ -867,7 +898,7 @@

Table of Contents

For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.

-

+

 TOC 

6.  Security Considerations

@@ -877,7 +908,7 @@

Table of Contents

However, there are additional security concerns when using the hyperlink definitions.

-

+

 TOC 

6.1.  "self" links

@@ -932,7 +963,7 @@

Table of Contents

-

+

 TOC 

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).

-

+

 TOC 

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.

-

+

 TOC 

6.4.  "invalidates" property of Link Description Objects

@@ -976,7 +1007,7 @@

Table of Contents

This is to guard against the possibility of tricking user agents into making requests on behalf of the user, to track their behaviour.

-

+

 TOC 

7.  IANA Considerations

@@ -999,7 +1030,7 @@

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.

-

+

 TOC 

7.1.  Registry of Link Relations

@@ -1057,7 +1088,7 @@

8.2. Informative References

Hickson, I., Lie, H., Çelik, 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 (HTML). -

+

 TOC 

Appendix A.  Change Log

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 @@

Table of Contents

        4.3.1.  contentEncoding
        4.3.2.  -mediaType
+type
    4.4.  pathStart
5.  @@ -227,43 +227,35 @@

Table of Contents

Missing values
    5.2.  rel
-    5.3.  -template
-    5.4.  +        5.2.1.  +Security Considerations for "self" links
+    5.3.  targetSchema
-    5.5.  +        5.3.1.  +Security Considerations for "targetSchema"
+    5.4.  mediaType
-    5.6.  -invalidates
-    5.7.  +        5.4.1.  +Security concerns for "mediaType"
+    5.5.  Submission Link Properties
-        5.7.1.  +        5.5.1.  method
-        5.7.2.  +        5.5.2.  encType
-        5.7.3.  +        5.5.3.  schema
-6.  -Security Considerations
-    6.1.  -"self" links
-    6.2.  -"mediaType" property of Link Description Objects
-    6.3.  -"targetSchema" property of Link Description Objects
-    6.4.  -"invalidates" property of Link Description Objects
-7.  +6.  IANA Considerations
-    7.1.  +    6.1.  Registry of Link Relations
-8.  +7.  References
-    8.1.  +    7.1.  Normative References
-    8.2.  +    7.2.  Informative References
-Appendix A.  +Appendix A.  Change Log


@@ -337,7 +329,7 @@

Table of Contents

"type": "string", "media": { "contentEncoding": "base64", - "mediaType": "image/png" + "type": "image/png" } } }, @@ -497,7 +489,7 @@

Table of Contents



 TOC 

4.3.2.  -mediaType

+type

The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2046]. @@ -726,17 +718,62 @@

Table of Contents



 TOC 
-

5.3.  -template

+

5.2.1.  +Security Considerations for "self" links

- 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. - -

+ 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; 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"
+}]
+
+
+ +

 TOC 
-

5.4.  +

5.3.  targetSchema

@@ -745,7 +782,67 @@

Table of Contents



 TOC 
-

5.5.  +

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: +

+
+{
+	"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). + +

+ + +

+
 TOC 
+

5.4.  mediaType

@@ -779,24 +876,28 @@

Table of Contents

}, { "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.

-

+

 TOC 
-

5.6.  -invalidates

+

5.4.1.  +Security concerns for "mediaType"

- 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". +

-

+

 TOC 
-

5.7.  +

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.

-

+

 TOC 
-

5.7.1.  +

5.5.1.  method

@@ -846,9 +949,9 @@

Table of Contents

This defaults to "GET".

-

+

 TOC 
-

5.7.2.  +

5.5.2.  encType

@@ -888,128 +991,19 @@

Table of Contents

If the method is POST, "application/json" is the default media type. -

+

 TOC 
-

5.7.3.  +

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. -

-

-
 TOC 
-

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 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. - However, there are additional security concerns when using the hyperlink definitions. -



 TOC 
-

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 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"
-}]
-
-
- - -

-
 TOC 
-

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). - -

-

-
 TOC 
-

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. - -

-

-
 TOC 
-

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. - -

-

-
 TOC 
-

7.  +

6.  IANA Considerations

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.

-

+

 TOC 
-

7.1.  +

6.1.  Registry of Link Relations

@@ -1043,12 +1037,12 @@

Table of Contents



 TOC 
-

8.  +

7.  References



 TOC 
-

8.1. Normative References

+

7.1. Normative References

@@ -1066,7 +1060,7 @@

8.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 (TXT).
 TOC 
-

8.2. Informative References

+

7.2. Informative References

@@ -1088,7 +1082,7 @@

8.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 (TXT, PS, PDF, HTML, XML).
Hickson, I., Lie, H., Çelik, 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 (HTML).
-

+

 TOC 

Appendix A.  Change Log

@@ -1110,8 +1104,6 @@

8.2. Informative References

  • Added "mediaType" property to LDOs
  • -
  • Added "invalidates" property to LDOs -
  • 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" property Added "mediaType" property to LDOs - Added "invalidates" property to LDOs Replaced "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 @@

    Table of Contents

        5.1.  href
            5.1.1.  -Missing values
    -    5.2.  +URI Templating
    +    5.2.  rel
    -        5.2.1.  +        5.2.1.  Security Considerations for "self" links
    -    5.3.  +    5.3.  targetSchema
    -        5.3.1.  +        5.3.1.  Security Considerations for "targetSchema"
    -    5.4.  +    5.4.  mediaType
    -        5.4.1.  +        5.4.1.  Security concerns for "mediaType"
    -    5.5.  +    5.5.  Submission Link Properties
    -        5.5.1.  +        5.5.1.  method
    -        5.5.2.  +        5.5.2.  encType
    -        5.5.3.  +        5.5.3.  schema
    -6.  +6.  IANA Considerations
    -    6.1.  +    6.1.  Registry of Link Relations
    7.  References
    @@ -255,7 +255,7 @@

    Table of Contents

    Normative References
        7.2.  Informative References
    -Appendix A.  +Appendix A.  Change Log


    @@ -567,49 +567,161 @@

    Table of Contents

    href

    - 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. +


    +
     TOC 
    +

    5.1.1.  +URI Templating

    +

    + The value of "href" is to be used as a URI Template, as defined in RFC 6570 (Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” March 2012.) [RFC6570]. However, some special considerations apply: -

    For example, if an href value is defined: -

    +

    +

    +
     TOC 
    +

    5.1.1.1.  +Pre-processing

    -http://somesite.com/{id} +

    + The URI Template specification (Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” March 2012.) [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: + +

    +

    +
     TOC 
    +

    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: +

    +
    +

    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 "!") +

    +

    +

    +

    +
     TOC 
    +

    5.1.1.1.2.  +Replacing $

    - -

    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"). + +

    +

    +
     TOC 
    +

    5.1.1.1.3.  +Examples

    + +

    + +

    For example, here are some possible values for "href", followed by the results after pre-processing:

     
    -http://somesite.com/45
    +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. + +

    + - 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. - +

    +
     TOC 
    +

    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). +

    +

    + +

    +

     TOC 
    -

    5.1.1.  +

    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. + +

    +

    +
     TOC 
    +

    5.1.1.3.  Missing values

    -

    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. +

    -

    +

     TOC 

    5.2.  rel

    @@ -716,7 +828,7 @@

    Table of Contents

    Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].

    -

    +

     TOC 

    5.2.1.  Security Considerations for "self" links

    @@ -771,7 +883,7 @@

    Table of Contents

    -

    +

     TOC 

    5.3.  targetSchema

    @@ -780,7 +892,7 @@

    Table of Contents

    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.

    -

    +

     TOC 

    5.3.1.  Security Considerations for "targetSchema"

    @@ -840,7 +952,7 @@

    Table of Contents

    -

    +

     TOC 

    5.4.  mediaType

    @@ -909,7 +1021,7 @@

    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.

    -

    +

     TOC 

    5.4.1.  Security concerns for "mediaType"

    @@ -929,7 +1041,7 @@

    Table of Contents

    This is to guard against re-interpretation of "safe" data, similar to the precautions for "targetSchema".

    -

    +

     TOC 

    5.5.  Submission Link Properties

    @@ -938,7 +1050,7 @@

    Table of Contents

    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.

    -

    +

     TOC 

    5.5.1.  method

    @@ -949,7 +1061,7 @@

    Table of Contents

    This defaults to "GET".

    -

    +

     TOC 

    5.5.2.  encType

    @@ -991,7 +1103,7 @@

    Table of Contents

    If the method is POST, "application/json" is the default media type. -

    +

     TOC 

    5.5.3.  schema

    @@ -1001,7 +1113,7 @@

    Table of Contents

    For a GET request, this schema would define the properties for the query string and for a POST request, this would define the body.

    -

    +

     TOC 

    6.  IANA Considerations

    @@ -1024,7 +1136,7 @@

    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.

    -

    +

     TOC 

    6.1.  Registry of Link Relations

    @@ -1054,6 +1166,8 @@

    7.1. Normative References

    Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML). [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML). +[RFC6570] +Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” RFC 6570, March 2012 (TXT). [json-pointer] Bryan, P. and K. Zyp, “JSON Pointer,” October 2011. @@ -1072,8 +1186,6 @@

    7.2. Informative References

    Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT). [I-D.hammer-discovery] Hammer-Lahav, E., “LRDD: Link-based Resource Descriptor Discovery,” draft-hammer-discovery-06 (work in progress), May 2010 (TXT). -[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 (TXT). [I-D.nottingham-http-link-header] Nottingham, M., “Web Linking,” draft-nottingham-http-link-header-10 (work in progress), May 2010 (TXT). [W3C.REC-html401-19991224] @@ -1082,7 +1194,7 @@

    7.2. Informative References

    Hickson, I., Lie, H., Çelik, 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 (HTML). -

    +

     TOC 

    Appendix A.  Change Log

    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 ForceK. Zyp, Ed. Internet-DraftSitePen (USA) Intended status: InformationalG. Court -Expires: June 21, 2013G. Luff - December 18, 2012 +Expires: June 22, 2013G. 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.

    Copyright Notice

    @@ -207,47 +207,51 @@

    Table of Contents

    Schema keywords
        4.1.  links
    -    4.2.  +        4.1.1.  +Multiple links per URI
    +    4.2.  fragmentResolution
    -        4.2.1.  +        4.2.1.  json-pointer fragment resolution
    -    4.3.  +    4.3.  media
    -        4.3.1.  -contentEncoding
    -        4.3.2.  +        4.3.1.  +binaryEncoding
    +        4.3.2.  type
    -    4.4.  +    4.4.  pathStart
    -5.  +5.  Link Description Object
        5.1.  href
    -        5.1.1.  +        5.1.1.  URI Templating
    -    5.2.  +    5.2.  rel
    -        5.2.1.  +        5.2.1.  +Fragment resolution with "root" links
    +        5.2.2.  Security Considerations for "self" links
    -    5.3.  +    5.3.  targetSchema
    -        5.3.1.  +        5.3.1.  Security Considerations for "targetSchema"
    -    5.4.  +    5.4.  mediaType
    -        5.4.1.  +        5.4.1.  Security concerns for "mediaType"
    -    5.5.  +    5.5.  Submission Link Properties
    -        5.5.1.  +        5.5.1.  method
    -        5.5.2.  +        5.5.2.  encType
    -        5.5.3.  +        5.5.3.  schema
    -6.  +6.  IANA Considerations
    -    6.1.  +    6.1.  Registry of Link Relations
    7.  References
    @@ -255,7 +259,7 @@

    Table of Contents

    Normative References
        7.2.  Informative References
    -Appendix A.  +Appendix A.  Change Log


    @@ -328,7 +332,7 @@

    Table of Contents

    "title": "Article Illustration (small)", "type": "string", "media": { - "contentEncoding": "base64", + "binaryEncoding": "base64", "type": "image/png" } } @@ -418,9 +422,8 @@

    Table of Contents

    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:

    -
     {
         "title": "Schema defining links",
         "links": [
    @@ -434,10 +437,74 @@ 

    Table of Contents

    } ] } -


     TOC 
    +

    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. + +

    + 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"]
    +        	}
    +        }
    +    ]
    +}
    +
    + +

    + 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. + +

    + + +

    +
     TOC 

    4.2.  fragmentResolution

    @@ -457,7 +524,7 @@

    Table of Contents

    The only exception to this is the resolution of "root" links themselves.

    -

    +

     TOC 

    4.2.1.  json-pointer fragment resolution

    @@ -466,7 +533,7 @@

    Table of Contents

    The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations.

    -

    +

     TOC 

    4.3.  media

    @@ -475,10 +542,10 @@

    Table of Contents

    The value of this properties MUST be an object. It MAY contain any of the following properties:

    -

    +

     TOC 

    4.3.1.  -contentEncoding

    +binaryEncoding

    The value of this property SHOULD be ignored for any instance that is not a string. @@ -486,7 +553,7 @@

    Table of Contents

    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.

    -

    +

     TOC 

    4.3.2.  type

    @@ -497,7 +564,7 @@

    Table of Contents

    - 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.

    @@ -508,8 +575,8 @@

    Table of Contents

    { "type": "string", "media": { - "contentEncoding": "base64", - "mediaType": "image/png" + "encoding": "base64", + "type": "image/png" } } @@ -533,7 +600,7 @@

    Table of Contents

    -

    +

     TOC 

    4.4.  pathStart

    @@ -549,7 +616,7 @@

    Table of Contents

    Any schema that does not have a pathStart property SHOULD be considered applicable to all the instances for which it is referenced.

    -

    +

     TOC 

    5.  Link Description Object

    @@ -568,11 +635,13 @@

    Table of Contents

    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 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 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. +

    +

     TOC 

    5.1.1.  URI Templating

    @@ -581,7 +650,7 @@

    Table of Contents

    The value of "href" is to be used as a URI Template, as defined in RFC 6570 (Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, “URI Template,” March 2012.) [RFC6570]. However, some special considerations apply:

    -

    +

     TOC 

    5.1.1.1.  Pre-processing

    @@ -591,7 +660,7 @@

    Table of Contents

    Property names in JSON, however, can be any UTF-8 string. As such, the following pre-processing rules apply:

    -

    +

     TOC 

    5.1.1.1.1.  Bracket escaping

    @@ -622,7 +691,7 @@

    Table of Contents

    -

    +

     TOC 

    5.1.1.1.2.  Replacing $

    @@ -631,7 +700,7 @@

    Table of Contents

    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").

    -

    +

     TOC 

    5.1.1.1.3.  Examples

    @@ -662,7 +731,7 @@

    Table of Contents

    -

    +

     TOC 

    5.1.1.2.  Values for substitution

    @@ -683,7 +752,7 @@

    Table of Contents

    -

    +

     TOC 

    5.1.1.2.1.  Converting to strings

    @@ -706,7 +775,7 @@

    Table of Contents

    Schema and API authors should bear this in mind, and use other types (such as string or boolean) if the exact representation is important.

    -

    +

     TOC 

    5.1.1.3.  Missing values

    @@ -721,15 +790,18 @@

    Table of Contents

    Otherwise, the link definition SHOULD be considered not to apply to the instance.

    -

    +

     TOC 

    5.2.  rel

    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.

    @@ -790,7 +864,6 @@

    Table of Contents

    For example, if a schema is defined:

    -
     {
         "links": [{
             "rel": "self",
    @@ -803,13 +876,11 @@ 

    Table of Contents

    "href": "?upId={id}" }] } -

    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". + +

    Note that these relationship values are case-insensitive, consistent with their use in HTML and the HTTP Link header (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header].

    -

    +

     TOC 

    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"
    +
    +

    + + +

    +

    +
     TOC 
    +

    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: +

    +
    +
    +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. + +

    +

    +
     TOC 
    +

    5.2.2.  Security Considerations for "self" links

    @@ -839,14 +1013,12 @@

    Table of Contents

    For example, if a hyper schema was defined:

    -
     {
     	"links": [{
     		"rel": "self",
     		"href": "{id}"
     	}]
     }
    -
     
    @@ -860,7 +1032,6 @@

    Table of Contents

    With a response of:

    -
     Content-Type: application/json; profile=/schema-for-this-data
     
     [{
    @@ -879,11 +1050,10 @@ 

    Table of Contents

    resource representation should be retrieved for the\ authoritative representation" }] -
    -

    +

     TOC 

    5.3.  targetSchema

    @@ -892,7 +1062,7 @@

    Table of Contents

    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.

    -

    +

     TOC 

    5.3.1.  Security Considerations for "targetSchema"

    @@ -952,7 +1122,7 @@

    Table of Contents

    -

    +

     TOC 

    5.4.  mediaType

    @@ -1021,7 +1191,7 @@

    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.

    -

    +

     TOC 

    5.4.1.  Security concerns for "mediaType"

    @@ -1041,7 +1211,7 @@

    Table of Contents

    This is to guard against re-interpretation of "safe" data, similar to the precautions for "targetSchema".

    -

    +

     TOC 

    5.5.  Submission Link Properties

    @@ -1050,7 +1220,7 @@

    Table of Contents

    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.

    -

    +

     TOC 

    5.5.1.  method

    @@ -1061,7 +1231,7 @@

    Table of Contents

    This defaults to "GET".

    -

    +

     TOC 

    5.5.2.  encType

    @@ -1073,7 +1243,6 @@

    Table of Contents

    For example, with the following schema:

    -
     {
         "links": [{
             "encType": "application/x-www-form-urlencoded",
    @@ -1086,7 +1255,6 @@ 

    Table of Contents

    } }] } -

    This indicates that the client can query the server for instances that have a specific name.

    @@ -1103,7 +1271,7 @@

    Table of Contents

    If the method is POST, "application/json" is the default media type. -

    +

     TOC 

    5.5.3.  schema

    @@ -1113,7 +1281,12 @@

    Table of Contents

    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. + +

    +

     TOC 

    6.  IANA Considerations

    @@ -1136,7 +1309,7 @@

    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.

    -

    +

     TOC 

    6.1.  Registry of Link Relations

    @@ -1194,7 +1367,7 @@

    7.2. Informative References

    Hickson, I., Lie, H., Çelik, 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 (HTML). -

    +

     TOC 

    Appendix A.  Change Log

    @@ -1212,7 +1385,7 @@

    7.2. Informative References

  • 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 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 LDOs Replaced "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 + + + + + + + +
     TOC 
    +
    + + + + +
    Internet Engineering Task ForceK. Zyp, Ed.
    Internet-DraftSitePen (USA)
    Intended status: InformationalDecember 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.

    +

    +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
    +2.  +Conventions
    +3.  +Overview
    +    3.1.  +Terminology
    +    3.2.  +Design Considerations
    +4.  +Schema/Instance Association
    +    4.1.  +Self-Descriptive Schema
    +5.  +Core Schema Definition
    +    5.1.  +type
    +    5.2.  +properties
    +    5.3.  +items
    +    5.4.  +optional
    +    5.5.  +additionalProperties
    +    5.6.  +requires
    +    5.7.  +minimum
    +    5.8.  +maximum
    +    5.9.  +minimumCanEqual
    +    5.10.  +maximumCanEqual
    +    5.11.  +minItems
    +    5.12.  +maxItems
    +    5.13.  +pattern
    +    5.14.  +maxLength
    +    5.15.  +minLength
    +    5.16.  +enum
    +    5.17.  +title
    +    5.18.  +description
    +    5.19.  +format
    +    5.20.  +contentEncoding
    +    5.21.  +default
    +    5.22.  +maxDecimal
    +    5.23.  +disallow
    +    5.24.  +extends
    +6.  +Hyper Schema
    +    6.1.  +links
    +        6.1.1.  +Link Description Object
    +    6.2.  +fragmentResolution
    +        6.2.1.  +dot-delimited fragment resolution
    +    6.3.  +root
    +    6.4.  +readonly
    +    6.5.  +pathStart
    +    6.6.  +mediaType
    +    6.7.  +alternate
    +7.  +Security Considerations
    +8.  +IANA Considerations
    +    8.1.  +Registry of Link Relations
    +9.  +References
    +    9.1.  +Normative References
    +    9.2.  +Informative References
    +Appendix A.  +Change Log
    +Appendix B.  +Open Issues
    +

    +
    + +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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: +

    +
    +
    +{
    +  "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. + +

    +

    +
     TOC 
    +

    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 +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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: <http://json.com/my-hyper-schema>; 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. + +

    +

    +
     TOC 
    +

    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
    +

    + + +

    +

    +
     TOC 
    +

    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): + +

    +

    +
     TOC 
    +

    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. +

    +
    + + +

    + +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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.. +

    +

    +
     TOC 
    +

    5.4.  +optional

    + +

    This indicates that the instance property in the instance object is optional. This is false by default. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    5.7.  +minimum

    + +

    This indicates the minimum value for the instance property when the type of the instance value is a number. +

    +

    +
     TOC 
    +

    5.8.  +maximum

    + +

    This indicates the minimum value for the instance property when the type of the instance value is a number. +

    +

    +
     TOC 
    +

    5.9.  +minimumCanEqual

    + +

    If the minimum is defined, this indicates whether or not the instance property value can equal the minimum. +

    +

    +
     TOC 
    +

    5.10.  +maximumCanEqual

    + +

    If the maximum is defined, this indicates whether or not the instance property value can equal the maximum. +

    +

    +
     TOC 
    +

    5.11.  +minItems

    + +

    This indicates the minimum number of values in an array when an array is the instance value. +

    +

    +
     TOC 
    +

    5.12.  +maxItems

    + +

    This indicates the maximum number of values in an array when an array is the instance value. +

    +

    +
     TOC 
    +

    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 +

    +

    +
     TOC 
    +

    5.14.  +maxLength

    + +

    When the instance value is a string, this indicates maximum length of the string. +

    +

    +
     TOC 
    +

    5.15.  +minLength

    + +

    When the instance value is a string, this indicates minimum length of the string. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    5.17.  +title

    + +

    This provides a short description of the instance property. The value must be a string. +

    +

    +
     TOC 
    +

    5.18.  +description

    + +

    This provides a full description of the of purpose the instance property. The value must be a string. +

    +

    +
     TOC 
    +

    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). + +

    +

    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. +

    +
    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    5.21.  +default

    + +

    This indicates the default for the instance property. +

    +

    +
     TOC 
    +

    5.22.  +maxDecimal

    + +

    This indicates the maximum number of decimal places in a floating point number. By default there is no maximum. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    6.1.1.  +Link Description Object

    + +

    +A link description object is used to describe the link relations +of instances of a schema. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +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. + +

    +

    +
     TOC 
    +

    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: +

    +
    +
    +{
    +    "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". + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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". + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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: +

    +
    +
    +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
    +

    + + +

    +

    +
     TOC 
    +

    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). + + +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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. + + + +

    +

    +
     TOC 
    +

    6.6.  +mediaType

    + +

    This indicates the media type of the instance representations that this schema is defining. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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"}
    +]
    +

    + + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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. + + +

    +

    +
     TOC 
    +

    9.  +References

    + +

    +
     TOC 
    +

    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 (TXT, HTML, XML).
    [RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
    [RFC4287]Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
    [RFC3339]Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
    [RFC2045]Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045, November 1996 (TXT).
    + +

    +
     TOC 
    +

    9.2. Informative References

    + + + + + + + + + + + + + + + +
    [RFC4627]Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
    [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 (TXT, PS, PDF, HTML, XML).
    [RFC5226]Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
    [I-D.hammer-discovery]Hammer-Lahav, E., “Link-based Resource Descriptor Discovery,” draft-hammer-discovery-03 (work in progress), March 2009 (TXT).
    [I-D.gregorio-uritemplate]Gregorio, J., “URI Template,” draft-gregorio-uritemplate-03 (work in progress), April 2008 (TXT).
    [I-D.nottingham-http-link-header]Nottingham, M., “Web Linking,” draft-nottingham-http-link-header-06 (work in progress), July 2009 (TXT).
    [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 (HTML).
    + +

    +
     TOC 
    +

    Appendix A.  +Change Log

    + +

    -01 +

    +

    +

    +
      +
    • Fixed category and updates from template +
    • +

    + +

    +

    -00 +

    +

    +

    +
      +
    • Initial draft +
    • +

    + +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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
    + + 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 + + +

    JSON Schema Implementations:

    + + + \ No newline at end of file diff --git a/index.html b/index.html new file mode 100644 index 00000000..7fb09732 --- /dev/null +++ b/index.html @@ -0,0 +1,27 @@ + + +JSON Schema + + +

    JSON Schema

    +

    Please see the JSON Schema Internet Draft for the latest specification. +

    +

    Schemas

    +

    The following are schemas that are available for referencing: +

      +
    • Core Meta-Schema - This is the meta-schema definition for schemas themselves (the type/validation part of schemas).
    • +
    • Hyper Meta-Schema - This is the extended full meta-schema definition for schemas with link definitions (hyper schemas).
    • +
    • JSON Referencing - This is the schema that defines a generic linking mechanism called JSON referencing (which is used by the meta-schema for links).
    • +
    • JSON Schema Interfaces - This is the meta-schema definition for schemas which define class-style method interfaces for programming languages.
    • +
    • Geographic Coordinate
    • +
    • 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).

    + + + + + + + + + + + \ No newline at end of file From c5d4fda09204f830d041c50794bed5ea7612ad78 Mon Sep 17 00:00:00 2001 From: nickl- Date: Mon, 20 Aug 2012 13:55:26 +0200 Subject: [PATCH 0138/1659] Update index html to shake gh-pages --- index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/index.html b/index.html index 7fb09732..a0d1304b 100644 --- a/index.html +++ b/index.html @@ -6,6 +6,7 @@

    JSON Schema

    Please see the JSON Schema Internet Draft for the latest specification.

    +

    It went a little side tracked but will be updated soon.

    Schemas

    The following are schemas that are available for referencing:

      @@ -24,4 +25,4 @@

      Tools

      Discussion

      Discussion about usage and development of JSON Schema can be found at the json-schema google group.

      - \ No newline at end of file + From 05ced6947837d5a08f9b805df8c69198cbf705f9 Mon Sep 17 00:00:00 2001 From: nickl- Date: Mon, 20 Aug 2012 14:00:00 +0200 Subject: [PATCH 0139/1659] Update index html to shake gh-pages again --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index a0d1304b..ec66974c 100644 --- a/index.html +++ b/index.html @@ -8,7 +8,7 @@

      JSON Schema

      It went a little side tracked but will be updated soon.

      Schemas

      -

      The following are schemas that are available for referencing: +

      The following are schemas that are available for referencing:(more to come)

      • Core Meta-Schema - This is the meta-schema definition for schemas themselves (the type/validation part of schemas).
      • Hyper Meta-Schema - This is the extended full meta-schema definition for schemas with link definitions (hyper schemas).
      • From 5d5a1d536eff82428a672bb9f61bd2486d8bb17b Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:46:20 +0200 Subject: [PATCH 0140/1659] address example schema: bring up to date, beautify --- address | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/address b/address index c553848c..c1746b44 100644 --- a/address +++ b/address @@ -1,12 +1,17 @@ -{"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} +{ + "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" } -} \ No newline at end of file +} From a4d61795ee9746dd3d3e941101e4f2e7e9425234 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:46:33 +0200 Subject: [PATCH 0141/1659] calendar example schema: bring up to date, beautify --- calendar | 49 +++++++++++++++++++++++++++++++++++-------------- 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/calendar b/calendar index 9b02c4d7..4de97790 100644 --- a/calendar +++ b/calendar @@ -1,17 +1,38 @@ -{"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" +{ + "description": "A representation of an event", + "type": "object", + "properties": { + "dtstart": { + "format": "date-time", + "type": "string", + "description": "Event starting time", + "required": true + }, + "dtend": { + "format": "date-time", + "type": "string", + "description": "Event ending time" + }, + "summary": { "type": "string", "required": true }, + "location": { "type": "string" }, + "url": { "type": "string", "format": "uri" }, + "duration": { + "format": "time", + "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/geo" } } } From 24577b1f8defaf2d2ede20cf6fc406a321206e9c Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:46:44 +0200 Subject: [PATCH 0142/1659] card example schema: bring up to date, beautify --- card | 82 +++++++++++++++++++++++++++++++----------------------------- 1 file changed, 43 insertions(+), 39 deletions(-) diff --git a/card b/card index ba47d78b..062d84d0 100644 --- a/card +++ b/card @@ -1,43 +1,47 @@ -{"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"}}, +{ + "description": "A representation of a person, company, organization, or place", + "type": "object", + "properties": { + "fn": { + "description": "Formatted Name", + "type": "string" }, - "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"}}, + "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": "uri" }, + "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": { "type": "string" }, + "logo": { "type": "string" }, + "sound": { "type": "string" }, + "bday": { "type": "string", "format": "date" }, + "title": { "type": "string" }, + "role": { "type": "string" }, + "org": { + "type": "object", + "properties": { + "organizationName": { "type": "string" }, + "organizationUnit": { "type": "string" } + } } } } - - - - From 1876ac9da47819390e366b01d50e68861e922b2e Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:48:12 +0200 Subject: [PATCH 0143/1659] geo example schema: bring up to date, beautify --- geo | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/geo b/geo index 73a9851b..b472c4e1 100644 --- a/geo +++ b/geo @@ -1,7 +1,8 @@ -{"description":"A geographical coordinate", - "type":"object", - "properties":{ - "latitude":{"type":"number"}, - "longitude":{"type":"number"} +{ + "description": "A geographical coordinate", + "type": "object", + "properties": { + "latitude": { "type": "number" }, + "longitude": { "type": "number" } } -} \ No newline at end of file +} From 255008cea398e9c77b97ed515678d59d911d84a4 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:48:40 +0200 Subject: [PATCH 0144/1659] Remove obsolete files All where schemas, and obsolete at that. Purge. --- address-v2 | 12 ---- address.properties | 9 --- calendar-v2 | 20 ------ calendar.properties | 13 ---- card-v2 | 47 ------------- card.properties | 40 ----------- geo-v2 | 7 -- geo.properties | 4 -- hyper-schema-v2 | 68 ------------------ interfaces-v2 | 23 ------ json-ref-v2 | 26 ------- links-v2 | 35 ---------- schema-v2 | 165 -------------------------------------------- schema.properties | 136 ------------------------------------ 14 files changed, 605 deletions(-) delete mode 100644 address-v2 delete mode 100644 address.properties delete mode 100644 calendar-v2 delete mode 100644 calendar.properties delete mode 100644 card-v2 delete mode 100644 card.properties delete mode 100644 geo-v2 delete mode 100644 geo.properties delete mode 100644 hyper-schema-v2 delete mode 100644 interfaces-v2 delete mode 100644 json-ref-v2 delete mode 100644 links-v2 delete mode 100644 schema-v2 delete mode 100644 schema.properties diff --git a/address-v2 b/address-v2 deleted file mode 100644 index 437da9e4..00000000 --- a/address-v2 +++ /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","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 deleted file mode 100644 index fc61ac2b..00000000 --- a/address.properties +++ /dev/null @@ -1,9 +0,0 @@ -{ -"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-v2 b/calendar-v2 deleted file mode 100644 index d2503693..00000000 --- a/calendar-v2 +++ /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"}, - "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 deleted file mode 100644 index a71520d8..00000000 --- a/calendar.properties +++ /dev/null @@ -1,13 +0,0 @@ -{ - "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-v2 b/card-v2 deleted file mode 100644 index 520dfbbe..00000000 --- a/card-v2 +++ /dev/null @@ -1,47 +0,0 @@ -{"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 deleted file mode 100644 index 8704f79c..00000000 --- a/card.properties +++ /dev/null @@ -1,40 +0,0 @@ -{ - "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/geo-v2 b/geo-v2 deleted file mode 100644 index 73a9851b..00000000 --- a/geo-v2 +++ /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/geo.properties b/geo.properties deleted file mode 100644 index 3449cd06..00000000 --- a/geo.properties +++ /dev/null @@ -1,4 +0,0 @@ -{ -"latitude":{"type":"number"}, -"longitude":{"type":"number"} -} diff --git a/hyper-schema-v2 b/hyper-schema-v2 deleted file mode 100644 index b995b83f..00000000 --- a/hyper-schema-v2 +++ /dev/null @@ -1,68 +0,0 @@ -{ - "$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/interfaces-v2 b/interfaces-v2 deleted file mode 100644 index 7118195b..00000000 --- a/interfaces-v2 +++ /dev/null @@ -1,23 +0,0 @@ -{ - "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-v2 b/json-ref-v2 deleted file mode 100644 index 9b12616e..00000000 --- a/json-ref-v2 +++ /dev/null @@ -1,26 +0,0 @@ -{ - "$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-v2 b/links-v2 deleted file mode 100644 index 6989b6d1..00000000 --- a/links-v2 +++ /dev/null @@ -1,35 +0,0 @@ -{ - "$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-v2 b/schema-v2 deleted file mode 100644 index f9d1a011..00000000 --- a/schema-v2 +++ /dev/null @@ -1,165 +0,0 @@ -{ - "$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 deleted file mode 100644 index 3f4041ab..00000000 --- a/schema.properties +++ /dev/null @@ -1,136 +0,0 @@ -{ - "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 From a154f3b614b10be11eca201ede17f77e484de909 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:54:01 +0200 Subject: [PATCH 0145/1659] hyper-schema: bring up to date, beautify --- hyper-schema | 129 +++++++++++++++++++++++++-------------------------- 1 file changed, 64 insertions(+), 65 deletions(-) diff --git a/hyper-schema b/hyper-schema index 3fedec1e..49e89e2a 100644 --- a/hyper-schema +++ b/hyper-schema @@ -1,107 +1,106 @@ { - "id" : "http://json-schema.org/hyper-schema", + "id": "http://json-schema.org/hyper-schema", - "properties" : { - "links" : { - "type" : "array", - "items" : "http://json-schema.org/links" + "properties": { + "links": { + "type": "array", + "items": { "$ref": "http://json-schema.org/links" } }, - "fragmentResolution" : { - "type" : "string", - "default" : "slash-delimited" + "fragmentResolution": { + "type": "string", + "default": "slash-delimited" }, - "root" : { - "type" : "boolean", - "default" : false + "root": { + "type": "boolean", + "default": false }, - "readonly" : { - "type" : "boolean", - "default" : false + "readonly": { + "type": "boolean", + "default": false }, - "pathStart" : { - "type" : "string", - "format" : "uri" + "pathStart": { + "type": "string", + "format": "uri" }, - "mediaType" : { - "type" : "string", - "format" : "media-type" + "mediaType": { + "type": "string" }, - "alternate" : { - "type" : "array", - "items" : "http://json-schema.org/hyper-schema-or-uri" + "alternate": { + "type": "array", + "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" } }, - "type" : { - "type" : ["string", "array"], - "items" : { - "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"] + "type": { + "type": [ "string", "array" ], + "items": { + "type": [ "string", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ] }, - "uniqueItems" : true, - "default" : "any" + "uniqueItems": true, + "default": "any" }, - "properties" : { - "type" : "object", - "additionalProperties" : "http://json-schema.org/hyper-schema-or-uri", - "default" : {} + "properties": { + "type": "object", + "additionalProperties": { "$ref": "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" : {} + "items": { + "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "array" ], + "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, + "default": {} }, - "additionalProperties" : { - "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"], - "default" : {} + "additionalProperties": { + "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "boolean" ], + "default": {} }, - "additionalItems" : { - "type" : ["http://json-schema.org/hyper-schema-or-uri", "boolean"], - "default" : {} + "additionalItems": { + "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "boolean" ], + "default": {} }, - "contentEncoding" : { - "type" : "string" + "contentEncoding": { + "type": "string" }, - "default" : { + "default": { }, - "requires" : { - "type" : ["string", "http://json-schema.org/hyper-schema-or-uri"] + "requires": { + "type": [ "string", { "$ref": "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"] + "disallow": { + "type": [ "string", "array", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ], + "items": { + "type": [ "string", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ] }, - "uniqueItems" : true + "uniqueItems": true }, - "extends" : { - "type" : ["http://json-schema.org/hyper-schema-or-uri", "array"], - "items" : "http://json-schema.org/hyper-schema-or-uri", - "default" : {} + "extends": { + "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "array"], + "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, + "default": {} } }, - "links" : [ + "links": [ { - "href" : "{$schema}", - "rel" : "describedby" + "href": "{$schema}", + "rel": "describedby" }, { - "href" : "{$ref}", - "rel" : "full" + "href": "{$ref}", + "rel": "full" } ], - "fragmentResolution" : "dot-delimited", - "extends" : "http://json-schema.org/schema" -} \ No newline at end of file + "fragmentResolution": "dot-delimited", + "extends": { "$ref": "http://json-schema.org/schema" } +} From ed2398d1f0778aad05a08bbd269e43a3a61f0048 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:55:18 +0200 Subject: [PATCH 0146/1659] hyper-schema-or-uri: bring up to date, beautify --- hyper-schema-or-uri | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/hyper-schema-or-uri b/hyper-schema-or-uri index 8d2a3c18..506dd1cc 100644 --- a/hyper-schema-or-uri +++ b/hyper-schema-or-uri @@ -1,10 +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 + "id": "http://json-schema.org/hyper-schema-or-uri", + "type": [ + { + "type": "string", + "links": [ { "rel": "full", "href": "{@}" } ] + }, + { "$ref": "http://json-schema.org/hyper-schema" } + ] +} From fc85fddca4379bd3e2641c83061ace07daac3451 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 21 Aug 2012 20:57:41 +0200 Subject: [PATCH 0147/1659] implementations.html: add json-schema-validator as a Java implementation And remove Jackson: while it does have a JsonSchema class, it outputs nothing else than { "type": "any" }, which it pretty much useless. --- implementations.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/implementations.html b/implementations.html index b90e9c1a..015047b9 100644 --- a/implementations.html +++ b/implementations.html @@ -9,7 +9,7 @@

        JSON Schema Implementations:

      • JavaScript - schema.js
      • JavaScript - json-schema
      • JavaScript - Dojo
      • -
      • Java - Jackson
      • +
      • Java - json-schema-validator
      • PHP
      • Python
      • Rhino
      • @@ -19,4 +19,4 @@

        JSON Schema Implementations:

      • ActionScript 3
      - \ No newline at end of file + From ecf47c122cc815fbe4003a459e0fd274b98f7bd0 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Thu, 30 Aug 2012 10:04:15 +0200 Subject: [PATCH 0148/1659] implementaions.html: mention WJElement as an implementation --- implementations.html | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/implementations.html b/implementations.html index 015047b9..c4a90975 100644 --- a/implementations.html +++ b/implementations.html @@ -1,22 +1,23 @@ - - JSON Schema Implementations - - -

      JSON Schema Implementations:

      - - + + JSON Schema Implementations + + +

      JSON Schema Implementations:

      + + From 8db3759edef63aaa257f1c55a83301422ef3435c Mon Sep 17 00:00:00 2001 From: nickl- Date: Fri, 31 Aug 2012 13:30:07 +0200 Subject: [PATCH 0149/1659] CNAME for json-schema.org see #3 --- CNAME | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 00000000..0d9c62bd --- /dev/null +++ b/CNAME @@ -0,0 +1,2 @@ +json-schema.org + From 28508e5f4fa274676ff631aeb2c1b0fc823eefe4 Mon Sep 17 00:00:00 2001 From: nickl- Date: Fri, 31 Aug 2012 16:01:42 +0200 Subject: [PATCH 0150/1659] CNAME to also include json-schema.github.com --- CNAME | 1 + 1 file changed, 1 insertion(+) diff --git a/CNAME b/CNAME index 0d9c62bd..45569e38 100644 --- a/CNAME +++ b/CNAME @@ -1,2 +1,3 @@ +json-schema.github.com json-schema.org From 4638a789d37ef1a923ebbd36f23ece55c45ff34f Mon Sep 17 00:00:00 2001 From: nickl- Date: Fri, 31 Aug 2012 16:04:17 +0200 Subject: [PATCH 0151/1659] CNAME can only have one domain --- CNAME | 1 - 1 file changed, 1 deletion(-) diff --git a/CNAME b/CNAME index 45569e38..0d9c62bd 100644 --- a/CNAME +++ b/CNAME @@ -1,3 +1,2 @@ -json-schema.github.com json-schema.org From 1d0effb7285b5c05955efe2b49040570bc8cf0d7 Mon Sep 17 00:00:00 2001 From: nickl- Date: Sat, 1 Sep 2012 10:47:51 +0200 Subject: [PATCH 0152/1659] Just a touch of style --- lib/bootstrap-alert.js | 90 ++++++++++++ lib/bootstrap-button.js | 96 ++++++++++++ lib/bootstrap-carousel.js | 169 +++++++++++++++++++++ lib/bootstrap-collapse.js | 157 ++++++++++++++++++++ lib/bootstrap-dropdown.js | 100 +++++++++++++ lib/bootstrap-min.css | 9 ++ lib/bootstrap-modal.js | 218 +++++++++++++++++++++++++++ lib/bootstrap-popover.js | 98 +++++++++++++ lib/bootstrap-scrollspy.js | 151 +++++++++++++++++++ lib/bootstrap-tab.js | 135 +++++++++++++++++ lib/bootstrap-tooltip.js | 275 ++++++++++++++++++++++++++++++++++ lib/bootstrap-transition.js | 61 ++++++++ lib/bootstrap-typeahead.js | 285 ++++++++++++++++++++++++++++++++++++ 13 files changed, 1844 insertions(+) create mode 100644 lib/bootstrap-alert.js create mode 100644 lib/bootstrap-button.js create mode 100644 lib/bootstrap-carousel.js create mode 100644 lib/bootstrap-collapse.js create mode 100644 lib/bootstrap-dropdown.js create mode 100644 lib/bootstrap-min.css create mode 100644 lib/bootstrap-modal.js create mode 100644 lib/bootstrap-popover.js create mode 100644 lib/bootstrap-scrollspy.js create mode 100644 lib/bootstrap-tab.js create mode 100644 lib/bootstrap-tooltip.js create mode 100644 lib/bootstrap-transition.js create mode 100644 lib/bootstrap-typeahead.js diff --git a/lib/bootstrap-alert.js b/lib/bootstrap-alert.js new file mode 100644 index 00000000..57890a9a --- /dev/null +++ b/lib/bootstrap-alert.js @@ -0,0 +1,90 @@ +/* ========================================================== + * bootstrap-alert.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#alerts + * ========================================================== + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ========================================================== */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* ALERT CLASS DEFINITION + * ====================== */ + + var dismiss = '[data-dismiss="alert"]' + , Alert = function (el) { + $(el).on('click', dismiss, this.close) + } + + Alert.prototype.close = function (e) { + var $this = $(this) + , selector = $this.attr('data-target') + , $parent + + if (!selector) { + selector = $this.attr('href') + selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') //strip for ie7 + } + + $parent = $(selector) + + e && e.preventDefault() + + $parent.length || ($parent = $this.hasClass('alert') ? $this : $this.parent()) + + $parent.trigger(e = $.Event('close')) + + if (e.isDefaultPrevented()) return + + $parent.removeClass('in') + + function removeElement() { + $parent + .trigger('closed') + .remove() + } + + $.support.transition && $parent.hasClass('fade') ? + $parent.on($.support.transition.end, removeElement) : + removeElement() + } + + + /* ALERT PLUGIN DEFINITION + * ======================= */ + + $.fn.alert = function (option) { + return this.each(function () { + var $this = $(this) + , data = $this.data('alert') + if (!data) $this.data('alert', (data = new Alert(this))) + if (typeof option == 'string') data[option].call($this) + }) + } + + $.fn.alert.Constructor = Alert + + + /* ALERT DATA-API + * ============== */ + + $(function () { + $('body').on('click.alert.data-api', dismiss, Alert.prototype.close) + }) + +}(window.jQuery); \ No newline at end of file diff --git a/lib/bootstrap-button.js b/lib/bootstrap-button.js new file mode 100644 index 00000000..7f187be6 --- /dev/null +++ b/lib/bootstrap-button.js @@ -0,0 +1,96 @@ +/* ============================================================ + * bootstrap-button.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#buttons + * ============================================================ + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ============================================================ */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* BUTTON PUBLIC CLASS DEFINITION + * ============================== */ + + var Button = function (element, options) { + this.$element = $(element) + this.options = $.extend({}, $.fn.button.defaults, options) + } + + Button.prototype.setState = function (state) { + var d = 'disabled' + , $el = this.$element + , data = $el.data() + , val = $el.is('input') ? 'val' : 'html' + + state = state + 'Text' + data.resetText || $el.data('resetText', $el[val]()) + + $el[val](data[state] || this.options[state]) + + // push to event loop to allow forms to submit + setTimeout(function () { + state == 'loadingText' ? + $el.addClass(d).attr(d, d) : + $el.removeClass(d).removeAttr(d) + }, 0) + } + + Button.prototype.toggle = function () { + var $parent = this.$element.parent('[data-toggle="buttons-radio"]') + + $parent && $parent + .find('.active') + .removeClass('active') + + this.$element.toggleClass('active') + } + + + /* BUTTON PLUGIN DEFINITION + * ======================== */ + + $.fn.button = function (option) { + return this.each(function () { + var $this = $(this) + , data = $this.data('button') + , options = typeof option == 'object' && option + if (!data) $this.data('button', (data = new Button(this, options))) + if (option == 'toggle') data.toggle() + else if (option) data.setState(option) + }) + } + + $.fn.button.defaults = { + loadingText: 'loading...' + } + + $.fn.button.Constructor = Button + + + /* BUTTON DATA-API + * =============== */ + + $(function () { + $('body').on('click.button.data-api', '[data-toggle^=button]', function ( e ) { + var $btn = $(e.target) + if (!$btn.hasClass('btn')) $btn = $btn.closest('.btn') + $btn.button('toggle') + }) + }) + +}(window.jQuery); \ No newline at end of file diff --git a/lib/bootstrap-carousel.js b/lib/bootstrap-carousel.js new file mode 100644 index 00000000..551de589 --- /dev/null +++ b/lib/bootstrap-carousel.js @@ -0,0 +1,169 @@ +/* ========================================================== + * bootstrap-carousel.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#carousel + * ========================================================== + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ========================================================== */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* CAROUSEL CLASS DEFINITION + * ========================= */ + + var Carousel = function (element, options) { + this.$element = $(element) + this.options = options + this.options.slide && this.slide(this.options.slide) + this.options.pause == 'hover' && this.$element + .on('mouseenter', $.proxy(this.pause, this)) + .on('mouseleave', $.proxy(this.cycle, this)) + } + + Carousel.prototype = { + + cycle: function (e) { + if (!e) this.paused = false + this.options.interval + && !this.paused + && (this.interval = setInterval($.proxy(this.next, this), this.options.interval)) + return this + } + + , to: function (pos) { + var $active = this.$element.find('.active') + , children = $active.parent().children() + , activePos = children.index($active) + , that = this + + if (pos > (children.length - 1) || pos < 0) return + + if (this.sliding) { + return this.$element.one('slid', function () { + that.to(pos) + }) + } + + if (activePos == pos) { + return this.pause().cycle() + } + + return this.slide(pos > activePos ? 'next' : 'prev', $(children[pos])) + } + + , pause: function (e) { + if (!e) this.paused = true + clearInterval(this.interval) + this.interval = null + return this + } + + , next: function () { + if (this.sliding) return + return this.slide('next') + } + + , prev: function () { + if (this.sliding) return + return this.slide('prev') + } + + , slide: function (type, next) { + var $active = this.$element.find('.active') + , $next = next || $active[type]() + , isCycling = this.interval + , direction = type == 'next' ? 'left' : 'right' + , fallback = type == 'next' ? 'first' : 'last' + , that = this + , e = $.Event('slide') + + this.sliding = true + + isCycling && this.pause() + + $next = $next.length ? $next : this.$element.find('.item')[fallback]() + + if ($next.hasClass('active')) return + + if ($.support.transition && this.$element.hasClass('slide')) { + this.$element.trigger(e) + if (e.isDefaultPrevented()) return + $next.addClass(type) + $next[0].offsetWidth // force reflow + $active.addClass(direction) + $next.addClass(direction) + this.$element.one($.support.transition.end, function () { + $next.removeClass([type, direction].join(' ')).addClass('active') + $active.removeClass(['active', direction].join(' ')) + that.sliding = false + setTimeout(function () { that.$element.trigger('slid') }, 0) + }) + } else { + this.$element.trigger(e) + if (e.isDefaultPrevented()) return + $active.removeClass('active') + $next.addClass('active') + this.sliding = false + this.$element.trigger('slid') + } + + isCycling && this.cycle() + + return this + } + + } + + + /* CAROUSEL PLUGIN DEFINITION + * ========================== */ + + $.fn.carousel = function (option) { + return this.each(function () { + var $this = $(this) + , data = $this.data('carousel') + , options = $.extend({}, $.fn.carousel.defaults, typeof option == 'object' && option) + if (!data) $this.data('carousel', (data = new Carousel(this, options))) + if (typeof option == 'number') data.to(option) + else if (typeof option == 'string' || (option = options.slide)) data[option]() + else if (options.interval) data.cycle() + }) + } + + $.fn.carousel.defaults = { + interval: 5000 + , pause: 'hover' + } + + $.fn.carousel.Constructor = Carousel + + + /* CAROUSEL DATA-API + * ================= */ + + $(function () { + $('body').on('click.carousel.data-api', '[data-slide]', function ( e ) { + var $this = $(this), href + , $target = $($this.attr('data-target') || (href = $this.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '')) //strip for ie7 + , options = !$target.data('modal') && $.extend({}, $target.data(), $this.data()) + $target.carousel(options) + e.preventDefault() + }) + }) + +}(window.jQuery); \ No newline at end of file diff --git a/lib/bootstrap-collapse.js b/lib/bootstrap-collapse.js new file mode 100644 index 00000000..fbc915b9 --- /dev/null +++ b/lib/bootstrap-collapse.js @@ -0,0 +1,157 @@ +/* ============================================================= + * bootstrap-collapse.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#collapse + * ============================================================= + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ============================================================ */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* COLLAPSE PUBLIC CLASS DEFINITION + * ================================ */ + + var Collapse = function (element, options) { + this.$element = $(element) + this.options = $.extend({}, $.fn.collapse.defaults, options) + + if (this.options.parent) { + this.$parent = $(this.options.parent) + } + + this.options.toggle && this.toggle() + } + + Collapse.prototype = { + + constructor: Collapse + + , dimension: function () { + var hasWidth = this.$element.hasClass('width') + return hasWidth ? 'width' : 'height' + } + + , show: function () { + var dimension + , scroll + , actives + , hasData + + if (this.transitioning) return + + dimension = this.dimension() + scroll = $.camelCase(['scroll', dimension].join('-')) + actives = this.$parent && this.$parent.find('> .accordion-group > .in') + + if (actives && actives.length) { + hasData = actives.data('collapse') + if (hasData && hasData.transitioning) return + actives.collapse('hide') + hasData || actives.data('collapse', null) + } + + this.$element[dimension](0) + this.transition('addClass', $.Event('show'), 'shown') + this.$element[dimension](this.$element[0][scroll]) + } + + , hide: function () { + var dimension + if (this.transitioning) return + dimension = this.dimension() + this.reset(this.$element[dimension]()) + this.transition('removeClass', $.Event('hide'), 'hidden') + this.$element[dimension](0) + } + + , reset: function (size) { + var dimension = this.dimension() + + this.$element + .removeClass('collapse') + [dimension](size || 'auto') + [0].offsetWidth + + this.$element[size !== null ? 'addClass' : 'removeClass']('collapse') + + return this + } + + , transition: function (method, startEvent, completeEvent) { + var that = this + , complete = function () { + if (startEvent.type == 'show') that.reset() + that.transitioning = 0 + that.$element.trigger(completeEvent) + } + + this.$element.trigger(startEvent) + + if (startEvent.isDefaultPrevented()) return + + this.transitioning = 1 + + this.$element[method]('in') + + $.support.transition && this.$element.hasClass('collapse') ? + this.$element.one($.support.transition.end, complete) : + complete() + } + + , toggle: function () { + this[this.$element.hasClass('in') ? 'hide' : 'show']() + } + + } + + + /* COLLAPSIBLE PLUGIN DEFINITION + * ============================== */ + + $.fn.collapse = function (option) { + return this.each(function () { + var $this = $(this) + , data = $this.data('collapse') + , options = typeof option == 'object' && option + if (!data) $this.data('collapse', (data = new Collapse(this, options))) + if (typeof option == 'string') data[option]() + }) + } + + $.fn.collapse.defaults = { + toggle: true + } + + $.fn.collapse.Constructor = Collapse + + + /* COLLAPSIBLE DATA-API + * ==================== */ + + $(function () { + $('body').on('click.collapse.data-api', '[data-toggle=collapse]', function ( e ) { + var $this = $(this), href + , target = $this.attr('data-target') + || e.preventDefault() + || (href = $this.attr('href')) && href.replace(/.*(?=#[^\s]+$)/, '') //strip for ie7 + , option = $(target).data('collapse') ? 'toggle' : $this.data() + $(target).collapse(option) + }) + }) + +}(window.jQuery); \ No newline at end of file diff --git a/lib/bootstrap-dropdown.js b/lib/bootstrap-dropdown.js new file mode 100644 index 00000000..454a9684 --- /dev/null +++ b/lib/bootstrap-dropdown.js @@ -0,0 +1,100 @@ +/* ============================================================ + * bootstrap-dropdown.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#dropdowns + * ============================================================ + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ============================================================ */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* DROPDOWN CLASS DEFINITION + * ========================= */ + + var toggle = '[data-toggle="dropdown"]' + , Dropdown = function (element) { + var $el = $(element).on('click.dropdown.data-api', this.toggle) + $('html').on('click.dropdown.data-api', function () { + $el.parent().removeClass('open') + }) + } + + Dropdown.prototype = { + + constructor: Dropdown + + , toggle: function (e) { + var $this = $(this) + , $parent + , selector + , isActive + + if ($this.is('.disabled, :disabled')) return + + selector = $this.attr('data-target') + + if (!selector) { + selector = $this.attr('href') + selector = selector && selector.replace(/.*(?=#[^\s]*$)/, '') //strip for ie7 + } + + $parent = $(selector) + $parent.length || ($parent = $this.parent()) + + isActive = $parent.hasClass('open') + + clearMenus() + + if (!isActive) $parent.toggleClass('open') + + return false + } + + } + + function clearMenus() { + $(toggle).parent().removeClass('open') + } + + + /* DROPDOWN PLUGIN DEFINITION + * ========================== */ + + $.fn.dropdown = function (option) { + return this.each(function () { + var $this = $(this) + , data = $this.data('dropdown') + if (!data) $this.data('dropdown', (data = new Dropdown(this))) + if (typeof option == 'string') data[option].call($this) + }) + } + + $.fn.dropdown.Constructor = Dropdown + + + /* APPLY TO STANDARD DROPDOWN ELEMENTS + * =================================== */ + + $(function () { + $('html').on('click.dropdown.data-api', clearMenus) + $('body') + .on('click.dropdown', '.dropdown form', function (e) { e.stopPropagation() }) + .on('click.dropdown.data-api', toggle, Dropdown.prototype.toggle) + }) + +}(window.jQuery); \ No newline at end of file diff --git a/lib/bootstrap-min.css b/lib/bootstrap-min.css new file mode 100644 index 00000000..11c533fb --- /dev/null +++ b/lib/bootstrap-min.css @@ -0,0 +1,9 @@ +/*! + * Bootstrap v2.0.4 + * + * Copyright 2012 Twitter, Inc + * Licensed under the Apache License v2.0 + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Designed and built with all the love in the world @twitter by @mdo and @fat. + */article,aside,details,figcaption,figure,footer,header,hgroup,nav,section{display:block}audio,canvas,video{display:inline-block;*display:inline;*zoom:1}audio:not([controls]){display:none}html{font-size:100%;-webkit-text-size-adjust:100%;-ms-text-size-adjust:100%}a:focus{outline:thin dotted #333;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}a:hover,a:active{outline:0}sub,sup{position:relative;font-size:75%;line-height:0;vertical-align:baseline}sup{top:-0.5em}sub{bottom:-0.25em}img{max-width:100%;vertical-align:middle;border:0;-ms-interpolation-mode:bicubic}#map_canvas img{max-width:none}button,input,select,textarea{margin:0;font-size:100%;vertical-align:middle}button,input{*overflow:visible;line-height:normal}button::-moz-focus-inner,input::-moz-focus-inner{padding:0;border:0}button,input[type="button"],input[type="reset"],input[type="submit"]{cursor:pointer;-webkit-appearance:button}input[type="search"]{-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box;-webkit-appearance:textfield}input[type="search"]::-webkit-search-decoration,input[type="search"]::-webkit-search-cancel-button{-webkit-appearance:none}textarea{overflow:auto;vertical-align:top}.clearfix{*zoom:1}.clearfix:before,.clearfix:after{display:table;content:""}.clearfix:after{clear:both}.hide-text{font:0/0 a;color:transparent;text-shadow:none;background-color:transparent;border:0}.input-block-level{display:block;width:100%;min-height:28px;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;-ms-box-sizing:border-box;box-sizing:border-box}body{margin:0;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;line-height:18px;color:#333;background-color:#fff}a{color:#08c;text-decoration:none}a:hover{color:#005580;text-decoration:underline}.row{margin-left:-20px;*zoom:1}.row:before,.row:after{display:table;content:""}.row:after{clear:both}[class*="span"]{float:left;margin-left:20px}.container,.navbar-fixed-top .container,.navbar-fixed-bottom .container{width:940px}.span12{width:940px}.span11{width:860px}.span10{width:780px}.span9{width:700px}.span8{width:620px}.span7{width:540px}.span6{width:460px}.span5{width:380px}.span4{width:300px}.span3{width:220px}.span2{width:140px}.span1{width:60px}.offset12{margin-left:980px}.offset11{margin-left:900px}.offset10{margin-left:820px}.offset9{margin-left:740px}.offset8{margin-left:660px}.offset7{margin-left:580px}.offset6{margin-left:500px}.offset5{margin-left:420px}.offset4{margin-left:340px}.offset3{margin-left:260px}.offset2{margin-left:180px}.offset1{margin-left:100px}.row-fluid{width:100%;*zoom:1}.row-fluid:before,.row-fluid:after{display:table;content:""}.row-fluid:after{clear:both}.row-fluid [class*="span"]{display:block;width:100%;min-height:28px;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;-ms-box-sizing:border-box;box-sizing:border-box;float:left;margin-left:2.127659574%;*margin-left:2.0744680846382977%}.row-fluid [class*="span"]:first-child{margin-left:0}.row-fluid .span12{width:99.99999998999999%;*width:99.94680850063828%}.row-fluid .span11{width:91.489361693%;*width:91.4361702036383%}.row-fluid .span10{width:82.97872339599999%;*width:82.92553190663828%}.row-fluid .span9{width:74.468085099%;*width:74.4148936096383%}.row-fluid .span8{width:65.95744680199999%;*width:65.90425531263828%}.row-fluid .span7{width:57.446808505%;*width:57.3936170156383%}.row-fluid .span6{width:48.93617020799999%;*width:48.88297871863829%}.row-fluid .span5{width:40.425531911%;*width:40.3723404216383%}.row-fluid .span4{width:31.914893614%;*width:31.8617021246383%}.row-fluid .span3{width:23.404255317%;*width:23.3510638276383%}.row-fluid .span2{width:14.89361702%;*width:14.8404255306383%}.row-fluid .span1{width:6.382978723%;*width:6.329787233638298%}.container{margin-right:auto;margin-left:auto;*zoom:1}.container:before,.container:after{display:table;content:""}.container:after{clear:both}.container-fluid{padding-right:20px;padding-left:20px;*zoom:1}.container-fluid:before,.container-fluid:after{display:table;content:""}.container-fluid:after{clear:both}p{margin:0 0 9px}p small{font-size:11px;color:#999}.lead{margin-bottom:18px;font-size:20px;font-weight:200;line-height:27px}h1,h2,h3,h4,h5,h6{margin:0;font-family:inherit;font-weight:bold;color:inherit;text-rendering:optimizelegibility}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small{font-weight:normal;color:#999}h1{font-size:30px;line-height:36px}h1 small{font-size:18px}h2{font-size:24px;line-height:36px}h2 small{font-size:18px}h3{font-size:18px;line-height:27px}h3 small{font-size:14px}h4,h5,h6{line-height:18px}h4{font-size:14px}h4 small{font-size:12px}h5{font-size:12px}h6{font-size:11px;color:#999;text-transform:uppercase}.page-header{padding-bottom:17px;margin:18px 0;border-bottom:1px solid #eee}.page-header h1{line-height:1}ul,ol{padding:0;margin:0 0 9px 25px}ul ul,ul ol,ol ol,ol ul{margin-bottom:0}ul{list-style:disc}ol{list-style:decimal}li{line-height:18px}ul.unstyled,ol.unstyled{margin-left:0;list-style:none}dl{margin-bottom:18px}dt,dd{line-height:18px}dt{font-weight:bold;line-height:17px}dd{margin-left:9px}.dl-horizontal dt{float:left;width:120px;clear:left;text-align:right;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.dl-horizontal dd{margin-left:130px}hr{margin:18px 0;border:0;border-top:1px solid #eee;border-bottom:1px solid #fff}strong{font-weight:bold}em{font-style:italic}.muted{color:#999}abbr[title]{cursor:help;border-bottom:1px dotted #999}abbr.initialism{font-size:90%;text-transform:uppercase}blockquote{padding:0 0 0 15px;margin:0 0 18px;border-left:5px solid #eee}blockquote p{margin-bottom:0;font-size:16px;font-weight:300;line-height:22.5px}blockquote small{display:block;line-height:18px;color:#999}blockquote small:before{content:'\2014 \00A0'}blockquote.pull-right{float:right;padding-right:15px;padding-left:0;border-right:5px solid #eee;border-left:0}blockquote.pull-right p,blockquote.pull-right small{text-align:right}q:before,q:after,blockquote:before,blockquote:after{content:""}address{display:block;margin-bottom:18px;font-style:normal;line-height:18px}small{font-size:100%}cite{font-style:normal}code,pre{padding:0 3px 2px;font-family:Menlo,Monaco,Consolas,"Courier New",monospace;font-size:12px;color:#333;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px}code{padding:2px 4px;color:#d14;background-color:#f7f7f9;border:1px solid #e1e1e8}pre{display:block;padding:8.5px;margin:0 0 9px;font-size:12.025px;line-height:18px;word-break:break-all;word-wrap:break-word;white-space:pre;white-space:pre-wrap;background-color:#f5f5f5;border:1px solid #ccc;border:1px solid rgba(0,0,0,0.15);-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}pre.prettyprint{margin-bottom:18px}pre code{padding:0;color:inherit;background-color:transparent;border:0}.pre-scrollable{max-height:340px;overflow-y:scroll}form{margin:0 0 18px}fieldset{padding:0;margin:0;border:0}legend{display:block;width:100%;padding:0;margin-bottom:27px;font-size:19.5px;line-height:36px;color:#333;border:0;border-bottom:1px solid #e5e5e5}legend small{font-size:13.5px;color:#999}label,input,button,select,textarea{font-size:13px;font-weight:normal;line-height:18px}input,button,select,textarea{font-family:"Helvetica Neue",Helvetica,Arial,sans-serif}label{display:block;margin-bottom:5px}select,textarea,input[type="text"],input[type="password"],input[type="datetime"],input[type="datetime-local"],input[type="date"],input[type="month"],input[type="time"],input[type="week"],input[type="number"],input[type="email"],input[type="url"],input[type="search"],input[type="tel"],input[type="color"],.uneditable-input{display:inline-block;height:18px;padding:4px;margin-bottom:9px;font-size:13px;line-height:18px;color:#555}input,textarea{width:210px}textarea{height:auto}textarea,input[type="text"],input[type="password"],input[type="datetime"],input[type="datetime-local"],input[type="date"],input[type="month"],input[type="time"],input[type="week"],input[type="number"],input[type="email"],input[type="url"],input[type="search"],input[type="tel"],input[type="color"],.uneditable-input{background-color:#fff;border:1px solid #ccc;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);-moz-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);-webkit-transition:border linear .2s,box-shadow linear .2s;-moz-transition:border linear .2s,box-shadow linear .2s;-ms-transition:border linear .2s,box-shadow linear .2s;-o-transition:border linear .2s,box-shadow linear .2s;transition:border linear .2s,box-shadow linear .2s}textarea:focus,input[type="text"]:focus,input[type="password"]:focus,input[type="datetime"]:focus,input[type="datetime-local"]:focus,input[type="date"]:focus,input[type="month"]:focus,input[type="time"]:focus,input[type="week"]:focus,input[type="number"]:focus,input[type="email"]:focus,input[type="url"]:focus,input[type="search"]:focus,input[type="tel"]:focus,input[type="color"]:focus,.uneditable-input:focus{border-color:rgba(82,168,236,0.8);outline:0;outline:thin dotted \9;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(82,168,236,.6);-moz-box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(82,168,236,.6);box-shadow:inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(82,168,236,.6)}input[type="radio"],input[type="checkbox"]{margin:3px 0;*margin-top:0;line-height:normal;cursor:pointer}input[type="submit"],input[type="reset"],input[type="button"],input[type="radio"],input[type="checkbox"]{width:auto}.uneditable-textarea{width:auto;height:auto}select,input[type="file"]{height:28px;*margin-top:4px;line-height:28px}select{width:220px;border:1px solid #bbb}select[multiple],select[size]{height:auto}select:focus,input[type="file"]:focus,input[type="radio"]:focus,input[type="checkbox"]:focus{outline:thin dotted #333;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.radio,.checkbox{min-height:18px;padding-left:18px}.radio input[type="radio"],.checkbox input[type="checkbox"]{float:left;margin-left:-18px}.controls>.radio:first-child,.controls>.checkbox:first-child{padding-top:5px}.radio.inline,.checkbox.inline{display:inline-block;padding-top:5px;margin-bottom:0;vertical-align:middle}.radio.inline+.radio.inline,.checkbox.inline+.checkbox.inline{margin-left:10px}.input-mini{width:60px}.input-small{width:90px}.input-medium{width:150px}.input-large{width:210px}.input-xlarge{width:270px}.input-xxlarge{width:530px}input[class*="span"],select[class*="span"],textarea[class*="span"],.uneditable-input[class*="span"],.row-fluid input[class*="span"],.row-fluid select[class*="span"],.row-fluid textarea[class*="span"],.row-fluid .uneditable-input[class*="span"]{float:none;margin-left:0}.input-append input[class*="span"],.input-append .uneditable-input[class*="span"],.input-prepend input[class*="span"],.input-prepend .uneditable-input[class*="span"],.row-fluid .input-prepend [class*="span"],.row-fluid .input-append [class*="span"]{display:inline-block}input,textarea,.uneditable-input{margin-left:0}input.span12,textarea.span12,.uneditable-input.span12{width:930px}input.span11,textarea.span11,.uneditable-input.span11{width:850px}input.span10,textarea.span10,.uneditable-input.span10{width:770px}input.span9,textarea.span9,.uneditable-input.span9{width:690px}input.span8,textarea.span8,.uneditable-input.span8{width:610px}input.span7,textarea.span7,.uneditable-input.span7{width:530px}input.span6,textarea.span6,.uneditable-input.span6{width:450px}input.span5,textarea.span5,.uneditable-input.span5{width:370px}input.span4,textarea.span4,.uneditable-input.span4{width:290px}input.span3,textarea.span3,.uneditable-input.span3{width:210px}input.span2,textarea.span2,.uneditable-input.span2{width:130px}input.span1,textarea.span1,.uneditable-input.span1{width:50px}input[disabled],select[disabled],textarea[disabled],input[readonly],select[readonly],textarea[readonly]{cursor:not-allowed;background-color:#eee;border-color:#ddd}input[type="radio"][disabled],input[type="checkbox"][disabled],input[type="radio"][readonly],input[type="checkbox"][readonly]{background-color:transparent}.control-group.warning>label,.control-group.warning .help-block,.control-group.warning .help-inline{color:#c09853}.control-group.warning .checkbox,.control-group.warning .radio,.control-group.warning input,.control-group.warning select,.control-group.warning textarea{color:#c09853;border-color:#c09853}.control-group.warning .checkbox:focus,.control-group.warning .radio:focus,.control-group.warning input:focus,.control-group.warning select:focus,.control-group.warning textarea:focus{border-color:#a47e3c;-webkit-box-shadow:0 0 6px #dbc59e;-moz-box-shadow:0 0 6px #dbc59e;box-shadow:0 0 6px #dbc59e}.control-group.warning .input-prepend .add-on,.control-group.warning .input-append .add-on{color:#c09853;background-color:#fcf8e3;border-color:#c09853}.control-group.error>label,.control-group.error .help-block,.control-group.error .help-inline{color:#b94a48}.control-group.error .checkbox,.control-group.error .radio,.control-group.error input,.control-group.error select,.control-group.error textarea{color:#b94a48;border-color:#b94a48}.control-group.error .checkbox:focus,.control-group.error .radio:focus,.control-group.error input:focus,.control-group.error select:focus,.control-group.error textarea:focus{border-color:#953b39;-webkit-box-shadow:0 0 6px #d59392;-moz-box-shadow:0 0 6px #d59392;box-shadow:0 0 6px #d59392}.control-group.error .input-prepend .add-on,.control-group.error .input-append .add-on{color:#b94a48;background-color:#f2dede;border-color:#b94a48}.control-group.success>label,.control-group.success .help-block,.control-group.success .help-inline{color:#468847}.control-group.success .checkbox,.control-group.success .radio,.control-group.success input,.control-group.success select,.control-group.success textarea{color:#468847;border-color:#468847}.control-group.success .checkbox:focus,.control-group.success .radio:focus,.control-group.success input:focus,.control-group.success select:focus,.control-group.success textarea:focus{border-color:#356635;-webkit-box-shadow:0 0 6px #7aba7b;-moz-box-shadow:0 0 6px #7aba7b;box-shadow:0 0 6px #7aba7b}.control-group.success .input-prepend .add-on,.control-group.success .input-append .add-on{color:#468847;background-color:#dff0d8;border-color:#468847}input:focus:required:invalid,textarea:focus:required:invalid,select:focus:required:invalid{color:#b94a48;border-color:#ee5f5b}input:focus:required:invalid:focus,textarea:focus:required:invalid:focus,select:focus:required:invalid:focus{border-color:#e9322d;-webkit-box-shadow:0 0 6px #f8b9b7;-moz-box-shadow:0 0 6px #f8b9b7;box-shadow:0 0 6px #f8b9b7}.form-actions{padding:17px 20px 18px;margin-top:18px;margin-bottom:18px;background-color:#f5f5f5;border-top:1px solid #e5e5e5;*zoom:1}.form-actions:before,.form-actions:after{display:table;content:""}.form-actions:after{clear:both}.uneditable-input{overflow:hidden;white-space:nowrap;cursor:not-allowed;background-color:#fff;border-color:#eee;-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,0.025);-moz-box-shadow:inset 0 1px 2px rgba(0,0,0,0.025);box-shadow:inset 0 1px 2px rgba(0,0,0,0.025)}:-moz-placeholder{color:#999}:-ms-input-placeholder{color:#999}::-webkit-input-placeholder{color:#999}.help-block,.help-inline{color:#555}.help-block{display:block;margin-bottom:9px}.help-inline{display:inline-block;*display:inline;*zoom:1;vertical-align:middle;padding-left:5px}.input-prepend,.input-append{margin-bottom:5px}.input-prepend input,.input-append input,.input-prepend select,.input-append select,.input-prepend .uneditable-input,.input-append .uneditable-input{position:relative;margin-bottom:0;*margin-left:0;vertical-align:middle;-webkit-border-radius:0 3px 3px 0;-moz-border-radius:0 3px 3px 0;border-radius:0 3px 3px 0}.input-prepend input:focus,.input-append input:focus,.input-prepend select:focus,.input-append select:focus,.input-prepend .uneditable-input:focus,.input-append .uneditable-input:focus{z-index:2}.input-prepend .uneditable-input,.input-append .uneditable-input{border-left-color:#ccc}.input-prepend .add-on,.input-append .add-on{display:inline-block;width:auto;height:18px;min-width:16px;padding:4px 5px;font-weight:normal;line-height:18px;text-align:center;text-shadow:0 1px 0 #fff;vertical-align:middle;background-color:#eee;border:1px solid #ccc}.input-prepend .add-on,.input-append .add-on,.input-prepend .btn,.input-append .btn{margin-left:-1px;-webkit-border-radius:0;-moz-border-radius:0;border-radius:0}.input-prepend .active,.input-append .active{background-color:#a9dba9;border-color:#46a546}.input-prepend .add-on,.input-prepend .btn{margin-right:-1px}.input-prepend .add-on:first-child,.input-prepend .btn:first-child{-webkit-border-radius:3px 0 0 3px;-moz-border-radius:3px 0 0 3px;border-radius:3px 0 0 3px}.input-append input,.input-append select,.input-append .uneditable-input{-webkit-border-radius:3px 0 0 3px;-moz-border-radius:3px 0 0 3px;border-radius:3px 0 0 3px}.input-append .uneditable-input{border-right-color:#ccc;border-left-color:#eee}.input-append .add-on:last-child,.input-append .btn:last-child{-webkit-border-radius:0 3px 3px 0;-moz-border-radius:0 3px 3px 0;border-radius:0 3px 3px 0}.input-prepend.input-append input,.input-prepend.input-append select,.input-prepend.input-append .uneditable-input{-webkit-border-radius:0;-moz-border-radius:0;border-radius:0}.input-prepend.input-append .add-on:first-child,.input-prepend.input-append .btn:first-child{margin-right:-1px;-webkit-border-radius:3px 0 0 3px;-moz-border-radius:3px 0 0 3px;border-radius:3px 0 0 3px}.input-prepend.input-append .add-on:last-child,.input-prepend.input-append .btn:last-child{margin-left:-1px;-webkit-border-radius:0 3px 3px 0;-moz-border-radius:0 3px 3px 0;border-radius:0 3px 3px 0}.search-query{padding-right:14px;padding-right:4px \9;padding-left:14px;padding-left:4px \9;margin-bottom:0;-webkit-border-radius:14px;-moz-border-radius:14px;border-radius:14px}.form-search input,.form-inline input,.form-horizontal input,.form-search textarea,.form-inline textarea,.form-horizontal textarea,.form-search select,.form-inline select,.form-horizontal select,.form-search .help-inline,.form-inline .help-inline,.form-horizontal .help-inline,.form-search .uneditable-input,.form-inline .uneditable-input,.form-horizontal .uneditable-input,.form-search .input-prepend,.form-inline .input-prepend,.form-horizontal .input-prepend,.form-search .input-append,.form-inline .input-append,.form-horizontal .input-append{display:inline-block;*display:inline;*zoom:1;margin-bottom:0}.form-search .hide,.form-inline .hide,.form-horizontal .hide{display:none}.form-search label,.form-inline label{display:inline-block}.form-search .input-append,.form-inline .input-append,.form-search .input-prepend,.form-inline .input-prepend{margin-bottom:0}.form-search .radio,.form-search .checkbox,.form-inline .radio,.form-inline .checkbox{padding-left:0;margin-bottom:0;vertical-align:middle}.form-search .radio input[type="radio"],.form-search .checkbox input[type="checkbox"],.form-inline .radio input[type="radio"],.form-inline .checkbox input[type="checkbox"]{float:left;margin-right:3px;margin-left:0}.control-group{margin-bottom:9px}legend+.control-group{margin-top:18px;-webkit-margin-top-collapse:separate}.form-horizontal .control-group{margin-bottom:18px;*zoom:1}.form-horizontal .control-group:before,.form-horizontal .control-group:after{display:table;content:""}.form-horizontal .control-group:after{clear:both}.form-horizontal .control-label{float:left;width:140px;padding-top:5px;text-align:right}.form-horizontal .controls{*display:inline-block;*padding-left:20px;margin-left:160px;*margin-left:0}.form-horizontal .controls:first-child{*padding-left:160px}.form-horizontal .help-block{margin-top:9px;margin-bottom:0}.form-horizontal .form-actions{padding-left:160px}table{max-width:100%;background-color:transparent;border-collapse:collapse;border-spacing:0}.table{width:100%;margin-bottom:18px}.table th,.table td{padding:8px;line-height:18px;text-align:left;vertical-align:top;border-top:1px solid #ddd}.table th{font-weight:bold}.table thead th{vertical-align:bottom}.table caption+thead tr:first-child th,.table caption+thead tr:first-child td,.table colgroup+thead tr:first-child th,.table colgroup+thead tr:first-child td,.table thead:first-child tr:first-child th,.table thead:first-child tr:first-child td{border-top:0}.table tbody+tbody{border-top:2px solid #ddd}.table-condensed th,.table-condensed td{padding:4px 5px}.table-bordered{border:1px solid #ddd;border-collapse:separate;*border-collapse:collapsed;border-left:0;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.table-bordered th,.table-bordered td{border-left:1px solid #ddd}.table-bordered caption+thead tr:first-child th,.table-bordered caption+tbody tr:first-child th,.table-bordered caption+tbody tr:first-child td,.table-bordered colgroup+thead tr:first-child th,.table-bordered colgroup+tbody tr:first-child th,.table-bordered colgroup+tbody tr:first-child td,.table-bordered thead:first-child tr:first-child th,.table-bordered tbody:first-child tr:first-child th,.table-bordered tbody:first-child tr:first-child td{border-top:0}.table-bordered thead:first-child tr:first-child th:first-child,.table-bordered tbody:first-child tr:first-child td:first-child{-webkit-border-top-left-radius:4px;border-top-left-radius:4px;-moz-border-radius-topleft:4px}.table-bordered thead:first-child tr:first-child th:last-child,.table-bordered tbody:first-child tr:first-child td:last-child{-webkit-border-top-right-radius:4px;border-top-right-radius:4px;-moz-border-radius-topright:4px}.table-bordered thead:last-child tr:last-child th:first-child,.table-bordered tbody:last-child tr:last-child td:first-child{-webkit-border-radius:0 0 0 4px;-moz-border-radius:0 0 0 4px;border-radius:0 0 0 4px;-webkit-border-bottom-left-radius:4px;border-bottom-left-radius:4px;-moz-border-radius-bottomleft:4px}.table-bordered thead:last-child tr:last-child th:last-child,.table-bordered tbody:last-child tr:last-child td:last-child{-webkit-border-bottom-right-radius:4px;border-bottom-right-radius:4px;-moz-border-radius-bottomright:4px}.table-striped tbody tr:nth-child(odd) td,.table-striped tbody tr:nth-child(odd) th{background-color:#f9f9f9}.table tbody tr:hover td,.table tbody tr:hover th{background-color:#f5f5f5}table .span1{float:none;width:44px;margin-left:0}table .span2{float:none;width:124px;margin-left:0}table .span3{float:none;width:204px;margin-left:0}table .span4{float:none;width:284px;margin-left:0}table .span5{float:none;width:364px;margin-left:0}table .span6{float:none;width:444px;margin-left:0}table .span7{float:none;width:524px;margin-left:0}table .span8{float:none;width:604px;margin-left:0}table .span9{float:none;width:684px;margin-left:0}table .span10{float:none;width:764px;margin-left:0}table .span11{float:none;width:844px;margin-left:0}table .span12{float:none;width:924px;margin-left:0}table .span13{float:none;width:1004px;margin-left:0}table .span14{float:none;width:1084px;margin-left:0}table .span15{float:none;width:1164px;margin-left:0}table .span16{float:none;width:1244px;margin-left:0}table .span17{float:none;width:1324px;margin-left:0}table .span18{float:none;width:1404px;margin-left:0}table .span19{float:none;width:1484px;margin-left:0}table .span20{float:none;width:1564px;margin-left:0}table .span21{float:none;width:1644px;margin-left:0}table .span22{float:none;width:1724px;margin-left:0}table .span23{float:none;width:1804px;margin-left:0}table .span24{float:none;width:1884px;margin-left:0}[class^="icon-"],[class*=" icon-"]{display:inline-block;width:14px;height:14px;*margin-right:.3em;line-height:14px;vertical-align:text-top;background-image:url("../img/glyphicons-halflings.png");background-position:14px 14px;background-repeat:no-repeat}[class^="icon-"]:last-child,[class*=" icon-"]:last-child{*margin-left:0}.icon-white{background-image:url("../img/glyphicons-halflings-white.png")}.icon-glass{background-position:0 0}.icon-music{background-position:-24px 0}.icon-search{background-position:-48px 0}.icon-envelope{background-position:-72px 0}.icon-heart{background-position:-96px 0}.icon-star{background-position:-120px 0}.icon-star-empty{background-position:-144px 0}.icon-user{background-position:-168px 0}.icon-film{background-position:-192px 0}.icon-th-large{background-position:-216px 0}.icon-th{background-position:-240px 0}.icon-th-list{background-position:-264px 0}.icon-ok{background-position:-288px 0}.icon-remove{background-position:-312px 0}.icon-zoom-in{background-position:-336px 0}.icon-zoom-out{background-position:-360px 0}.icon-off{background-position:-384px 0}.icon-signal{background-position:-408px 0}.icon-cog{background-position:-432px 0}.icon-trash{background-position:-456px 0}.icon-home{background-position:0 -24px}.icon-file{background-position:-24px -24px}.icon-time{background-position:-48px -24px}.icon-road{background-position:-72px -24px}.icon-download-alt{background-position:-96px -24px}.icon-download{background-position:-120px -24px}.icon-upload{background-position:-144px -24px}.icon-inbox{background-position:-168px -24px}.icon-play-circle{background-position:-192px -24px}.icon-repeat{background-position:-216px -24px}.icon-refresh{background-position:-240px -24px}.icon-list-alt{background-position:-264px -24px}.icon-lock{background-position:-287px -24px}.icon-flag{background-position:-312px -24px}.icon-headphones{background-position:-336px -24px}.icon-volume-off{background-position:-360px -24px}.icon-volume-down{background-position:-384px -24px}.icon-volume-up{background-position:-408px -24px}.icon-qrcode{background-position:-432px -24px}.icon-barcode{background-position:-456px -24px}.icon-tag{background-position:0 -48px}.icon-tags{background-position:-25px -48px}.icon-book{background-position:-48px -48px}.icon-bookmark{background-position:-72px -48px}.icon-print{background-position:-96px -48px}.icon-camera{background-position:-120px -48px}.icon-font{background-position:-144px -48px}.icon-bold{background-position:-167px -48px}.icon-italic{background-position:-192px -48px}.icon-text-height{background-position:-216px -48px}.icon-text-width{background-position:-240px -48px}.icon-align-left{background-position:-264px -48px}.icon-align-center{background-position:-288px -48px}.icon-align-right{background-position:-312px -48px}.icon-align-justify{background-position:-336px -48px}.icon-list{background-position:-360px -48px}.icon-indent-left{background-position:-384px -48px}.icon-indent-right{background-position:-408px -48px}.icon-facetime-video{background-position:-432px -48px}.icon-picture{background-position:-456px -48px}.icon-pencil{background-position:0 -72px}.icon-map-marker{background-position:-24px -72px}.icon-adjust{background-position:-48px -72px}.icon-tint{background-position:-72px -72px}.icon-edit{background-position:-96px -72px}.icon-share{background-position:-120px -72px}.icon-check{background-position:-144px -72px}.icon-move{background-position:-168px -72px}.icon-step-backward{background-position:-192px -72px}.icon-fast-backward{background-position:-216px -72px}.icon-backward{background-position:-240px -72px}.icon-play{background-position:-264px -72px}.icon-pause{background-position:-288px -72px}.icon-stop{background-position:-312px -72px}.icon-forward{background-position:-336px -72px}.icon-fast-forward{background-position:-360px -72px}.icon-step-forward{background-position:-384px -72px}.icon-eject{background-position:-408px -72px}.icon-chevron-left{background-position:-432px -72px}.icon-chevron-right{background-position:-456px -72px}.icon-plus-sign{background-position:0 -96px}.icon-minus-sign{background-position:-24px -96px}.icon-remove-sign{background-position:-48px -96px}.icon-ok-sign{background-position:-72px -96px}.icon-question-sign{background-position:-96px -96px}.icon-info-sign{background-position:-120px -96px}.icon-screenshot{background-position:-144px -96px}.icon-remove-circle{background-position:-168px -96px}.icon-ok-circle{background-position:-192px -96px}.icon-ban-circle{background-position:-216px -96px}.icon-arrow-left{background-position:-240px -96px}.icon-arrow-right{background-position:-264px -96px}.icon-arrow-up{background-position:-289px -96px}.icon-arrow-down{background-position:-312px -96px}.icon-share-alt{background-position:-336px -96px}.icon-resize-full{background-position:-360px -96px}.icon-resize-small{background-position:-384px -96px}.icon-plus{background-position:-408px -96px}.icon-minus{background-position:-433px -96px}.icon-asterisk{background-position:-456px -96px}.icon-exclamation-sign{background-position:0 -120px}.icon-gift{background-position:-24px -120px}.icon-leaf{background-position:-48px -120px}.icon-fire{background-position:-72px -120px}.icon-eye-open{background-position:-96px -120px}.icon-eye-close{background-position:-120px -120px}.icon-warning-sign{background-position:-144px -120px}.icon-plane{background-position:-168px -120px}.icon-calendar{background-position:-192px -120px}.icon-random{background-position:-216px -120px}.icon-comment{background-position:-240px -120px}.icon-magnet{background-position:-264px -120px}.icon-chevron-up{background-position:-288px -120px}.icon-chevron-down{background-position:-313px -119px}.icon-retweet{background-position:-336px -120px}.icon-shopping-cart{background-position:-360px -120px}.icon-folder-close{background-position:-384px -120px}.icon-folder-open{background-position:-408px -120px}.icon-resize-vertical{background-position:-432px -119px}.icon-resize-horizontal{background-position:-456px -118px}.icon-hdd{background-position:0 -144px}.icon-bullhorn{background-position:-24px -144px}.icon-bell{background-position:-48px -144px}.icon-certificate{background-position:-72px -144px}.icon-thumbs-up{background-position:-96px -144px}.icon-thumbs-down{background-position:-120px -144px}.icon-hand-right{background-position:-144px -144px}.icon-hand-left{background-position:-168px -144px}.icon-hand-up{background-position:-192px -144px}.icon-hand-down{background-position:-216px -144px}.icon-circle-arrow-right{background-position:-240px -144px}.icon-circle-arrow-left{background-position:-264px -144px}.icon-circle-arrow-up{background-position:-288px -144px}.icon-circle-arrow-down{background-position:-312px -144px}.icon-globe{background-position:-336px -144px}.icon-wrench{background-position:-360px -144px}.icon-tasks{background-position:-384px -144px}.icon-filter{background-position:-408px -144px}.icon-briefcase{background-position:-432px -144px}.icon-fullscreen{background-position:-456px -144px}.dropup,.dropdown{position:relative}.dropdown-toggle{*margin-bottom:-3px}.dropdown-toggle:active,.open .dropdown-toggle{outline:0}.caret{display:inline-block;width:0;height:0;vertical-align:top;border-top:4px solid #000;border-right:4px solid transparent;border-left:4px solid transparent;content:"";opacity:.3;filter:alpha(opacity=30)}.dropdown .caret{margin-top:8px;margin-left:2px}.dropdown:hover .caret,.open .caret{opacity:1;filter:alpha(opacity=100)}.dropdown-menu{position:absolute;top:100%;left:0;z-index:1000;display:none;float:left;min-width:160px;padding:4px 0;margin:1px 0 0;list-style:none;background-color:#fff;border:1px solid #ccc;border:1px solid rgba(0,0,0,0.2);*border-right-width:2px;*border-bottom-width:2px;-webkit-border-radius:5px;-moz-border-radius:5px;border-radius:5px;-webkit-box-shadow:0 5px 10px rgba(0,0,0,0.2);-moz-box-shadow:0 5px 10px rgba(0,0,0,0.2);box-shadow:0 5px 10px rgba(0,0,0,0.2);-webkit-background-clip:padding-box;-moz-background-clip:padding;background-clip:padding-box}.dropdown-menu.pull-right{right:0;left:auto}.dropdown-menu .divider{*width:100%;height:1px;margin:8px 1px;*margin:-5px 0 5px;overflow:hidden;background-color:#e5e5e5;border-bottom:1px solid #fff}.dropdown-menu a{display:block;padding:3px 15px;clear:both;font-weight:normal;line-height:18px;color:#333;white-space:nowrap}.dropdown-menu li>a:hover,.dropdown-menu .active>a,.dropdown-menu .active>a:hover{color:#fff;text-decoration:none;background-color:#08c}.open{*z-index:1000}.open>.dropdown-menu{display:block}.pull-right>.dropdown-menu{right:0;left:auto}.dropup .caret,.navbar-fixed-bottom .dropdown .caret{border-top:0;border-bottom:4px solid #000;content:"\2191"}.dropup .dropdown-menu,.navbar-fixed-bottom .dropdown .dropdown-menu{top:auto;bottom:100%;margin-bottom:1px}.typeahead{margin-top:2px;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.well{min-height:20px;padding:19px;margin-bottom:20px;background-color:#f5f5f5;border:1px solid #eee;border:1px solid rgba(0,0,0,0.05);-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.05);-moz-box-shadow:inset 0 1px 1px rgba(0,0,0,0.05);box-shadow:inset 0 1px 1px rgba(0,0,0,0.05)}.well blockquote{border-color:#ddd;border-color:rgba(0,0,0,0.15)}.well-large{padding:24px;-webkit-border-radius:6px;-moz-border-radius:6px;border-radius:6px}.well-small{padding:9px;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px}.fade{opacity:0;-webkit-transition:opacity .15s linear;-moz-transition:opacity .15s linear;-ms-transition:opacity .15s linear;-o-transition:opacity .15s linear;transition:opacity .15s linear}.fade.in{opacity:1}.collapse{position:relative;height:0;overflow:hidden;-webkit-transition:height .35s ease;-moz-transition:height .35s ease;-ms-transition:height .35s ease;-o-transition:height .35s ease;transition:height .35s ease}.collapse.in{height:auto}.close{float:right;font-size:20px;font-weight:bold;line-height:18px;color:#000;text-shadow:0 1px 0 #fff;opacity:.2;filter:alpha(opacity=20)}.close:hover{color:#000;text-decoration:none;cursor:pointer;opacity:.4;filter:alpha(opacity=40)}button.close{padding:0;cursor:pointer;background:transparent;border:0;-webkit-appearance:none}.btn{display:inline-block;*display:inline;*zoom:1;padding:4px 10px 4px;margin-bottom:0;font-size:13px;line-height:18px;*line-height:20px;color:#333;text-align:center;text-shadow:0 1px 1px rgba(255,255,255,0.75);vertical-align:middle;cursor:pointer;background-color:#f5f5f5;background-image:-moz-linear-gradient(top,#fff,#e6e6e6);background-image:-ms-linear-gradient(top,#fff,#e6e6e6);background-image:-webkit-gradient(linear,0 0,0 100%,from(#fff),to(#e6e6e6));background-image:-webkit-linear-gradient(top,#fff,#e6e6e6);background-image:-o-linear-gradient(top,#fff,#e6e6e6);background-image:linear-gradient(top,#fff,#e6e6e6);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff',endColorstr='#e6e6e6',GradientType=0);border-color:#e6e6e6 #e6e6e6 #bfbfbf;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#e6e6e6;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);border:1px solid #ccc;*border:0;border-bottom-color:#b3b3b3;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;*margin-left:.3em;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05);-moz-box-shadow:inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05);box-shadow:inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05)}.btn:hover,.btn:active,.btn.active,.btn.disabled,.btn[disabled]{background-color:#e6e6e6;*background-color:#d9d9d9}.btn:active,.btn.active{background-color:#ccc \9}.btn:first-child{*margin-left:0}.btn:hover{color:#333;text-decoration:none;background-color:#e6e6e6;*background-color:#d9d9d9;background-position:0 -15px;-webkit-transition:background-position .1s linear;-moz-transition:background-position .1s linear;-ms-transition:background-position .1s linear;-o-transition:background-position .1s linear;transition:background-position .1s linear}.btn:focus{outline:thin dotted #333;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.btn.active,.btn:active{background-color:#e6e6e6;background-color:#d9d9d9 \9;background-image:none;outline:0;-webkit-box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05);-moz-box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05);box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05)}.btn.disabled,.btn[disabled]{cursor:default;background-color:#e6e6e6;background-image:none;opacity:.65;filter:alpha(opacity=65);-webkit-box-shadow:none;-moz-box-shadow:none;box-shadow:none}.btn-large{padding:9px 14px;font-size:15px;line-height:normal;-webkit-border-radius:5px;-moz-border-radius:5px;border-radius:5px}.btn-large [class^="icon-"]{margin-top:1px}.btn-small{padding:5px 9px;font-size:11px;line-height:16px}.btn-small [class^="icon-"]{margin-top:-1px}.btn-mini{padding:2px 6px;font-size:11px;line-height:14px}.btn-primary,.btn-primary:hover,.btn-warning,.btn-warning:hover,.btn-danger,.btn-danger:hover,.btn-success,.btn-success:hover,.btn-info,.btn-info:hover,.btn-inverse,.btn-inverse:hover{color:#fff;text-shadow:0 -1px 0 rgba(0,0,0,0.25)}.btn-primary.active,.btn-warning.active,.btn-danger.active,.btn-success.active,.btn-info.active,.btn-inverse.active{color:rgba(255,255,255,0.75)}.btn{border-color:#ccc;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25)}.btn-primary{background-color:#0074cc;background-image:-moz-linear-gradient(top,#08c,#05c);background-image:-ms-linear-gradient(top,#08c,#05c);background-image:-webkit-gradient(linear,0 0,0 100%,from(#08c),to(#05c));background-image:-webkit-linear-gradient(top,#08c,#05c);background-image:-o-linear-gradient(top,#08c,#05c);background-image:linear-gradient(top,#08c,#05c);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#0088cc',endColorstr='#0055cc',GradientType=0);border-color:#05c #05c #003580;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#05c;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-primary:hover,.btn-primary:active,.btn-primary.active,.btn-primary.disabled,.btn-primary[disabled]{background-color:#05c;*background-color:#004ab3}.btn-primary:active,.btn-primary.active{background-color:#004099 \9}.btn-warning{background-color:#faa732;background-image:-moz-linear-gradient(top,#fbb450,#f89406);background-image:-ms-linear-gradient(top,#fbb450,#f89406);background-image:-webkit-gradient(linear,0 0,0 100%,from(#fbb450),to(#f89406));background-image:-webkit-linear-gradient(top,#fbb450,#f89406);background-image:-o-linear-gradient(top,#fbb450,#f89406);background-image:linear-gradient(top,#fbb450,#f89406);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#fbb450',endColorstr='#f89406',GradientType=0);border-color:#f89406 #f89406 #ad6704;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#f89406;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-warning:hover,.btn-warning:active,.btn-warning.active,.btn-warning.disabled,.btn-warning[disabled]{background-color:#f89406;*background-color:#df8505}.btn-warning:active,.btn-warning.active{background-color:#c67605 \9}.btn-danger{background-color:#da4f49;background-image:-moz-linear-gradient(top,#ee5f5b,#bd362f);background-image:-ms-linear-gradient(top,#ee5f5b,#bd362f);background-image:-webkit-gradient(linear,0 0,0 100%,from(#ee5f5b),to(#bd362f));background-image:-webkit-linear-gradient(top,#ee5f5b,#bd362f);background-image:-o-linear-gradient(top,#ee5f5b,#bd362f);background-image:linear-gradient(top,#ee5f5b,#bd362f);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ee5f5b',endColorstr='#bd362f',GradientType=0);border-color:#bd362f #bd362f #802420;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#bd362f;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-danger:hover,.btn-danger:active,.btn-danger.active,.btn-danger.disabled,.btn-danger[disabled]{background-color:#bd362f;*background-color:#a9302a}.btn-danger:active,.btn-danger.active{background-color:#942a25 \9}.btn-success{background-color:#5bb75b;background-image:-moz-linear-gradient(top,#62c462,#51a351);background-image:-ms-linear-gradient(top,#62c462,#51a351);background-image:-webkit-gradient(linear,0 0,0 100%,from(#62c462),to(#51a351));background-image:-webkit-linear-gradient(top,#62c462,#51a351);background-image:-o-linear-gradient(top,#62c462,#51a351);background-image:linear-gradient(top,#62c462,#51a351);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#62c462',endColorstr='#51a351',GradientType=0);border-color:#51a351 #51a351 #387038;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#51a351;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-success:hover,.btn-success:active,.btn-success.active,.btn-success.disabled,.btn-success[disabled]{background-color:#51a351;*background-color:#499249}.btn-success:active,.btn-success.active{background-color:#408140 \9}.btn-info{background-color:#49afcd;background-image:-moz-linear-gradient(top,#5bc0de,#2f96b4);background-image:-ms-linear-gradient(top,#5bc0de,#2f96b4);background-image:-webkit-gradient(linear,0 0,0 100%,from(#5bc0de),to(#2f96b4));background-image:-webkit-linear-gradient(top,#5bc0de,#2f96b4);background-image:-o-linear-gradient(top,#5bc0de,#2f96b4);background-image:linear-gradient(top,#5bc0de,#2f96b4);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#5bc0de',endColorstr='#2f96b4',GradientType=0);border-color:#2f96b4 #2f96b4 #1f6377;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#2f96b4;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-info:hover,.btn-info:active,.btn-info.active,.btn-info.disabled,.btn-info[disabled]{background-color:#2f96b4;*background-color:#2a85a0}.btn-info:active,.btn-info.active{background-color:#24748c \9}.btn-inverse{background-color:#414141;background-image:-moz-linear-gradient(top,#555,#222);background-image:-ms-linear-gradient(top,#555,#222);background-image:-webkit-gradient(linear,0 0,0 100%,from(#555),to(#222));background-image:-webkit-linear-gradient(top,#555,#222);background-image:-o-linear-gradient(top,#555,#222);background-image:linear-gradient(top,#555,#222);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#555555',endColorstr='#222222',GradientType=0);border-color:#222 #222 #000;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#222;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false)}.btn-inverse:hover,.btn-inverse:active,.btn-inverse.active,.btn-inverse.disabled,.btn-inverse[disabled]{background-color:#222;*background-color:#151515}.btn-inverse:active,.btn-inverse.active{background-color:#080808 \9}button.btn,input[type="submit"].btn{*padding-top:2px;*padding-bottom:2px}button.btn::-moz-focus-inner,input[type="submit"].btn::-moz-focus-inner{padding:0;border:0}button.btn.btn-large,input[type="submit"].btn.btn-large{*padding-top:7px;*padding-bottom:7px}button.btn.btn-small,input[type="submit"].btn.btn-small{*padding-top:3px;*padding-bottom:3px}button.btn.btn-mini,input[type="submit"].btn.btn-mini{*padding-top:1px;*padding-bottom:1px}.btn-group{position:relative;*zoom:1;*margin-left:.3em}.btn-group:before,.btn-group:after{display:table;content:""}.btn-group:after{clear:both}.btn-group:first-child{*margin-left:0}.btn-group+.btn-group{margin-left:5px}.btn-toolbar{margin-top:9px;margin-bottom:9px}.btn-toolbar .btn-group{display:inline-block;*display:inline;*zoom:1}.btn-group>.btn{position:relative;float:left;margin-left:-1px;-webkit-border-radius:0;-moz-border-radius:0;border-radius:0}.btn-group>.btn:first-child{margin-left:0;-webkit-border-top-left-radius:4px;-moz-border-radius-topleft:4px;border-top-left-radius:4px;-webkit-border-bottom-left-radius:4px;-moz-border-radius-bottomleft:4px;border-bottom-left-radius:4px}.btn-group>.btn:last-child,.btn-group>.dropdown-toggle{-webkit-border-top-right-radius:4px;-moz-border-radius-topright:4px;border-top-right-radius:4px;-webkit-border-bottom-right-radius:4px;-moz-border-radius-bottomright:4px;border-bottom-right-radius:4px}.btn-group>.btn.large:first-child{margin-left:0;-webkit-border-top-left-radius:6px;-moz-border-radius-topleft:6px;border-top-left-radius:6px;-webkit-border-bottom-left-radius:6px;-moz-border-radius-bottomleft:6px;border-bottom-left-radius:6px}.btn-group>.btn.large:last-child,.btn-group>.large.dropdown-toggle{-webkit-border-top-right-radius:6px;-moz-border-radius-topright:6px;border-top-right-radius:6px;-webkit-border-bottom-right-radius:6px;-moz-border-radius-bottomright:6px;border-bottom-right-radius:6px}.btn-group>.btn:hover,.btn-group>.btn:focus,.btn-group>.btn:active,.btn-group>.btn.active{z-index:2}.btn-group .dropdown-toggle:active,.btn-group.open .dropdown-toggle{outline:0}.btn-group>.dropdown-toggle{padding-left:8px;padding-right:8px;-webkit-box-shadow:inset 1px 0 0 rgba(255,255,255,.125),inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05);-moz-box-shadow:inset 1px 0 0 rgba(255,255,255,.125),inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05);box-shadow:inset 1px 0 0 rgba(255,255,255,.125),inset 0 1px 0 rgba(255,255,255,.2),0 1px 2px rgba(0,0,0,.05);*padding-top:4px;*padding-bottom:4px}.btn-group>.btn-mini.dropdown-toggle{padding-left:5px;padding-right:5px}.btn-group>.btn-small.dropdown-toggle{*padding-top:4px;*padding-bottom:4px}.btn-group>.btn-large.dropdown-toggle{padding-left:12px;padding-right:12px}.btn-group.open .dropdown-toggle{background-image:none;-webkit-box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05);-moz-box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05);box-shadow:inset 0 2px 4px rgba(0,0,0,.15),0 1px 2px rgba(0,0,0,.05)}.btn-group.open .btn.dropdown-toggle{background-color:#e6e6e6}.btn-group.open .btn-primary.dropdown-toggle{background-color:#05c}.btn-group.open .btn-warning.dropdown-toggle{background-color:#f89406}.btn-group.open .btn-danger.dropdown-toggle{background-color:#bd362f}.btn-group.open .btn-success.dropdown-toggle{background-color:#51a351}.btn-group.open .btn-info.dropdown-toggle{background-color:#2f96b4}.btn-group.open .btn-inverse.dropdown-toggle{background-color:#222}.btn .caret{margin-top:7px;margin-left:0}.btn:hover .caret,.open.btn-group .caret{opacity:1;filter:alpha(opacity=100)}.btn-mini .caret{margin-top:5px}.btn-small .caret{margin-top:6px}.btn-large .caret{margin-top:6px;border-left-width:5px;border-right-width:5px;border-top-width:5px}.dropup .btn-large .caret{border-bottom:5px solid #000;border-top:0}.btn-primary .caret,.btn-warning .caret,.btn-danger .caret,.btn-info .caret,.btn-success .caret,.btn-inverse .caret{border-top-color:#fff;border-bottom-color:#fff;opacity:.75;filter:alpha(opacity=75)}.alert{padding:8px 35px 8px 14px;margin-bottom:18px;text-shadow:0 1px 0 rgba(255,255,255,0.5);background-color:#fcf8e3;border:1px solid #fbeed5;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;color:#c09853}.alert-heading{color:inherit}.alert .close{position:relative;top:-2px;right:-21px;line-height:18px}.alert-success{background-color:#dff0d8;border-color:#d6e9c6;color:#468847}.alert-danger,.alert-error{background-color:#f2dede;border-color:#eed3d7;color:#b94a48}.alert-info{background-color:#d9edf7;border-color:#bce8f1;color:#3a87ad}.alert-block{padding-top:14px;padding-bottom:14px}.alert-block>p,.alert-block>ul{margin-bottom:0}.alert-block p+p{margin-top:5px}.nav{margin-left:0;margin-bottom:18px;list-style:none}.nav>li>a{display:block}.nav>li>a:hover{text-decoration:none;background-color:#eee}.nav>.pull-right{float:right}.nav .nav-header{display:block;padding:3px 15px;font-size:11px;font-weight:bold;line-height:18px;color:#999;text-shadow:0 1px 0 rgba(255,255,255,0.5);text-transform:uppercase}.nav li+.nav-header{margin-top:9px}.nav-list{padding-left:15px;padding-right:15px;margin-bottom:0}.nav-list>li>a,.nav-list .nav-header{margin-left:-15px;margin-right:-15px;text-shadow:0 1px 0 rgba(255,255,255,0.5)}.nav-list>li>a{padding:3px 15px}.nav-list>.active>a,.nav-list>.active>a:hover{color:#fff;text-shadow:0 -1px 0 rgba(0,0,0,0.2);background-color:#08c}.nav-list [class^="icon-"]{margin-right:2px}.nav-list .divider{*width:100%;height:1px;margin:8px 1px;*margin:-5px 0 5px;overflow:hidden;background-color:#e5e5e5;border-bottom:1px solid #fff}.nav-tabs,.nav-pills{*zoom:1}.nav-tabs:before,.nav-pills:before,.nav-tabs:after,.nav-pills:after{display:table;content:""}.nav-tabs:after,.nav-pills:after{clear:both}.nav-tabs>li,.nav-pills>li{float:left}.nav-tabs>li>a,.nav-pills>li>a{padding-right:12px;padding-left:12px;margin-right:2px;line-height:14px}.nav-tabs{border-bottom:1px solid #ddd}.nav-tabs>li{margin-bottom:-1px}.nav-tabs>li>a{padding-top:8px;padding-bottom:8px;line-height:18px;border:1px solid transparent;-webkit-border-radius:4px 4px 0 0;-moz-border-radius:4px 4px 0 0;border-radius:4px 4px 0 0}.nav-tabs>li>a:hover{border-color:#eee #eee #ddd}.nav-tabs>.active>a,.nav-tabs>.active>a:hover{color:#555;background-color:#fff;border:1px solid #ddd;border-bottom-color:transparent;cursor:default}.nav-pills>li>a{padding-top:8px;padding-bottom:8px;margin-top:2px;margin-bottom:2px;-webkit-border-radius:5px;-moz-border-radius:5px;border-radius:5px}.nav-pills>.active>a,.nav-pills>.active>a:hover{color:#fff;background-color:#08c}.nav-stacked>li{float:none}.nav-stacked>li>a{margin-right:0}.nav-tabs.nav-stacked{border-bottom:0}.nav-tabs.nav-stacked>li>a{border:1px solid #ddd;-webkit-border-radius:0;-moz-border-radius:0;border-radius:0}.nav-tabs.nav-stacked>li:first-child>a{-webkit-border-radius:4px 4px 0 0;-moz-border-radius:4px 4px 0 0;border-radius:4px 4px 0 0}.nav-tabs.nav-stacked>li:last-child>a{-webkit-border-radius:0 0 4px 4px;-moz-border-radius:0 0 4px 4px;border-radius:0 0 4px 4px}.nav-tabs.nav-stacked>li>a:hover{border-color:#ddd;z-index:2}.nav-pills.nav-stacked>li>a{margin-bottom:3px}.nav-pills.nav-stacked>li:last-child>a{margin-bottom:1px}.nav-tabs .dropdown-menu{-webkit-border-radius:0 0 5px 5px;-moz-border-radius:0 0 5px 5px;border-radius:0 0 5px 5px}.nav-pills .dropdown-menu{-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.nav-tabs .dropdown-toggle .caret,.nav-pills .dropdown-toggle .caret{border-top-color:#08c;border-bottom-color:#08c;margin-top:6px}.nav-tabs .dropdown-toggle:hover .caret,.nav-pills .dropdown-toggle:hover .caret{border-top-color:#005580;border-bottom-color:#005580}.nav-tabs .active .dropdown-toggle .caret,.nav-pills .active .dropdown-toggle .caret{border-top-color:#333;border-bottom-color:#333}.nav>.dropdown.active>a:hover{color:#000;cursor:pointer}.nav-tabs .open .dropdown-toggle,.nav-pills .open .dropdown-toggle,.nav>li.dropdown.open.active>a:hover{color:#fff;background-color:#999;border-color:#999}.nav li.dropdown.open .caret,.nav li.dropdown.open.active .caret,.nav li.dropdown.open a:hover .caret{border-top-color:#fff;border-bottom-color:#fff;opacity:1;filter:alpha(opacity=100)}.tabs-stacked .open>a:hover{border-color:#999}.tabbable{*zoom:1}.tabbable:before,.tabbable:after{display:table;content:""}.tabbable:after{clear:both}.tab-content{overflow:auto}.tabs-below>.nav-tabs,.tabs-right>.nav-tabs,.tabs-left>.nav-tabs{border-bottom:0}.tab-content>.tab-pane,.pill-content>.pill-pane{display:none}.tab-content>.active,.pill-content>.active{display:block}.tabs-below>.nav-tabs{border-top:1px solid #ddd}.tabs-below>.nav-tabs>li{margin-top:-1px;margin-bottom:0}.tabs-below>.nav-tabs>li>a{-webkit-border-radius:0 0 4px 4px;-moz-border-radius:0 0 4px 4px;border-radius:0 0 4px 4px}.tabs-below>.nav-tabs>li>a:hover{border-bottom-color:transparent;border-top-color:#ddd}.tabs-below>.nav-tabs>.active>a,.tabs-below>.nav-tabs>.active>a:hover{border-color:transparent #ddd #ddd #ddd}.tabs-left>.nav-tabs>li,.tabs-right>.nav-tabs>li{float:none}.tabs-left>.nav-tabs>li>a,.tabs-right>.nav-tabs>li>a{min-width:74px;margin-right:0;margin-bottom:3px}.tabs-left>.nav-tabs{float:left;margin-right:19px;border-right:1px solid #ddd}.tabs-left>.nav-tabs>li>a{margin-right:-1px;-webkit-border-radius:4px 0 0 4px;-moz-border-radius:4px 0 0 4px;border-radius:4px 0 0 4px}.tabs-left>.nav-tabs>li>a:hover{border-color:#eee #ddd #eee #eee}.tabs-left>.nav-tabs .active>a,.tabs-left>.nav-tabs .active>a:hover{border-color:#ddd transparent #ddd #ddd;*border-right-color:#fff}.tabs-right>.nav-tabs{float:right;margin-left:19px;border-left:1px solid #ddd}.tabs-right>.nav-tabs>li>a{margin-left:-1px;-webkit-border-radius:0 4px 4px 0;-moz-border-radius:0 4px 4px 0;border-radius:0 4px 4px 0}.tabs-right>.nav-tabs>li>a:hover{border-color:#eee #eee #eee #ddd}.tabs-right>.nav-tabs .active>a,.tabs-right>.nav-tabs .active>a:hover{border-color:#ddd #ddd #ddd transparent;*border-left-color:#fff}.navbar{*position:relative;*z-index:2;overflow:visible;margin-bottom:18px}.navbar-inner{min-height:40px;padding-left:20px;padding-right:20px;background-color:#2c2c2c;background-image:-moz-linear-gradient(top,#333,#222);background-image:-ms-linear-gradient(top,#333,#222);background-image:-webkit-gradient(linear,0 0,0 100%,from(#333),to(#222));background-image:-webkit-linear-gradient(top,#333,#222);background-image:-o-linear-gradient(top,#333,#222);background-image:linear-gradient(top,#333,#222);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333',endColorstr='#222222',GradientType=0);-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,.25),inset 0 -1px 0 rgba(0,0,0,.1);-moz-box-shadow:0 1px 3px rgba(0,0,0,.25),inset 0 -1px 0 rgba(0,0,0,.1);box-shadow:0 1px 3px rgba(0,0,0,.25),inset 0 -1px 0 rgba(0,0,0,.1)}.navbar .container{width:auto}.nav-collapse.collapse{height:auto}.navbar{color:#999}.navbar .brand:hover{text-decoration:none}.navbar .brand{float:left;display:block;padding:8px 20px 12px;margin-left:-20px;font-size:20px;font-weight:200;line-height:1;color:#999}.navbar .navbar-text{margin-bottom:0;line-height:40px}.navbar .navbar-link{color:#999}.navbar .navbar-link:hover{color:#fff}.navbar .btn,.navbar .btn-group{margin-top:5px}.navbar .btn-group .btn{margin:0}.navbar-form{margin-bottom:0;*zoom:1}.navbar-form:before,.navbar-form:after{display:table;content:""}.navbar-form:after{clear:both}.navbar-form input,.navbar-form select,.navbar-form .radio,.navbar-form .checkbox{margin-top:5px}.navbar-form input,.navbar-form select{display:inline-block;margin-bottom:0}.navbar-form input[type="image"],.navbar-form input[type="checkbox"],.navbar-form input[type="radio"]{margin-top:3px}.navbar-form .input-append,.navbar-form .input-prepend{margin-top:6px;white-space:nowrap}.navbar-form .input-append input,.navbar-form .input-prepend input{margin-top:0}.navbar-search{position:relative;float:left;margin-top:6px;margin-bottom:0}.navbar-search .search-query{padding:4px 9px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:13px;font-weight:normal;line-height:1;color:#fff;background-color:#626262;border:1px solid #151515;-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,.1),0 1px 0 rgba(255,255,255,.15);-moz-box-shadow:inset 0 1px 2px rgba(0,0,0,.1),0 1px 0 rgba(255,255,255,.15);box-shadow:inset 0 1px 2px rgba(0,0,0,.1),0 1px 0 rgba(255,255,255,.15);-webkit-transition:none;-moz-transition:none;-ms-transition:none;-o-transition:none;transition:none}.navbar-search .search-query:-moz-placeholder{color:#ccc}.navbar-search .search-query:-ms-input-placeholder{color:#ccc}.navbar-search .search-query::-webkit-input-placeholder{color:#ccc}.navbar-search .search-query:focus,.navbar-search .search-query.focused{padding:5px 10px;color:#333;text-shadow:0 1px 0 #fff;background-color:#fff;border:0;-webkit-box-shadow:0 0 3px rgba(0,0,0,0.15);-moz-box-shadow:0 0 3px rgba(0,0,0,0.15);box-shadow:0 0 3px rgba(0,0,0,0.15);outline:0}.navbar-fixed-top,.navbar-fixed-bottom{position:fixed;right:0;left:0;z-index:1030;margin-bottom:0}.navbar-fixed-top .navbar-inner,.navbar-fixed-bottom .navbar-inner{padding-left:0;padding-right:0;-webkit-border-radius:0;-moz-border-radius:0;border-radius:0}.navbar-fixed-top .container,.navbar-fixed-bottom .container{width:940px}.navbar-fixed-top{top:0}.navbar-fixed-bottom{bottom:0}.navbar .nav{position:relative;left:0;display:block;float:left;margin:0 10px 0 0}.navbar .nav.pull-right{float:right}.navbar .nav>li{display:block;float:left}.navbar .nav>li>a{float:none;padding:9px 10px 11px;line-height:19px;color:#999;text-decoration:none;text-shadow:0 -1px 0 rgba(0,0,0,0.25)}.navbar .btn{display:inline-block;padding:4px 10px 4px;margin:5px 5px 6px;line-height:18px}.navbar .btn-group{margin:0;padding:5px 5px 6px}.navbar .nav>li>a:hover{background-color:transparent;color:#fff;text-decoration:none}.navbar .nav .active>a,.navbar .nav .active>a:hover{color:#fff;text-decoration:none;background-color:#222}.navbar .divider-vertical{height:40px;width:1px;margin:0 9px;overflow:hidden;background-color:#222;border-right:1px solid #333}.navbar .nav.pull-right{margin-left:10px;margin-right:0}.navbar .btn-navbar{display:none;float:right;padding:7px 10px;margin-left:5px;margin-right:5px;background-color:#2c2c2c;background-image:-moz-linear-gradient(top,#333,#222);background-image:-ms-linear-gradient(top,#333,#222);background-image:-webkit-gradient(linear,0 0,0 100%,from(#333),to(#222));background-image:-webkit-linear-gradient(top,#333,#222);background-image:-o-linear-gradient(top,#333,#222);background-image:linear-gradient(top,#333,#222);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#333333',endColorstr='#222222',GradientType=0);border-color:#222 #222 #000;border-color:rgba(0,0,0,0.1) rgba(0,0,0,0.1) rgba(0,0,0,0.25);*background-color:#222;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,.1),0 1px 0 rgba(255,255,255,.075);-moz-box-shadow:inset 0 1px 0 rgba(255,255,255,.1),0 1px 0 rgba(255,255,255,.075);box-shadow:inset 0 1px 0 rgba(255,255,255,.1),0 1px 0 rgba(255,255,255,.075)}.navbar .btn-navbar:hover,.navbar .btn-navbar:active,.navbar .btn-navbar.active,.navbar .btn-navbar.disabled,.navbar .btn-navbar[disabled]{background-color:#222;*background-color:#151515}.navbar .btn-navbar:active,.navbar .btn-navbar.active{background-color:#080808 \9}.navbar .btn-navbar .icon-bar{display:block;width:18px;height:2px;background-color:#f5f5f5;-webkit-border-radius:1px;-moz-border-radius:1px;border-radius:1px;-webkit-box-shadow:0 1px 0 rgba(0,0,0,0.25);-moz-box-shadow:0 1px 0 rgba(0,0,0,0.25);box-shadow:0 1px 0 rgba(0,0,0,0.25)}.btn-navbar .icon-bar+.icon-bar{margin-top:3px}.navbar .dropdown-menu:before{content:'';display:inline-block;border-left:7px solid transparent;border-right:7px solid transparent;border-bottom:7px solid #ccc;border-bottom-color:rgba(0,0,0,0.2);position:absolute;top:-7px;left:9px}.navbar .dropdown-menu:after{content:'';display:inline-block;border-left:6px solid transparent;border-right:6px solid transparent;border-bottom:6px solid #fff;position:absolute;top:-6px;left:10px}.navbar-fixed-bottom .dropdown-menu:before{border-top:7px solid #ccc;border-top-color:rgba(0,0,0,0.2);border-bottom:0;bottom:-7px;top:auto}.navbar-fixed-bottom .dropdown-menu:after{border-top:6px solid #fff;border-bottom:0;bottom:-6px;top:auto}.navbar .nav li.dropdown .dropdown-toggle .caret,.navbar .nav li.dropdown.open .caret{border-top-color:#fff;border-bottom-color:#fff}.navbar .nav li.dropdown.active .caret{opacity:1;filter:alpha(opacity=100)}.navbar .nav li.dropdown.open>.dropdown-toggle,.navbar .nav li.dropdown.active>.dropdown-toggle,.navbar .nav li.dropdown.open.active>.dropdown-toggle{background-color:transparent}.navbar .nav li.dropdown.active>.dropdown-toggle:hover{color:#fff}.navbar .pull-right .dropdown-menu,.navbar .dropdown-menu.pull-right{left:auto;right:0}.navbar .pull-right .dropdown-menu:before,.navbar .dropdown-menu.pull-right:before{left:auto;right:12px}.navbar .pull-right .dropdown-menu:after,.navbar .dropdown-menu.pull-right:after{left:auto;right:13px}.breadcrumb{padding:7px 14px;margin:0 0 18px;list-style:none;background-color:#fbfbfb;background-image:-moz-linear-gradient(top,#fff,#f5f5f5);background-image:-ms-linear-gradient(top,#fff,#f5f5f5);background-image:-webkit-gradient(linear,0 0,0 100%,from(#fff),to(#f5f5f5));background-image:-webkit-linear-gradient(top,#fff,#f5f5f5);background-image:-o-linear-gradient(top,#fff,#f5f5f5);background-image:linear-gradient(top,#fff,#f5f5f5);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ffffff',endColorstr='#f5f5f5',GradientType=0);border:1px solid #ddd;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px;-webkit-box-shadow:inset 0 1px 0 #fff;-moz-box-shadow:inset 0 1px 0 #fff;box-shadow:inset 0 1px 0 #fff}.breadcrumb li{display:inline-block;*display:inline;*zoom:1;text-shadow:0 1px 0 #fff}.breadcrumb .divider{padding:0 5px;color:#999}.breadcrumb .active a{color:#333}.pagination{height:36px;margin:18px 0}.pagination ul{display:inline-block;*display:inline;*zoom:1;margin-left:0;margin-bottom:0;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px;-webkit-box-shadow:0 1px 2px rgba(0,0,0,0.05);-moz-box-shadow:0 1px 2px rgba(0,0,0,0.05);box-shadow:0 1px 2px rgba(0,0,0,0.05)}.pagination li{display:inline}.pagination a{float:left;padding:0 14px;line-height:34px;text-decoration:none;border:1px solid #ddd;border-left-width:0}.pagination a:hover,.pagination .active a{background-color:#f5f5f5}.pagination .active a{color:#999;cursor:default}.pagination .disabled span,.pagination .disabled a,.pagination .disabled a:hover{color:#999;background-color:transparent;cursor:default}.pagination li:first-child a{border-left-width:1px;-webkit-border-radius:3px 0 0 3px;-moz-border-radius:3px 0 0 3px;border-radius:3px 0 0 3px}.pagination li:last-child a{-webkit-border-radius:0 3px 3px 0;-moz-border-radius:0 3px 3px 0;border-radius:0 3px 3px 0}.pagination-centered{text-align:center}.pagination-right{text-align:right}.pager{margin-left:0;margin-bottom:18px;list-style:none;text-align:center;*zoom:1}.pager:before,.pager:after{display:table;content:""}.pager:after{clear:both}.pager li{display:inline}.pager a{display:inline-block;padding:5px 14px;background-color:#fff;border:1px solid #ddd;-webkit-border-radius:15px;-moz-border-radius:15px;border-radius:15px}.pager a:hover{text-decoration:none;background-color:#f5f5f5}.pager .next a{float:right}.pager .previous a{float:left}.pager .disabled a,.pager .disabled a:hover{color:#999;background-color:#fff;cursor:default}.modal-open .dropdown-menu{z-index:2050}.modal-open .dropdown.open{*z-index:2050}.modal-open .popover{z-index:2060}.modal-open .tooltip{z-index:2070}.modal-backdrop{position:fixed;top:0;right:0;bottom:0;left:0;z-index:1040;background-color:#000}.modal-backdrop.fade{opacity:0}.modal-backdrop,.modal-backdrop.fade.in{opacity:.8;filter:alpha(opacity=80)}.modal{position:fixed;top:50%;left:50%;z-index:1050;overflow:auto;width:560px;margin:-250px 0 0 -280px;background-color:#fff;border:1px solid #999;border:1px solid rgba(0,0,0,0.3);*border:1px solid #999;-webkit-border-radius:6px;-moz-border-radius:6px;border-radius:6px;-webkit-box-shadow:0 3px 7px rgba(0,0,0,0.3);-moz-box-shadow:0 3px 7px rgba(0,0,0,0.3);box-shadow:0 3px 7px rgba(0,0,0,0.3);-webkit-background-clip:padding-box;-moz-background-clip:padding-box;background-clip:padding-box}.modal.fade{-webkit-transition:opacity .3s linear,top .3s ease-out;-moz-transition:opacity .3s linear,top .3s ease-out;-ms-transition:opacity .3s linear,top .3s ease-out;-o-transition:opacity .3s linear,top .3s ease-out;transition:opacity .3s linear,top .3s ease-out;top:-25%}.modal.fade.in{top:50%}.modal-header{padding:9px 15px;border-bottom:1px solid #eee}.modal-header .close{margin-top:2px}.modal-body{overflow-y:auto;max-height:400px;padding:15px}.modal-form{margin-bottom:0}.modal-footer{padding:14px 15px 15px;margin-bottom:0;text-align:right;background-color:#f5f5f5;border-top:1px solid #ddd;-webkit-border-radius:0 0 6px 6px;-moz-border-radius:0 0 6px 6px;border-radius:0 0 6px 6px;-webkit-box-shadow:inset 0 1px 0 #fff;-moz-box-shadow:inset 0 1px 0 #fff;box-shadow:inset 0 1px 0 #fff;*zoom:1}.modal-footer:before,.modal-footer:after{display:table;content:""}.modal-footer:after{clear:both}.modal-footer .btn+.btn{margin-left:5px;margin-bottom:0}.modal-footer .btn-group .btn+.btn{margin-left:-1px}.tooltip{position:absolute;z-index:1020;display:block;visibility:visible;padding:5px;font-size:11px;opacity:0;filter:alpha(opacity=0)}.tooltip.in{opacity:.8;filter:alpha(opacity=80)}.tooltip.top{margin-top:-2px}.tooltip.right{margin-left:2px}.tooltip.bottom{margin-top:2px}.tooltip.left{margin-left:-2px}.tooltip.top .tooltip-arrow{bottom:0;left:50%;margin-left:-5px;border-left:5px solid transparent;border-right:5px solid transparent;border-top:5px solid #000}.tooltip.left .tooltip-arrow{top:50%;right:0;margin-top:-5px;border-top:5px solid transparent;border-bottom:5px solid transparent;border-left:5px solid #000}.tooltip.bottom .tooltip-arrow{top:0;left:50%;margin-left:-5px;border-left:5px solid transparent;border-right:5px solid transparent;border-bottom:5px solid #000}.tooltip.right .tooltip-arrow{top:50%;left:0;margin-top:-5px;border-top:5px solid transparent;border-bottom:5px solid transparent;border-right:5px solid #000}.tooltip-inner{max-width:200px;padding:3px 8px;color:#fff;text-align:center;text-decoration:none;background-color:#000;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.tooltip-arrow{position:absolute;width:0;height:0}.popover{position:absolute;top:0;left:0;z-index:1010;display:none;padding:5px}.popover.top{margin-top:-5px}.popover.right{margin-left:5px}.popover.bottom{margin-top:5px}.popover.left{margin-left:-5px}.popover.top .arrow{bottom:0;left:50%;margin-left:-5px;border-left:5px solid transparent;border-right:5px solid transparent;border-top:5px solid #000}.popover.right .arrow{top:50%;left:0;margin-top:-5px;border-top:5px solid transparent;border-bottom:5px solid transparent;border-right:5px solid #000}.popover.bottom .arrow{top:0;left:50%;margin-left:-5px;border-left:5px solid transparent;border-right:5px solid transparent;border-bottom:5px solid #000}.popover.left .arrow{top:50%;right:0;margin-top:-5px;border-top:5px solid transparent;border-bottom:5px solid transparent;border-left:5px solid #000}.popover .arrow{position:absolute;width:0;height:0}.popover-inner{padding:3px;width:280px;overflow:hidden;background:#000;background:rgba(0,0,0,0.8);-webkit-border-radius:6px;-moz-border-radius:6px;border-radius:6px;-webkit-box-shadow:0 3px 7px rgba(0,0,0,0.3);-moz-box-shadow:0 3px 7px rgba(0,0,0,0.3);box-shadow:0 3px 7px rgba(0,0,0,0.3)}.popover-title{padding:9px 15px;line-height:1;background-color:#f5f5f5;border-bottom:1px solid #eee;-webkit-border-radius:3px 3px 0 0;-moz-border-radius:3px 3px 0 0;border-radius:3px 3px 0 0}.popover-content{padding:14px;background-color:#fff;-webkit-border-radius:0 0 3px 3px;-moz-border-radius:0 0 3px 3px;border-radius:0 0 3px 3px;-webkit-background-clip:padding-box;-moz-background-clip:padding-box;background-clip:padding-box}.popover-content p,.popover-content ul,.popover-content ol{margin-bottom:0}.thumbnails{margin-left:-20px;list-style:none;*zoom:1}.thumbnails:before,.thumbnails:after{display:table;content:""}.thumbnails:after{clear:both}.row-fluid .thumbnails{margin-left:0}.thumbnails>li{float:left;margin-bottom:18px;margin-left:20px}.thumbnail{display:block;padding:4px;line-height:1;border:1px solid #ddd;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px;-webkit-box-shadow:0 1px 1px rgba(0,0,0,0.075);-moz-box-shadow:0 1px 1px rgba(0,0,0,0.075);box-shadow:0 1px 1px rgba(0,0,0,0.075)}a.thumbnail:hover{border-color:#08c;-webkit-box-shadow:0 1px 4px rgba(0,105,214,0.25);-moz-box-shadow:0 1px 4px rgba(0,105,214,0.25);box-shadow:0 1px 4px rgba(0,105,214,0.25)}.thumbnail>img{display:block;max-width:100%;margin-left:auto;margin-right:auto}.thumbnail .caption{padding:9px}.label,.badge{font-size:10.998px;font-weight:bold;line-height:14px;color:#fff;vertical-align:baseline;white-space:nowrap;text-shadow:0 -1px 0 rgba(0,0,0,0.25);background-color:#999}.label{padding:1px 4px 2px;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px}.badge{padding:1px 9px 2px;-webkit-border-radius:9px;-moz-border-radius:9px;border-radius:9px}a.label:hover,a.badge:hover{color:#fff;text-decoration:none;cursor:pointer}.label-important,.badge-important{background-color:#b94a48}.label-important[href],.badge-important[href]{background-color:#953b39}.label-warning,.badge-warning{background-color:#f89406}.label-warning[href],.badge-warning[href]{background-color:#c67605}.label-success,.badge-success{background-color:#468847}.label-success[href],.badge-success[href]{background-color:#356635}.label-info,.badge-info{background-color:#3a87ad}.label-info[href],.badge-info[href]{background-color:#2d6987}.label-inverse,.badge-inverse{background-color:#333}.label-inverse[href],.badge-inverse[href]{background-color:#1a1a1a}@-webkit-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@-moz-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@-ms-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@-o-keyframes progress-bar-stripes{from{background-position:0 0}to{background-position:40px 0}}@keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}.progress{overflow:hidden;height:18px;margin-bottom:18px;background-color:#f7f7f7;background-image:-moz-linear-gradient(top,#f5f5f5,#f9f9f9);background-image:-ms-linear-gradient(top,#f5f5f5,#f9f9f9);background-image:-webkit-gradient(linear,0 0,0 100%,from(#f5f5f5),to(#f9f9f9));background-image:-webkit-linear-gradient(top,#f5f5f5,#f9f9f9);background-image:-o-linear-gradient(top,#f5f5f5,#f9f9f9);background-image:linear-gradient(top,#f5f5f5,#f9f9f9);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#f5f5f5',endColorstr='#f9f9f9',GradientType=0);-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,0.1);-moz-box-shadow:inset 0 1px 2px rgba(0,0,0,0.1);box-shadow:inset 0 1px 2px rgba(0,0,0,0.1);-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.progress .bar{width:0;height:18px;color:#fff;font-size:12px;text-align:center;text-shadow:0 -1px 0 rgba(0,0,0,0.25);background-color:#0e90d2;background-image:-moz-linear-gradient(top,#149bdf,#0480be);background-image:-ms-linear-gradient(top,#149bdf,#0480be);background-image:-webkit-gradient(linear,0 0,0 100%,from(#149bdf),to(#0480be));background-image:-webkit-linear-gradient(top,#149bdf,#0480be);background-image:-o-linear-gradient(top,#149bdf,#0480be);background-image:linear-gradient(top,#149bdf,#0480be);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#149bdf',endColorstr='#0480be',GradientType=0);-webkit-box-shadow:inset 0 -1px 0 rgba(0,0,0,0.15);-moz-box-shadow:inset 0 -1px 0 rgba(0,0,0,0.15);box-shadow:inset 0 -1px 0 rgba(0,0,0,0.15);-webkit-box-sizing:border-box;-moz-box-sizing:border-box;-ms-box-sizing:border-box;box-sizing:border-box;-webkit-transition:width .6s ease;-moz-transition:width .6s ease;-ms-transition:width .6s ease;-o-transition:width .6s ease;transition:width .6s ease}.progress-striped .bar{background-color:#149bdf;background-image:-webkit-gradient(linear,0 100%,100% 0,color-stop(0.25,rgba(255,255,255,0.15)),color-stop(0.25,transparent),color-stop(0.5,transparent),color-stop(0.5,rgba(255,255,255,0.15)),color-stop(0.75,rgba(255,255,255,0.15)),color-stop(0.75,transparent),to(transparent));background-image:-webkit-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-moz-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-ms-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);-webkit-background-size:40px 40px;-moz-background-size:40px 40px;-o-background-size:40px 40px;background-size:40px 40px}.progress.active .bar{-webkit-animation:progress-bar-stripes 2s linear infinite;-moz-animation:progress-bar-stripes 2s linear infinite;-ms-animation:progress-bar-stripes 2s linear infinite;-o-animation:progress-bar-stripes 2s linear infinite;animation:progress-bar-stripes 2s linear infinite}.progress-danger .bar{background-color:#dd514c;background-image:-moz-linear-gradient(top,#ee5f5b,#c43c35);background-image:-ms-linear-gradient(top,#ee5f5b,#c43c35);background-image:-webkit-gradient(linear,0 0,0 100%,from(#ee5f5b),to(#c43c35));background-image:-webkit-linear-gradient(top,#ee5f5b,#c43c35);background-image:-o-linear-gradient(top,#ee5f5b,#c43c35);background-image:linear-gradient(top,#ee5f5b,#c43c35);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#ee5f5b',endColorstr='#c43c35',GradientType=0)}.progress-danger.progress-striped .bar{background-color:#ee5f5b;background-image:-webkit-gradient(linear,0 100%,100% 0,color-stop(0.25,rgba(255,255,255,0.15)),color-stop(0.25,transparent),color-stop(0.5,transparent),color-stop(0.5,rgba(255,255,255,0.15)),color-stop(0.75,rgba(255,255,255,0.15)),color-stop(0.75,transparent),to(transparent));background-image:-webkit-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-moz-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-ms-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent)}.progress-success .bar{background-color:#5eb95e;background-image:-moz-linear-gradient(top,#62c462,#57a957);background-image:-ms-linear-gradient(top,#62c462,#57a957);background-image:-webkit-gradient(linear,0 0,0 100%,from(#62c462),to(#57a957));background-image:-webkit-linear-gradient(top,#62c462,#57a957);background-image:-o-linear-gradient(top,#62c462,#57a957);background-image:linear-gradient(top,#62c462,#57a957);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#62c462',endColorstr='#57a957',GradientType=0)}.progress-success.progress-striped .bar{background-color:#62c462;background-image:-webkit-gradient(linear,0 100%,100% 0,color-stop(0.25,rgba(255,255,255,0.15)),color-stop(0.25,transparent),color-stop(0.5,transparent),color-stop(0.5,rgba(255,255,255,0.15)),color-stop(0.75,rgba(255,255,255,0.15)),color-stop(0.75,transparent),to(transparent));background-image:-webkit-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-moz-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-ms-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent)}.progress-info .bar{background-color:#4bb1cf;background-image:-moz-linear-gradient(top,#5bc0de,#339bb9);background-image:-ms-linear-gradient(top,#5bc0de,#339bb9);background-image:-webkit-gradient(linear,0 0,0 100%,from(#5bc0de),to(#339bb9));background-image:-webkit-linear-gradient(top,#5bc0de,#339bb9);background-image:-o-linear-gradient(top,#5bc0de,#339bb9);background-image:linear-gradient(top,#5bc0de,#339bb9);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#5bc0de',endColorstr='#339bb9',GradientType=0)}.progress-info.progress-striped .bar{background-color:#5bc0de;background-image:-webkit-gradient(linear,0 100%,100% 0,color-stop(0.25,rgba(255,255,255,0.15)),color-stop(0.25,transparent),color-stop(0.5,transparent),color-stop(0.5,rgba(255,255,255,0.15)),color-stop(0.75,rgba(255,255,255,0.15)),color-stop(0.75,transparent),to(transparent));background-image:-webkit-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-moz-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-ms-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent)}.progress-warning .bar{background-color:#faa732;background-image:-moz-linear-gradient(top,#fbb450,#f89406);background-image:-ms-linear-gradient(top,#fbb450,#f89406);background-image:-webkit-gradient(linear,0 0,0 100%,from(#fbb450),to(#f89406));background-image:-webkit-linear-gradient(top,#fbb450,#f89406);background-image:-o-linear-gradient(top,#fbb450,#f89406);background-image:linear-gradient(top,#fbb450,#f89406);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#fbb450',endColorstr='#f89406',GradientType=0)}.progress-warning.progress-striped .bar{background-color:#fbb450;background-image:-webkit-gradient(linear,0 100%,100% 0,color-stop(0.25,rgba(255,255,255,0.15)),color-stop(0.25,transparent),color-stop(0.5,transparent),color-stop(0.5,rgba(255,255,255,0.15)),color-stop(0.75,rgba(255,255,255,0.15)),color-stop(0.75,transparent),to(transparent));background-image:-webkit-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-moz-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-ms-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:-o-linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent);background-image:linear-gradient(-45deg,rgba(255,255,255,0.15) 25%,transparent 25%,transparent 50%,rgba(255,255,255,0.15) 50%,rgba(255,255,255,0.15) 75%,transparent 75%,transparent)}.accordion{margin-bottom:18px}.accordion-group{margin-bottom:2px;border:1px solid #e5e5e5;-webkit-border-radius:4px;-moz-border-radius:4px;border-radius:4px}.accordion-heading{border-bottom:0}.accordion-heading .accordion-toggle{display:block;padding:8px 15px}.accordion-toggle{cursor:pointer}.accordion-inner{padding:9px 15px;border-top:1px solid #e5e5e5}.carousel{position:relative;margin-bottom:18px;line-height:1}.carousel-inner{overflow:hidden;width:100%;position:relative}.carousel .item{display:none;position:relative;-webkit-transition:.6s ease-in-out left;-moz-transition:.6s ease-in-out left;-ms-transition:.6s ease-in-out left;-o-transition:.6s ease-in-out left;transition:.6s ease-in-out left}.carousel .item>img{display:block;line-height:1}.carousel .active,.carousel .next,.carousel .prev{display:block}.carousel .active{left:0}.carousel .next,.carousel .prev{position:absolute;top:0;width:100%}.carousel .next{left:100%}.carousel .prev{left:-100%}.carousel .next.left,.carousel .prev.right{left:0}.carousel .active.left{left:-100%}.carousel .active.right{left:100%}.carousel-control{position:absolute;top:40%;left:15px;width:40px;height:40px;margin-top:-20px;font-size:60px;font-weight:100;line-height:30px;color:#fff;text-align:center;background:#222;border:3px solid #fff;-webkit-border-radius:23px;-moz-border-radius:23px;border-radius:23px;opacity:.5;filter:alpha(opacity=50)}.carousel-control.right{left:auto;right:15px}.carousel-control:hover{color:#fff;text-decoration:none;opacity:.9;filter:alpha(opacity=90)}.carousel-caption{position:absolute;left:0;right:0;bottom:0;padding:10px 15px 5px;background:#333;background:rgba(0,0,0,0.75)}.carousel-caption h4,.carousel-caption p{color:#fff}.hero-unit{padding:60px;margin-bottom:30px;background-color:#eee;-webkit-border-radius:6px;-moz-border-radius:6px;border-radius:6px}.hero-unit h1{margin-bottom:0;font-size:60px;line-height:1;color:inherit;letter-spacing:-1px}.hero-unit p{font-size:18px;font-weight:200;line-height:27px;color:inherit}.pull-right{float:right}.pull-left{float:left}.hide{display:none}.show{display:block}.invisible{visibility:hidden} \ No newline at end of file diff --git a/lib/bootstrap-modal.js b/lib/bootstrap-modal.js new file mode 100644 index 00000000..38fd0c84 --- /dev/null +++ b/lib/bootstrap-modal.js @@ -0,0 +1,218 @@ +/* ========================================================= + * bootstrap-modal.js v2.0.4 + * http://twitter.github.com/bootstrap/javascript.html#modals + * ========================================================= + * Copyright 2012 Twitter, Inc. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + * ========================================================= */ + + +!function ($) { + + "use strict"; // jshint ;_; + + + /* MODAL CLASS DEFINITION + * ====================== */ + + var Modal = function (content, options) { + this.options = options + this.$element = $(content) + .delegate('[data-dismiss="modal"]', 'click.dismiss.modal', $.proxy(this.hide, this)) + } + + Modal.prototype = { + + constructor: Modal + + , toggle: function () { + return this[!this.isShown ? 'show' : 'hide']() + } + + , show: function () { + var that = this + , e = $.Event('show') + + this.$element.trigger(e) + + if (this.isShown || e.isDefaultPrevented()) return + + $('body').addClass('modal-open') + + this.isShown = true + + escape.call(this) + backdrop.call(this, function () { + var transition = $.support.transition && that.$element.hasClass('fade') + + if (!that.$element.parent().length) { + that.$element.appendTo(document.body) //don't move modals dom position + } + + that.$element + .show() + + if (transition) { + that.$element[0].offsetWidth // force reflow + } + + that.$element.addClass('in') + + transition ? + that.$element.one($.support.transition.end, function () { that.$element.trigger('shown') }) : + that.$element.trigger('shown') + + }) + } + + , hide: function (e) { + e && e.preventDefault() + + var that = this + + e = $.Event('hide') + + this.$element.trigger(e) + + if (!this.isShown || e.isDefaultPrevented()) return + + this.isShown = false + + $('body').removeClass('modal-open') + + escape.call(this) + + this.$element.removeClass('in') + + $.support.transition && this.$element.hasClass('fade') ? + hideWithTransition.call(this) : + hideModal.call(this) + } + + } + + + /* MODAL PRIVATE METHODS + * ===================== */ + + function hideWithTransition() { + var that = this + , timeout = setTimeout(function () { + that.$element.off($.support.transition.end) + hideModal.call(that) + }, 500) + + this.$element.one($.support.transition.end, function () { + clearTimeout(timeout) + hideModal.call(that) + }) + } + + function hideModal(that) { + this.$element + .hide() + .trigger('hidden') + + backdrop.call(this) + } + + function backdrop(callback) { + var that = this + , animate = this.$element.hasClass('fade') ? 'fade' : '' + + if (this.isShown && this.options.backdrop) { + var doAnimate = $.support.transition && animate + + this.$backdrop = $('
    -
    +
    @@ -91,51 +92,32 @@ "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, + 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. - 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 + 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 JSON values. This allows user - agents to be able to successfully navigate documents containing JSON based on their - schemas. + 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 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. + 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: @@ -145,16 +127,19 @@ "title": "Product", "properties": { "id": { - "title": "Product Identifier", - "type": "number" + "type": "number", + "description": "Product identifier", + "required": true }, "name": { - "title": "Product Name", - "type": "string" + "description": "Name of the product", + "type": "string", + "required": true }, "price": { "type": "number", - "minimum": 0 + "minimum": 0, + "required": true }, "tags": { "type": "array", @@ -163,7 +148,6 @@ } } }, - "required" : ["id", "name", "price"], "links": [{ "rel": "full", "href": "{id}" @@ -175,24 +159,32 @@ ]]> - 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. + 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 - 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. + 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) @@ -209,24 +201,25 @@
    - 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: + 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:
    @@ -237,18 +230,21 @@ Content-Type: application/my-media-type+json;
    ; rel="describedby" +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 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). + 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).
    @@ -257,13 +253,13 @@ Link: ; rel="describedby" 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 + target="http://json-schema.org/draft-03/schema">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-04/hyper-schema. - All schemas used within a protocol with a media type specified SHOULD include a + target="http://json-schema.org/draft-03/hyper-schema">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: @@ -271,7 +267,7 @@ Link: ; rel="describedby" @@ -281,13 +277,13 @@ Content-Type: application/json;
    - A JSON Schema is a JSON object that defines various attributes (including usage and + 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: + An example JSON Schema definition 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. - -
    - -
    - - 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. - + A JSON Schema object may have any of the following properties, called schema + attributes (all attributes are optional): -
    - -
    - -
    - -
    - - 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. +
    + + 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. + - 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. + 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: + + +
    +
    - 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. - - +
    + 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. +
    - 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 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 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. - - +
    + 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. +
    - If this attribute is not specified, then all value types are accepted. +
    + 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. +
    -
    - For example, a schema that defines if an instance can be a string or a - number would be: - - - -
    +
    + 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. + + +
    - 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. +
    + 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 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. - - +
    + 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. +
    - 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". +
    + 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 array MUST have at least one element. Elements in the array MUST be unique. + + 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. +
    - 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. +
    + 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. +
    - 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": +
    + 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": -
    - +
    + - -
    +
    +
    -
    - +
    + - -
    - - -
    - -
    - -
    - - 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. - +
    + + 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. + +
    @@ -820,24 +694,22 @@ Content-Type: application/json; 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). + target="http://json-schema.org/draft-03/links">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 @@ -1000,13 +872,6 @@ 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. @@ -1092,30 +957,97 @@ GET /Resource/ 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. + 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 3986, Sec + The fragment identifier is based on RFC 2396, 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. +
    + + 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 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. + 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.
    @@ -1128,7 +1060,7 @@ GET /Resource/
    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 + 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. @@ -1222,7 +1154,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-04/hyper-schema, but it is allowable to use other + 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 @@ -1234,7 +1166,7 @@ Content-Type: application/json; profile=/schema-for-this-data 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, + target="RFC5226">RFC 5226. Requests should be made by email to IANA, which will then forward the request to the IESG, requesting approval.
    @@ -1246,21 +1178,10 @@ Content-Type: application/json; profile=/schema-for-this-data &rfc2045; &rfc2119; + &rfc2396; &rfc3339; &rfc3986; &rfc4287; - - - JSON Pointer - - ForgeRock US, Inc. - - - SitePen (USA) - - - - &rfc2616; @@ -1276,23 +1197,6 @@ 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. - 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. @@ -1349,5 +1253,18 @@ 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 bc478c901a9ea83a39dd95ea47d67e441d164654 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sun, 2 Sep 2012 18:58:17 +0200 Subject: [PATCH 0166/1659] Rework index.html and implementations.html Also add a new Ruby based implementation to the implementations list, and remove non-existing ones. --- implementations.html | 74 ++++++++++++++++++++++++++++++++++---------- index.html | 31 ++++++++++--------- 2 files changed, 74 insertions(+), 31 deletions(-) diff --git a/implementations.html b/implementations.html index 85b7eaee..73de1814 100644 --- a/implementations.html +++ b/implementations.html @@ -8,27 +8,67 @@
    -
    - +
    + +

    Preliminary note

    + +

    Implementations below are written in different languages, and support part, +or all, of the specification. This page only lists the implementaions and links +to them, and does not specify the level of JSON Schema support.

    + +

    Implementations below are classified based on their programming language. +When known, the license of the project is also mentioned.

    + +

    C

    + +

    Yes, there is one: WJElement (GPLv3/LGPLv3).

    + +

    Java

    + +

    json-schema-validator +and json-schema-formats +(LGPLv3). + +

    .NET

    + +

    Json.NET +(MIT).

    + +

    ActionScript 3

    + +

    Frigga (MIT).

    + +

    Ruby

    + + + +

    PHP

    + +

    jsonschemaphpv +(MIT).

    + +

    And, of course, JavaScript

    + +
    diff --git a/index.html b/index.html index 408c8545..ac08fcd2 100644 --- a/index.html +++ b/index.html @@ -44,7 +44,23 @@

    Existing IETF drafts

    Pointer. -

    Schemas

    +

    Implementations

    + +

    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.

    + +

    Contributing

    + +

    JSON Schema as a whole (this site, the specifications, and related projects) +can be found on GitHub. +Feature/pull requests are welcome.

    + +

    Schemas

    The following are schemas that are available for referencing (more to come):

    Core Meta-Schema
    This is the meta-schema @@ -67,19 +83,6 @@

    Schemas

    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.

    - -

    Contributing

    - -

    JSON Schema as a whole (this site, the specifications, and related projects) -can be found on GitHub. -Feature/pull requests are welcome.

    -
    From ab805cd5796c3810a08e4efcbbb10f793fb893c1 Mon Sep 17 00:00:00 2001 From: nickl- Date: Sun, 2 Sep 2012 19:30:55 +0200 Subject: [PATCH 0167/1659] update php schema validators --- implementations.html | 50 +++++++++++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/implementations.html b/implementations.html index 73de1814..f7f3d6a7 100644 --- a/implementations.html +++ b/implementations.html @@ -23,29 +23,30 @@

    Preliminary note

    Implementations below are classified based on their programming language. When known, the license of the project is also mentioned.

    - +
    +

    C

    -

    Yes, there is one: WJElement (GPLv3/LGPLv3).

    +

    Yes, there is one:

    +

    Java

    - -

    json-schema-validator -and json-schema-formats +

    .NET

    - -

    Json.NET -(MIT).

    - +

    ActionScript 3

    - -

    Frigga (MIT).

    - +

    Ruby

      @@ -54,13 +55,22 @@

      Ruby

      href="https://github.com/Constellation/ruby-jsonchema">ruby-jsonschema (MIT).
    +
    +
    +

    PHP

    + -

    And, of course, JavaScript

    +

    JavaScript

    • JSV;
    • @@ -69,6 +79,8 @@

      And, of course, JavaScript

    • Dojo;
    • Persevere (modified BSD or AFL 2.0).
    +
    +
    From 8e8375a2c443e272ac5175da0fb4d7af6f25e064 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Mon, 3 Sep 2012 12:04:32 +0200 Subject: [PATCH 0168/1659] implementations.html: add Matic --- implementations.html | 1 + 1 file changed, 1 insertion(+) diff --git a/implementations.html b/implementations.html index f7f3d6a7..e73b5aab 100644 --- a/implementations.html +++ b/implementations.html @@ -78,6 +78,7 @@

    JavaScript

  • json-schema;
  • Dojo;
  • Persevere (modified BSD or AFL 2.0).
  • +
  • Matic (MIT)
  • From 562312167d8470953d88deb61fcb3a9168fd8b69 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Mon, 3 Sep 2012 18:19:07 +0200 Subject: [PATCH 0169/1659] implementations.html: add one python implementation https://github.com/Julian/jsonschema --- implementations.html | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/implementations.html b/implementations.html index e73b5aab..5436ddff 100644 --- a/implementations.html +++ b/implementations.html @@ -24,6 +24,7 @@

    Preliminary note

    Implementations below are classified based on their programming language. When known, the license of the project is also mentioned.

    +

    C

    @@ -34,7 +35,7 @@

    C

    Java

    @@ -47,6 +48,16 @@

    ActionScript 3

    + +

    Python

    + + + +
    + +

    Ruby

      @@ -55,8 +66,6 @@

      Ruby

      href="https://github.com/Constellation/ruby-jsonchema">ruby-jsonschema (MIT).
    -
    -

    PHP

    From eb75093eb28e6f36ffaa73941a8b4d5af177869f Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Thu, 13 Sep 2012 20:41:40 +0200 Subject: [PATCH 0170/1659] Update json-ref schema It was VERY obsolete! --- json-ref | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/json-ref b/json-ref index 323df0c6..0c616021 100644 --- a/json-ref +++ b/json-ref @@ -1,26 +1,26 @@ { - "$schema" : "http://json-schema.org/hyper-schema", - "id" : "http://json-schema.org/json-ref", + "$schema": "http://json-schema.org/hyper-schema", + "id": "http://json-schema.org/json-ref", - "items" : "#", - "additionalProperties" : "#", + "items": { "$ref": "#" }, + "additionalProperties": { "$ref": "#" }, - "links" : [ + "links": [ { - "href" : "{$ref}", - "rel" : "full" + "href": "{$ref}", + "rel": "full" }, { - "href" : "{$schema}", - "rel" : "describedby" + "href": "{$schema}", + "rel": "describedby" }, { - "href" : "{id}", - "rel" : "self" + "href": "{id}", + "rel": "self" } - ], + ] - "fragmentResolution" : "dot-delimited" -} \ No newline at end of file + "fragmentResolution": "json-pointer" +} From 0927d1c8b9d4e9a44d47ad99460a8b1f476e4da9 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 15 Sep 2012 14:59:21 +0200 Subject: [PATCH 0171/1659] implementations.html: rework, add new implementation * Unify style * Comments about closing divs, and add missing one * Add a... Haskell implementation to the list (!) --- implementations.html | 103 +++++++++++++++++++++++++------------------ 1 file changed, 59 insertions(+), 44 deletions(-) diff --git a/implementations.html b/implementations.html index 5436ddff..150a8d8f 100644 --- a/implementations.html +++ b/implementations.html @@ -1,52 +1,69 @@ - - JSON Schema Implementations - - - + + + JSON Schema Implementations + + + + +
    -
    -
    - -
    -
    -
    +
    + +
    +
    + +
    +

    Preliminary note

    -

    Implementations below are written in different languages, and support part, -or all, of the specification. This page only lists the implementaions and links -to them, and does not specify the level of JSON Schema support.

    +

    Implementations below are written in different languages, and support part, or all, of the +specification. This page only lists the implementaions and links to them, and does not specify the +level of JSON Schema support.

    + +

    Implementations below are classified based on their programming language. When known, the +license of the project is also mentioned.

    -

    Implementations below are classified based on their programming language. -When known, the license of the project is also mentioned.

    -
    +
    +
    -

    C

    Yes, there is one:

    +

    Java

    + +

    .NET

    + +

    ActionScript 3

    + + + +

    Haskell

    + +

    If that is not proof that JSON Schema is language agnostic, I don't know what is.

    +

    Python

    @@ -55,28 +72,23 @@

    Python

  • jsonschema.
  • -
    +
    + +
    -

    Ruby

    PHP

    - -
    -
    -
    -
    - + +
    +
    +
    +
    +
    + + From 37290cd4c7833b0c568de91a3f2cc18a6dd312aa Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 22 Sep 2012 22:47:51 +0200 Subject: [PATCH 0172/1659] Add Orderly implementation --- implementations.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/implementations.html b/implementations.html index 150a8d8f..181f5e08 100644 --- a/implementations.html +++ b/implementations.html @@ -94,12 +94,13 @@

    PHP

    JavaScript

    From a5b973bfed1f1c7c046080efa3c748229c676d7a Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 25 Sep 2012 12:22:57 +0200 Subject: [PATCH 0173/1659] Fix miswritten card schema Also add a "$schema" to explicitly mention that it is a draftv3 written schema. --- card | 91 ++++++------- draft-03/schema | 346 ++++++++++++++++++++++++------------------------ 2 files changed, 219 insertions(+), 218 deletions(-) diff --git a/card b/card index 062d84d0..d4d28e02 100644 --- a/card +++ b/card @@ -1,47 +1,48 @@ { - "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": "uri" }, - "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": { "type": "string" }, - "logo": { "type": "string" }, - "sound": { "type": "string" }, - "bday": { "type": "string", "format": "date" }, - "title": { "type": "string" }, - "role": { "type": "string" }, - "org": { - "type": "object", - "properties": { - "organizationName": { "type": "string" }, - "organizationUnit": { "type": "string" } - } - } - } + "$schema": "http://json-schema.org/draft-03/schema#", + "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": "uri" }, + "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": { "type": "string" }, + "logo": { "type": "string" }, + "sound": { "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-03/schema b/draft-03/schema index 55ae47d8..7a1a2d38 100644 --- a/draft-03/schema +++ b/draft-03/schema @@ -1,174 +1,174 @@ { - "$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", {"$ref" : "#"}] - }, - "uniqueItems" : true, - "default" : "any" - }, - - "properties" : { - "type" : "object", - "additionalProperties" : {"$ref" : "#"}, - "default" : {} - }, - - "patternProperties" : { - "type" : "object", - "additionalProperties" : {"$ref" : "#"}, - "default" : {} - }, - - "additionalProperties" : { - "type" : [{"$ref" : "#"}, "boolean"], - "default" : {} - }, - - "items" : { - "type" : [{"$ref" : "#"}, "array"], - "items" : {"$ref" : "#"}, - "default" : {} - }, - - "additionalItems" : { - "type" : [{"$ref" : "#"}, "boolean"], - "default" : {} - }, - - "required" : { - "type" : "boolean", - "default" : false - }, - - "dependencies" : { - "type" : "object", - "additionalProperties" : { - "type" : ["string", "array", {"$ref" : "#"}], - "items" : { - "type" : "string" - } - }, - "default" : {} - }, - - "minimum" : { - "type" : "number" - }, - - "maximum" : { - "type" : "number" - }, - - "exclusiveMinimum" : { - "type" : "boolean", - "default" : false - }, - - "exclusiveMaximum" : { - "type" : "boolean", - "default" : false - }, - - "minItems" : { - "type" : "integer", - "minimum" : 0, - "default" : 0 - }, - - "maxItems" : { - "type" : "integer", - "minimum" : 0 - }, - - "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 - }, - - "default" : { - "type" : "any" - }, - - "title" : { - "type" : "string" - }, - - "description" : { - "type" : "string" - }, - - "format" : { - "type" : "string" - }, - - "divisibleBy" : { - "type" : "number", - "minimum" : 0, - "exclusiveMinimum" : true, - "default" : 1 - }, - - "disallow" : { - "type" : ["string", "array"], - "items" : { - "type" : ["string", {"$ref" : "#"}] - }, - "uniqueItems" : true - }, - - "extends" : { - "type" : [{"$ref" : "#"}, "array"], - "items" : {"$ref" : "#"}, - "default" : {} - }, - - "id" : { - "type" : "string", - "format" : "uri" - }, - - "$ref" : { - "type" : "string", - "format" : "uri" - }, - - "$schema" : { - "type" : "string", - "format" : "uri" - } - }, - - "dependencies" : { - "exclusiveMinimum" : "minimum", - "exclusiveMaximum" : "maximum" - }, - - "default" : {} -} \ No newline at end of file + "$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", { "$ref": "#" } ] + }, + "uniqueItems": true, + "default": "any" + }, + + "properties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} + }, + + "patternProperties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} + }, + + "additionalProperties": { + "type": [ { "$ref": "#" }, "boolean" ], + "default": {} + }, + + "items": { + "type": [ { "$ref": "#" }, "array" ], + "items": { "$ref": "#" }, + "default": {} + }, + + "additionalItems": { + "type": [ { "$ref": "#" }, "boolean" ], + "default": {} + }, + + "required": { + "type": "boolean", + "default": false + }, + + "dependencies": { + "type": "object", + "additionalProperties": { + "type": [ "string", "array", { "$ref": "#" } ], + "items": { + "type": "string" + } + }, + "default": {} + }, + + "minimum": { + "type": "number" + }, + + "maximum": { + "type": "number" + }, + + "exclusiveMinimum": { + "type": "boolean", + "default": false + }, + + "exclusiveMaximum": { + "type": "boolean", + "default": false + }, + + "minItems": { + "type": "integer", + "minimum": 0, + "default": 0 + }, + + "maxItems": { + "type": "integer", + "minimum": 0 + }, + + "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 + }, + + "default": { + "type": "any" + }, + + "title": { + "type": "string" + }, + + "description": { + "type": "string" + }, + + "format": { + "type": "string" + }, + + "divisibleBy": { + "type": "number", + "minimum": 0, + "exclusiveMinimum": true, + "default": 1 + }, + + "disallow": { + "type": [ "string", "array" ], + "items": { + "type": [ "string", { "$ref": "#" } ] + }, + "uniqueItems": true + }, + + "extends": { + "type": [ { "$ref": "#" }, "array" ], + "items": { "$ref": "#" }, + "default": {} + }, + + "id": { + "type": "string", + "format": "uri" + }, + + "$ref": { + "type": "string", + "format": "uri" + }, + + "$schema": { + "type": "string", + "format": "uri" + } + }, + + "dependencies": { + "exclusiveMinimum": "minimum", + "exclusiveMaximum": "maximum" + }, + + "default": {} +} From 3103379da6686a7b71ebfecd4f575189dd87884d Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 3 Oct 2012 20:57:57 +0200 Subject: [PATCH 0174/1659] add html from proposals --- next/proposals/json-schema-hypermedia-p1.html | 1213 +++++++++++++++++ 1 file changed, 1213 insertions(+) create mode 100644 next/proposals/json-schema-hypermedia-p1.html diff --git a/next/proposals/json-schema-hypermedia-p1.html b/next/proposals/json-schema-hypermedia-p1.html new file mode 100644 index 00000000..718d19bc --- /dev/null +++ b/next/proposals/json-schema-hypermedia-p1.html @@ -0,0 +1,1213 @@ + +Hyperlinks and media for JSON Schema + + + + + + + +
     TOC 
    +
    + + + + + +
    Internet Engineering Task ForceK. Zyp, Ed.
    Internet-DraftSitePen (USA)
    Intended status: InformationalG. Court
    Expires: March 30, 2013G. 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.

    +

    +

    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
    +

    +
    + +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. + +

    +

    + This specification also uses the following defined terms: + +

    +
    +
    schema
    +
    A JSON Schema object. +
    +
    instance
    +
    Equivalent to "JSON value" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
    +
    property
    +
    Equivalent to "member" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
    +
    item
    +
    Equivalent to "element" as defined in RFC 4627 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. +
    +
    attribute
    +
    A property of a JSON Schema object. +
    +

    + +

    +

    +
     TOC 
    +

    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. + +

    +

    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. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    4.  +Keywords

    + +

    + The following properties are defined for JSON Schema objects: + +

    +

    +
     TOC 
    +

    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}"
    +        }
    +    ]
    +}
    +
    +
    +

    +
     TOC 
    +

    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). + +

    +

    +
     TOC 
    +

    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 (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. + + +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    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 (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. + +

    +

    + +

    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 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 (Nottingham, M., “Web Linking,” May 2010.) [I‑D.nottingham‑http‑link‑header]. +

    +

    +
     TOC 
    +

    4.1.1.3.  +template

    + +

    + This property value is a string that defines the templating language used in the "href" (href) attribute. + If no templating language is defined, then the default Link Description Object templating language (href) is used. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    4.1.1.5.  +mediaType

    + +

    + The value of this property is advisory only, and represents the media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616]. + +

    +

    + 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 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 (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [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. + + +

    + 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. + +

    +

    +
     TOC 
    +

    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 (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. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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". + +

    +

    +
     TOC 
    +

    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 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. + + +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

    +

    +
     TOC 
    +

    4.2.1.  +json-pointer fragment resolution

    + +

    + The "json-pointer" fragment resolution protocol uses a JSON Pointer (Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.) [json‑pointer] to resolve fragment identifiers in URIs within instance representations. + +

    +

    +
     TOC 
    +

    4.3.  +media

    + +

    + The value of this attribute MUST be an object. It MAY contain any of the following properties: + +

    +

    +
     TOC 
    +

    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 (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. + +

    +

    +
     TOC 
    +

    4.3.2.  +mediaType

    + +

    + The value of this property must be a media type RFC 2046 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [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. + +

    +

    + +

    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. +

    + + +

    +
     TOC 
    +

    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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [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. + +

    +

    +
     TOC 
    +

    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 (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) [RFC4627]. + However, there are additional security concerns when using the hyperlink definitions. + +

    +

    +
     TOC 
    +

    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/
    +
    +
    + + +

    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"
    +}]
    +
    +
    + + +

    +
     TOC 
    +

    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). + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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. + +

    +

    +
     TOC 
    +

    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. +

    +

    +
     TOC 
    +

    6.1.  +Registry of Link Relations

    + +

    + This registry is maintained by IANA per RFC 4287 (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) [RFC4287] and this specification adds four values: "full", "create", "instances", "root". + New assignments are subject to IESG Approval, as outlined in RFC 5226 (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) [RFC5226]. + Requests should be made by email to IANA, which will then forward the request to the IESG, requesting approval. + +

    +

    +
     TOC 
    +

    7.  +References

    + +

    +
     TOC 
    +

    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 (TXT).
    [RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
    [RFC3339]Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
    [RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
    [RFC4287]Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
    [json-pointer]Bryan, P. and K. Zyp, “JSON Pointer,” October 2011.
    + +

    +
     TOC 
    +

    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 (TXT, PS, PDF, HTML, XML).
    [RFC4627]Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” RFC 4627, July 2006 (TXT).
    [RFC5226]Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
    [RFC2046]Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT).
    [I-D.hammer-discovery]Hammer-Lahav, E., “LRDD: Link-based Resource Descriptor Discovery,” draft-hammer-discovery-06 (work in progress), May 2010 (TXT).
    [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 (TXT).
    [I-D.nottingham-http-link-header]Nottingham, M., “Web Linking,” draft-nottingham-http-link-header-10 (work in progress), May 2010 (TXT).
    [W3C.REC-html401-19991224]Hors, A., Raggett, D., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
    [W3C.CR-CSS21-20070719]Hickson, I., Lie, H., Çelik, 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 (HTML).
    + +

    +
     TOC 
    +

    Appendix A.  +Change Log

    + +

    +

    +
    +
    draft-04
    +
    + +
      +
    • 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. +
    • +
    + +
    +
    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. +
    • +
    + +
    +
    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. +
    • +
    + +
    +

    + +

    +

    +
     TOC 
    +

    Authors' Addresses

    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
     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
      
     Geraint Luff
    + From f8944c9140e773c167bb9f5367879084a8c1ad21 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Thu, 15 Nov 2012 15:18:28 -0500 Subject: [PATCH 0175/1659] Add direct-schema to the list of implementations. --- implementations.html | 1 + 1 file changed, 1 insertion(+) diff --git a/implementations.html b/implementations.html index 181f5e08..f5ac1780 100644 --- a/implementations.html +++ b/implementations.html @@ -101,6 +101,7 @@

    JavaScript

  • Dojo;
  • Persevere (modified BSD or AFL 2.0);
  • schema.js.
  • +
  • direct-schema (BSD);
  • From 16fd62e65604e65109060b4afc63ff389df9568c Mon Sep 17 00:00:00 2001 From: Nick Lombard Date: Mon, 10 Dec 2012 21:28:30 +0200 Subject: [PATCH 0176/1659] Added json-schema-validator Draft 3 based validator written in python https://github.com/zyga/json-schema-validator --- implementations.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/implementations.html b/implementations.html index f5ac1780..3f6e86c5 100644 --- a/implementations.html +++ b/implementations.html @@ -69,7 +69,8 @@

    Haskell

    Python

    From c0ccbc2578d38db47df6f7dfc606941562a1b667 Mon Sep 17 00:00:00 2001 From: Nick Lombard Date: Mon, 10 Dec 2012 21:45:09 +0200 Subject: [PATCH 0177/1659] Update licensing information Tx google... --- implementations.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/implementations.html b/implementations.html index 3f6e86c5..20457154 100644 --- a/implementations.html +++ b/implementations.html @@ -69,8 +69,8 @@

    Haskell

    Python

    @@ -96,12 +96,12 @@

    JavaScript

    From 2b6e2013ef0309896c9d8a9601ca490649e6c6ec Mon Sep 17 00:00:00 2001 From: Nick Lombard Date: Mon, 10 Dec 2012 21:51:08 +0200 Subject: [PATCH 0178/1659] Remove misaligned amazement json schema has been extensively adopted lets reflect that by not being all wow theres one for C. --- implementations.html | 3 --- 1 file changed, 3 deletions(-) diff --git a/implementations.html b/implementations.html index 20457154..16d16273 100644 --- a/implementations.html +++ b/implementations.html @@ -32,9 +32,6 @@

    Preliminary note

    C

    - -

    Yes, there is one:

    - From 2593599bc0ae90e29ed6e3063390e2bc75b61828 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Mon, 17 Dec 2012 12:26:53 +0100 Subject: [PATCH 0179/1659] Bring schema JSON files in conformity with the draft text --- address | 30 ++-- calendar | 74 +++++----- draft-03/hyper-schema | 101 ++++++-------- draft-03/json-ref | 45 +++--- draft-03/links | 64 ++++----- geo | 12 +- hyper-schema | 147 ++++++-------------- hyper-schema-or-uri | 10 -- json-ref | 43 +++--- links | 63 ++++----- schema | 309 +++++++++++++++++++++++------------------- 11 files changed, 414 insertions(+), 484 deletions(-) delete mode 100644 hyper-schema-or-uri diff --git a/address b/address index c1746b44..3470d74d 100644 --- a/address +++ b/address @@ -1,17 +1,17 @@ { - "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" - } + "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" + } } diff --git a/calendar b/calendar index 4de97790..68f6f072 100644 --- a/calendar +++ b/calendar @@ -1,41 +1,37 @@ { - "description": "A representation of an event", - "type": "object", - "properties": { - "dtstart": { - "format": "date-time", - "type": "string", - "description": "Event starting time", - "required": true - }, - "dtend": { - "format": "date-time", - "type": "string", - "description": "Event ending time" - }, - "summary": { "type": "string", "required": true }, - "location": { "type": "string" }, - "url": { "type": "string", "format": "uri" }, - "duration": { - "format": "time", - "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/geo" } - } + "description": "A representation of an event", + "type": "object", + "properties": { + "dtstart": { + "format": "date-time", + "type": "string", + "description": "Event starting time", + "required": true + }, + "dtend": { + "format": "date-time", + "type": "string", + "description": "Event ending time" + }, + "summary": { "type": "string", "required": true }, + "location": { "type": "string" }, + "url": { "type": "string", "format": "uri" }, + "duration": { + "format": "time", + "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/geo" } + } } - - - - diff --git a/draft-03/hyper-schema b/draft-03/hyper-schema index 623055c3..0446f1f5 100644 --- a/draft-03/hyper-schema +++ b/draft-03/hyper-schema @@ -1,60 +1,45 @@ { - "$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" + "$schema": "http://json-schema.org/draft-03/hyper-schema#", + "id": "http://json-schema.org/draft-03/hyper-schema#", + "extends": { "$ref": "http://json-schema.org/draft-03/schema#" }, + "properties": { + "links": { + "type": "array", + "items": { "$ref": "http://json-schema.org/draft-03/links#" } + }, + "fragmentResolution": { + "type": "string", + "default": "slash-delimited" + }, + "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" } diff --git a/draft-03/json-ref b/draft-03/json-ref index 7e491a8e..bbafa591 100644 --- a/draft-03/json-ref +++ b/draft-03/json-ref @@ -1,26 +1,21 @@ { - "$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 + "$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": "slash-delimited" +} diff --git a/draft-03/links b/draft-03/links index 6b0a85a6..96a9a088 100644 --- a/draft-03/links +++ b/draft-03/links @@ -1,35 +1,31 @@ { - "$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 + "$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 + }, + "rel": { + "type": "string", + "required": true + }, + "targetSchema": { "$ref": "http://json-schema.org/draft-03/hyper-schema#" }, + "method": { + "type": "string", + "default": "GET" + }, + "enctype": { + "type": "string" + }, + "schema": { + "type": "object", + "additionalProperties": { "$ref": "http://json-schema.org/draft-03/hyper-schema#" } + } + }, + "dependencies": { + "enctype": "method" + } +} diff --git a/geo b/geo index b472c4e1..05345b2b 100644 --- a/geo +++ b/geo @@ -1,8 +1,8 @@ { - "description": "A geographical coordinate", - "type": "object", - "properties": { - "latitude": { "type": "number" }, - "longitude": { "type": "number" } - } + "description": "A geographical coordinate", + "type": "object", + "properties": { + "latitude": { "type": "number" }, + "longitude": { "type": "number" } + } } diff --git a/hyper-schema b/hyper-schema index 49e89e2a..0446f1f5 100644 --- a/hyper-schema +++ b/hyper-schema @@ -1,106 +1,45 @@ { - "id": "http://json-schema.org/hyper-schema", - - "properties": { - "links": { - "type": "array", - "items": { "$ref": "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" - }, - - "alternate": { - "type": "array", - "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" } - }, - - "type": { - "type": [ "string", "array" ], - "items": { - "type": [ "string", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ] - }, - "uniqueItems": true, - "default": "any" - }, - - "properties": { - "type": "object", - "additionalProperties": { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, - "default": {} - }, - - "items": { - "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "array" ], - "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, - "default": {} - }, - "additionalProperties": { - "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "boolean" ], - "default": {} - }, - "additionalItems": { - "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "boolean" ], - "default": {} - }, - "contentEncoding": { - "type": "string" - }, - - "default": { - }, - - "requires": { - "type": [ "string", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ] - }, - "disallow": { - "type": [ "string", "array", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ], - "items": { - "type": [ "string", { "$ref": "http://json-schema.org/hyper-schema-or-uri" } ] - }, - "uniqueItems": true - }, - "extends": { - "type": [ { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, "array"], - "items": { "$ref": "http://json-schema.org/hyper-schema-or-uri" }, - "default": {} - } - - }, - - "links": [ - { - "href": "{$schema}", - "rel": "describedby" - }, - - { - "href": "{$ref}", - "rel": "full" - } - ], - - "fragmentResolution": "dot-delimited", - "extends": { "$ref": "http://json-schema.org/schema" } + "$schema": "http://json-schema.org/draft-03/hyper-schema#", + "id": "http://json-schema.org/draft-03/hyper-schema#", + "extends": { "$ref": "http://json-schema.org/draft-03/schema#" }, + "properties": { + "links": { + "type": "array", + "items": { "$ref": "http://json-schema.org/draft-03/links#" } + }, + "fragmentResolution": { + "type": "string", + "default": "slash-delimited" + }, + "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" } diff --git a/hyper-schema-or-uri b/hyper-schema-or-uri deleted file mode 100644 index 506dd1cc..00000000 --- a/hyper-schema-or-uri +++ /dev/null @@ -1,10 +0,0 @@ -{ - "id": "http://json-schema.org/hyper-schema-or-uri", - "type": [ - { - "type": "string", - "links": [ { "rel": "full", "href": "{@}" } ] - }, - { "$ref": "http://json-schema.org/hyper-schema" } - ] -} diff --git a/json-ref b/json-ref index 0c616021..bbafa591 100644 --- a/json-ref +++ b/json-ref @@ -1,26 +1,21 @@ { - "$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": "json-pointer" + "$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": "slash-delimited" } diff --git a/links b/links index 27041005..96a9a088 100644 --- a/links +++ b/links @@ -1,34 +1,31 @@ { - "$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 + "$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 + }, + "rel": { + "type": "string", + "required": true + }, + "targetSchema": { "$ref": "http://json-schema.org/draft-03/hyper-schema#" }, + "method": { + "type": "string", + "default": "GET" + }, + "enctype": { + "type": "string" + }, + "schema": { + "type": "object", + "additionalProperties": { "$ref": "http://json-schema.org/draft-03/hyper-schema#" } + } + }, + "dependencies": { + "enctype": "method" + } +} diff --git a/schema b/schema index dd0d1cee..7a1a2d38 100644 --- a/schema +++ b/schema @@ -1,137 +1,174 @@ { - "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 + "$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", { "$ref": "#" } ] + }, + "uniqueItems": true, + "default": "any" + }, + + "properties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} + }, + + "patternProperties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} + }, + + "additionalProperties": { + "type": [ { "$ref": "#" }, "boolean" ], + "default": {} + }, + + "items": { + "type": [ { "$ref": "#" }, "array" ], + "items": { "$ref": "#" }, + "default": {} + }, + + "additionalItems": { + "type": [ { "$ref": "#" }, "boolean" ], + "default": {} + }, + + "required": { + "type": "boolean", + "default": false + }, + + "dependencies": { + "type": "object", + "additionalProperties": { + "type": [ "string", "array", { "$ref": "#" } ], + "items": { + "type": "string" + } + }, + "default": {} + }, + + "minimum": { + "type": "number" + }, + + "maximum": { + "type": "number" + }, + + "exclusiveMinimum": { + "type": "boolean", + "default": false + }, + + "exclusiveMaximum": { + "type": "boolean", + "default": false + }, + + "minItems": { + "type": "integer", + "minimum": 0, + "default": 0 + }, + + "maxItems": { + "type": "integer", + "minimum": 0 + }, + + "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 + }, + + "default": { + "type": "any" + }, + + "title": { + "type": "string" + }, + + "description": { + "type": "string" + }, + + "format": { + "type": "string" + }, + + "divisibleBy": { + "type": "number", + "minimum": 0, + "exclusiveMinimum": true, + "default": 1 + }, + + "disallow": { + "type": [ "string", "array" ], + "items": { + "type": [ "string", { "$ref": "#" } ] + }, + "uniqueItems": true + }, + + "extends": { + "type": [ { "$ref": "#" }, "array" ], + "items": { "$ref": "#" }, + "default": {} + }, + + "id": { + "type": "string", + "format": "uri" + }, + + "$ref": { + "type": "string", + "format": "uri" + }, + + "$schema": { + "type": "string", + "format": "uri" + } + }, + + "dependencies": { + "exclusiveMinimum": "minimum", + "exclusiveMaximum": "maximum" + }, + + "default": {} +} From a96cb64a70bfe1234a05cb7401dab3d849acde8f Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 04:20:22 +0200 Subject: [PATCH 0180/1659] Successfully verified --- google09cd80b591ceeb46.html | 1 - 1 file changed, 1 deletion(-) delete mode 100644 google09cd80b591ceeb46.html diff --git a/google09cd80b591ceeb46.html b/google09cd80b591ceeb46.html deleted file mode 100644 index abe96859..00000000 --- a/google09cd80b591ceeb46.html +++ /dev/null @@ -1 +0,0 @@ -google-site-verification: google09cd80b591ceeb46.html \ No newline at end of file From 3b34df9c2c19b09d22cdcb6a9f85892e4c122869 Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 04:53:25 +0200 Subject: [PATCH 0181/1659] Add google analytics and link ids --- implementations.html | 52 ++++++++++++++++++++++++++++---------------- index.html | 42 +++++++++++++++++++++++------------ 2 files changed, 61 insertions(+), 33 deletions(-) diff --git a/implementations.html b/implementations.html index 16d16273..582831ef 100644 --- a/implementations.html +++ b/implementations.html @@ -33,26 +33,26 @@

    Preliminary note

    C

    Java

    .NET

    ActionScript 3

    Haskell

    @@ -60,14 +60,14 @@

    Haskell

    If that is not proof that JSON Schema is language agnostic, I don't know what is.

    Python

    @@ -77,29 +77,29 @@

    Python

    Ruby

    PHP

    JavaScript

    @@ -107,6 +107,20 @@

    JavaScript

    + diff --git a/index.html b/index.html index ac08fcd2..84276898 100644 --- a/index.html +++ b/index.html @@ -31,60 +31,74 @@

    What is JSON Schema

    Existing IETF drafts

    -

    The latest IETF published draft to date can be found The latest IETF published draft to date can be found here. It is in the process of being updated.

    JSON Schema also uses two other specifications:

    Implementations

    -

    A list of JSON Schema implementations can be found here.

    +

    A list of JSON Schema implementations can be found here.

    Discussion

    -

    Discussion about usage and development of JSON Schema can be found at the Discussion about usage and development of JSON Schema can be found at the json-schema google group.

    Contributing

    JSON Schema as a whole (this site, the specifications, and related projects) -can be found on GitHub. +can be found on GitHub. Feature/pull requests are welcome.

    Schemas

    The following are schemas that are available for referencing (more to come):

    -
    Core Meta-Schema
    This is the meta-schema +
    Core Meta-Schema
    This is the meta-schema definition for schemas themselves (the type/validation part of schemas).
    -
    Hyper Meta-Schema
    This is the extended +
    Hyper Meta-Schema
    This is the extended full meta-schema definition for schemas with link definitions (hyper schemas).
    -
    JSON Referencing
    This is the schema that +
    JSON Referencing
    This is the schema that defines a generic linking mechanism called JSON referencing (which is used by the meta-schema for links).
    -
    JSON Schema Interfaces
    This is the +
    JSON Schema Interfaces
    This is the meta-schema definition for schemas which define class-style method interfaces for programming languages.
    -
    Geographic Coordinate
     
    -
    Card
    A schema for microformat style +
    Geographic Coordinate
     
    +
    Card
    A schema for microformat style representation of a person, company, organization, or place.
    -
    Calendar
    A schema for microformat style +
    Calendar
    A schema for microformat style representation of an event.
    -
    Address
    A schema for microformat style +
    Address
    A schema for microformat style representation of an address.

    + From b68e718ad50efc7ba5de262d53cd02fccd0f6293 Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 04:58:30 +0200 Subject: [PATCH 0182/1659] google analytics required in head --- implementations.html | 27 ++++++++++++--------------- index.html | 31 ++++++++++++++----------------- 2 files changed, 26 insertions(+), 32 deletions(-) diff --git a/implementations.html b/implementations.html index 582831ef..f458044f 100644 --- a/implementations.html +++ b/implementations.html @@ -3,6 +3,18 @@ JSON Schema Implementations + @@ -107,20 +119,5 @@

    JavaScript

    - diff --git a/index.html b/index.html index 84276898..add4dd2b 100644 --- a/index.html +++ b/index.html @@ -1,7 +1,19 @@ -JSON Schema - + JSON Schema + +
    @@ -85,20 +97,5 @@

    Schemas

    - From 86177fb56dfe103ea8a9fdcba387aff757fb6b75 Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 05:15:08 +0200 Subject: [PATCH 0183/1659] Analytics: try try again. WTF Google? --- index.html | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index add4dd2b..ce8d0e61 100644 --- a/index.html +++ b/index.html @@ -2,18 +2,6 @@ JSON Schema -
    @@ -97,5 +85,19 @@

    Schemas

    + + From ca0c398c65f49af63ae697bb42532548069c21f4 Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 06:02:02 +0200 Subject: [PATCH 0184/1659] google analytics again from scratch --- implementations.html | 7 ++++--- index.html | 26 +++++++++++++------------- 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/implementations.html b/implementations.html index f458044f..88f549b8 100644 --- a/implementations.html +++ b/implementations.html @@ -4,16 +4,17 @@ JSON Schema Implementations diff --git a/index.html b/index.html index ce8d0e61..921c53b9 100644 --- a/index.html +++ b/index.html @@ -2,6 +2,19 @@ JSON Schema +
    @@ -86,18 +99,5 @@

    Schemas

    - From 6f7c446540f4edb2fd2f6fece8b784cb53a38981 Mon Sep 17 00:00:00 2001 From: nickl- Date: Wed, 19 Dec 2012 06:28:53 +0200 Subject: [PATCH 0185/1659] google analytics reenable enhanced link atts --- implementations.html | 2 ++ index.html | 2 ++ 2 files changed, 4 insertions(+) diff --git a/implementations.html b/implementations.html index 88f549b8..c5f927ae 100644 --- a/implementations.html +++ b/implementations.html @@ -6,6 +6,8 @@ + +

    The above schema has a description saying we are going to describe a product, a type saying our product is a JSON object (versus a simple datapoint like a string/number), and a propertiessection for describing the data in that object.

    + +

    Next let's answer our previous questions about this API, starting with id.

    + +

    What is id?

    +

    id is a numeric value that uniquely identifies a product. Since this is the canonical identifier for a product, it doesn't make sense to have a product without one, so it is required.

    + +

    In JSON Schema terms, we can update our schema to:

    + + +

    Is name required?

    +

    name is a string value that describes a product. Since there isn't much to a product, it also is required. Adding this gives us the schema:

    + + + +

    Can price be 0?

    +

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum, and by default minimum is exclusive of the minimum value. Therefore we can update our schema with price:

    + + + +

    Are all tags strings?

    +

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. Since required is an optional attribute of a propery (ironically), we can leave it out of the tags definition, giving us:

    + + + +

    Example summary

    +

    The above example is by no means definitive of all the types of data JSON schema can define. For more definitive information see the full standard draft.

    + +

    As a final example, here's a spec for an array of products, with the products having 2 new properties. The first is a dimensions property for the size of the product, and the second is a warehouseLocation field for where the warehouse that stores them is geographically located.

    + +

    And also, since JSON Schema defines a reference schema for a geographic location, instead of coming up with our own, we'll reference the canonical one.

    + +

    Set of products:

    + + +

    Set of products schema:

    + + + + + + + + + diff --git a/index.html b/index.html index ade62977..cc8297f0 100644 --- a/index.html +++ b/index.html @@ -32,8 +32,33 @@

    JSON Schema

    What is JSON Schema

    -

    JSON Schema is a proposed Internet draft defining a JSON media type -(application/schema+json) with the following goals:

    +

    JSON Schema is a JSON based format for describing JSON data. JSON Schema is to JSON as XSD is to XML.

    + +

    JSON Schema by example

    + +

    Let's pretend we're interacting with a JSON based product catalog. This catalog has a product which has an id, a name, a price, and an optional set of tags. +

    + +

    Example JSON data for a product API

    +

    An example product in this API is:

    + +
    {
    +  "id": 1,
    +  "name": "A green door",
    +  "price": 12.50,
    +  "tags": ["home", "green"]
    +}
    + +

    While generally straightforward, that example leaves some open questions. For example, one may ask:

    + +
      +
    • What is id?
    • +
    • Is name required?
    • +
    • Can price be 0?
    • +
    • Are all tags strings?
    • +
    + +

    When you're talking about a data format, you want to have metadata about what fields mean, and what valid inputs for those fields are. JSON schema is a specification for standardizing how to answer those questions for JSON data. Specifically, JSON Schema is a draft media type (application/schema+json) with the following goals:

    Validation
    You can use JSON Schema to validate your JSON data.
    @@ -44,19 +69,20 @@

    What is JSON Schema

    Schema to build hyperlinks into parts of that JSON data.
    -

    Existing IETF drafts

    +

    JSON Schema standard draft

    -

    The latest IETF published draft to date can be found here. It is in -the process of being updated.

    +

    The latest IETF published draft is v3. While not yet published, +v4 + of the draft is being updated on github.

    JSON Schema also uses two other specifications:

    Implementations

    @@ -75,7 +101,7 @@

    Contributing

    can be found on GitHub. Feature/pull requests are welcome.

    -

    Schemas

    +

    Reference schemas

    The following are schemas that are available for referencing (more to come):

    Core Meta-Schema
    This is the meta-schema From f237800be655a30d2a582092647e46ceb50d04be Mon Sep 17 00:00:00 2001 From: Richie Vos Date: Tue, 4 Dec 2012 00:08:57 -0600 Subject: [PATCH 0188/1659] Additional example content Add a $ref example Added sample data to examples More elaborate explanations --- examples.html | 20 ++++++++++++++++++++ index.html | 30 +++++------------------------- 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/examples.html b/examples.html index 71b27278..ec498127 100644 --- a/examples.html +++ b/examples.html @@ -15,6 +15,26 @@

    JSON Schema Examples

    +

    JSON Schema by example

    + +

    Let's pretend we're interacting with a JSON based product catalog. This catalog has a product which has an id, a name, a price, and an optional set of tags. +

    + +

    Example JSON data for a product API

    +

    An example product in this API is:

    + + + +

    While generally straightforward, that example leaves some open questions. For example, one may ask:

    + +
      +
    • What is id?
    • +
    • Is name required?
    • +
    • Can price be 0?
    • +
    • Are all tags strings?
    • +
    + +

    When you're talking about a data format, you want to have metadata about what fields mean, and what valid inputs for those fields are. JSON schema is a specification for standardizing how to answer those questions for JSON data.

    Example schema for the product API

    To start a schema definition, let's begin with a basic to JSON schema.

    diff --git a/index.html b/index.html index cc8297f0..ddef6251 100644 --- a/index.html +++ b/index.html @@ -34,31 +34,7 @@

    What is JSON Schema

    JSON Schema is a JSON based format for describing JSON data. JSON Schema is to JSON as XSD is to XML.

    -

    JSON Schema by example

    - -

    Let's pretend we're interacting with a JSON based product catalog. This catalog has a product which has an id, a name, a price, and an optional set of tags. -

    - -

    Example JSON data for a product API

    -

    An example product in this API is:

    - -
    {
    -  "id": 1,
    -  "name": "A green door",
    -  "price": 12.50,
    -  "tags": ["home", "green"]
    -}
    - -

    While generally straightforward, that example leaves some open questions. For example, one may ask:

    - -
      -
    • What is id?
    • -
    • Is name required?
    • -
    • Can price be 0?
    • -
    • Are all tags strings?
    • -
    - -

    When you're talking about a data format, you want to have metadata about what fields mean, and what valid inputs for those fields are. JSON schema is a specification for standardizing how to answer those questions for JSON data. Specifically, JSON Schema is a draft media type (application/schema+json) with the following goals:

    +

    JSON Schema is a proposed Internet draft defining a JSON media type (application/schema+json) with the following goals:

    Validation
    You can use JSON Schema to validate your JSON data.
    @@ -68,6 +44,10 @@

    Example JSON data for a product API

    Hyperlinking
    You can pair your JSON data with the defining JSON Schema to build hyperlinks into parts of that JSON data.
    +

    JSON Schema by example

    + +

    Let's pretend we're interacting with a JSON based product catalog. This catalog has a... + continue to the examples page to read more...

    JSON Schema standard draft

    From cd4c791b3cc51359faa1a808cdc651d112426184 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Fri, 21 Dec 2012 20:42:44 +0100 Subject: [PATCH 0189/1659] Rename schema-core.json to schema --- proposals/{schema-core.json => schema} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{schema-core.json => schema} (100%) diff --git a/proposals/schema-core.json b/proposals/schema similarity index 100% rename from proposals/schema-core.json rename to proposals/schema From a61df5ac47a3105ad3d552f0b8ec51d8998bac06 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Fri, 21 Dec 2012 20:56:11 +0100 Subject: [PATCH 0190/1659] Validation spec: introduce "definitions" keyword "definitions" is a standardized container for inlined schemas. --- proposals/json-schema-validation.txt | 256 ++++++++++++++++----------- proposals/json-schema-validation.xml | 42 +++++ proposals/schema | 39 ++-- 3 files changed, 220 insertions(+), 117 deletions(-) diff --git a/proposals/json-schema-validation.txt b/proposals/json-schema-validation.txt index 0eb5d791..28aa78d4 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 December 17, 2012 +Internet-Draft December 21, 2012 Intended status: Informational -Expires: June 20, 2013 +Expires: June 24, 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 June 20, 2013. + This Internet-Draft will expire on June 24, 2013. Copyright Notice @@ -52,7 +52,7 @@ Copyright Notice -Galiegue Expires June 20, 2013 [Page 1] +Galiegue Expires June 24, 2013 [Page 1] Internet-Draft JSON Schema December 2012 @@ -102,46 +102,47 @@ Table of Contents 5.5.4. anyOf . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5.5. oneOf . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5.6. not . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 17 - 6.1. "title" and "description" . . . . . . . . . . . . . . . . 17 - 6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17 + 5.5.7. definitions . . . . . . . . . . . . . . . . . . . . . 17 + 6. Metadata keywords . . . . . . . . . . . . . . . . . . . . . . 18 + 6.1. "title" and "description" . . . . . . . . . . . . . . . . 18 -Galiegue Expires June 20, 2013 [Page 2] +Galiegue Expires June 24, 2013 [Page 2] Internet-Draft JSON Schema December 2012 - 6.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2. "default" . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.2.1. Valid values . . . . . . . . . . . . . . . . . . . . . 17 + 6.1.1. Valid values . . . . . . . . . . . . . . . . . . . . . 18 + 6.1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . . . . . . . . . . . . . 18 + 7.2. Implementation requirements . . . . . . . . . . . . . . . 19 + 7.3. Defined attributes . . . . . . . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.3.3. hostname . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.3.4. ipv4 . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 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. Calculating child instances' schema(s) . . . . . . . . . . . . 21 + 8.1. Foreword . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2. Array elements . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2.1. Defining characteristic . . . . . . . . . . . . . . . 21 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. Object values . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3.1. Defining characteristic . . . . . . . . . . . . . . . 22 + 8.3.2. Implied keywords . . . . . . . . . . . . . . . . . . . 22 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 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 24 @@ -163,8 +164,7 @@ Internet-Draft JSON Schema December 2012 - -Galiegue Expires June 20, 2013 [Page 3] +Galiegue Expires June 24, 2013 [Page 3] Internet-Draft JSON Schema December 2012 @@ -220,7 +220,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 4] +Galiegue Expires June 24, 2013 [Page 4] Internet-Draft JSON Schema December 2012 @@ -276,7 +276,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 5] +Galiegue Expires June 24, 2013 [Page 5] Internet-Draft JSON Schema December 2012 @@ -332,7 +332,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 6] +Galiegue Expires June 24, 2013 [Page 6] Internet-Draft JSON Schema December 2012 @@ -388,7 +388,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 7] +Galiegue Expires June 24, 2013 [Page 7] Internet-Draft JSON Schema December 2012 @@ -444,7 +444,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 8] +Galiegue Expires June 24, 2013 [Page 8] Internet-Draft JSON Schema December 2012 @@ -500,7 +500,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 9] +Galiegue Expires June 24, 2013 [Page 9] Internet-Draft JSON Schema December 2012 @@ -556,7 +556,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 10] +Galiegue Expires June 24, 2013 [Page 10] Internet-Draft JSON Schema December 2012 @@ -612,7 +612,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 11] +Galiegue Expires June 24, 2013 [Page 11] Internet-Draft JSON Schema December 2012 @@ -668,7 +668,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 12] +Galiegue Expires June 24, 2013 [Page 12] Internet-Draft JSON Schema December 2012 @@ -724,7 +724,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 13] +Galiegue Expires June 24, 2013 [Page 13] Internet-Draft JSON Schema December 2012 @@ -780,7 +780,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 14] +Galiegue Expires June 24, 2013 [Page 14] Internet-Draft JSON Schema December 2012 @@ -836,7 +836,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 15] +Galiegue Expires June 24, 2013 [Page 15] Internet-Draft JSON Schema December 2012 @@ -892,7 +892,7 @@ Internet-Draft JSON Schema December 2012 -Galiegue Expires June 20, 2013 [Page 16] +Galiegue Expires June 24, 2013 [Page 16] Internet-Draft JSON Schema December 2012 @@ -918,6 +918,45 @@ Internet-Draft JSON Schema December 2012 An instance is valid against this keyword if and only if it fails to validate successfully against the schema defined by this keyword. +5.5.7. definitions + +5.5.7.1. Valid values + + This keyword's value MUST be an object. Each member value of this + object MUST be a valid JSON Schema. + +5.5.7.2. Conditions for successful validation + + This keyword plays no role in validation per se. Its role is to + provide a standardized location for schema authors to inline JSON + Schemas into a more general schema. + + As an example, here is a schema describing an array of positive + integers, where the positive integer constraint is a subschema in + "definitions": + + + { + "type": "array", + "items": { "$ref": "#/definitions/positiveInteger" }, + "definitions": { + "positiveInteger": { + "type": "integer", + "minimum": 0, + "exclusiveMinimum": true + } + + + +Galiegue Expires June 24, 2013 [Page 17] + +Internet-Draft JSON Schema December 2012 + + + } + } + + 6. Metadata keywords 6.1. "title" and "description" @@ -943,16 +982,6 @@ Internet-Draft JSON Schema December 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 @@ -972,6 +1001,14 @@ Internet-Draft JSON Schema December 2012 authoritative resources, be they RFCs or other external specifications. + + + +Galiegue Expires June 24, 2013 [Page 18] + +Internet-Draft JSON Schema December 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,16 +1036,6 @@ Internet-Draft JSON Schema December 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 @@ -1027,6 +1054,17 @@ Internet-Draft JSON Schema December 2012 is a valid Internet email address as defined by RFC 5322, section 3.4.1 [RFC5322]. + + + + + + +Galiegue Expires June 24, 2013 [Page 19] + +Internet-Draft JSON Schema December 2012 + + 7.3.3. hostname 7.3.3.1. Applicability @@ -1054,17 +1092,6 @@ Internet-Draft JSON Schema December 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. @@ -1086,6 +1113,14 @@ Internet-Draft JSON Schema December 2012 A string instance is valid against this attribute if and only if it is a valid URI, according to [RFC3986]. + + + +Galiegue Expires June 24, 2013 [Page 20] + +Internet-Draft JSON Schema December 2012 + + 8. Calculating child instances' schema(s) 8.1. Foreword @@ -1111,16 +1146,6 @@ Internet-Draft JSON Schema December 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 @@ -1143,6 +1168,15 @@ Internet-Draft JSON Schema December 2012 In this situation, the schema depends on the index of the child instance: + + + + +Galiegue Expires June 24, 2013 [Page 21] + +Internet-Draft JSON Schema December 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; @@ -1170,13 +1204,6 @@ Internet-Draft JSON Schema December 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 @@ -1197,6 +1224,15 @@ Internet-Draft JSON Schema December 2012 If set "p" contains value "m", then the corresponding schema in "properties" is added to "s". + + + + +Galiegue Expires June 24, 2013 [Page 22] + +Internet-Draft JSON Schema December 2012 + + 8.3.3.3. Second step: schemas in "patternProperties" For each regex in "pp", if it matches "m" successfully, the @@ -1226,13 +1262,6 @@ Internet-Draft JSON Schema December 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. @@ -1253,6 +1282,13 @@ Internet-Draft JSON Schema December 2012 www.ecma-international.org/publications/files/ECMA-ST/ Ecma-262.pdf>. + + +Galiegue Expires June 24, 2013 [Page 23] + +Internet-Draft JSON Schema December 2012 + + Appendix A. ChangeLog TODO @@ -1284,5 +1320,25 @@ Author's Address -Galiegue Expires June 20, 2013 [Page 23] + + + + + + + + + + + + + + + + + + + + +Galiegue Expires June 24, 2013 [Page 24] diff --git a/proposals/json-schema-validation.xml b/proposals/json-schema-validation.xml index ebeee8a4..7ce8036d 100644 --- a/proposals/json-schema-validation.xml +++ b/proposals/json-schema-validation.xml @@ -948,6 +948,48 @@
    + +
    + +
    + + This keyword's value MUST be an object. Each member value of this object + MUST be a valid JSON Schema. + +
    + +
    + + This keyword plays no role in validation per se. Its role is to provide + a standardized location for schema authors to inline JSON Schemas into a + more general schema. + + + + As an example, here is a schema describing an array of positive + integers, where the positive integer constraint is a subschema in + "definitions": + +
    + + + +
    +
    +
    +
    diff --git a/proposals/schema b/proposals/schema index f7ecbf12..85eb502a 100644 --- a/proposals/schema +++ b/proposals/schema @@ -2,7 +2,7 @@ "id": "http://json-schema.org/draft-04/schema#", "$schema": "http://json-schema.org/draft-04/schema#", "description": "Core schema meta-schema", - "common": { + "definitions": { "schemaArray": { "type": "array", "minItems": 1, @@ -13,7 +13,7 @@ "minimum": 0 }, "positiveIntegerDefault0": { - "allOf": [ { "$ref": "#/common/positiveInteger" }, { "default": 0 } ] + "allOf": [ { "$ref": "#/definitions/positiveInteger" }, { "default": 0 } ] }, "simpleTypes": { "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ] @@ -61,8 +61,8 @@ "type": "boolean", "default": false }, - "maxLength": { "$ref": "#/common/positiveInteger" }, - "minLength": { "$ref": "#/common/positiveIntegerDefault0" }, + "maxLength": { "$ref": "#/definitions/positiveInteger" }, + "minLength": { "$ref": "#/definitions/positiveIntegerDefault0" }, "pattern": { "type": "string", "format": "regex" @@ -77,19 +77,19 @@ "items": { "anyOf": [ { "$ref": "#" }, - { "$ref": "#/common/schemaArray" } + { "$ref": "#/definitions/schemaArray" } ], "default": {} }, - "maxItems": { "$ref": "#/common/positiveInteger" }, - "minItems": { "$ref": "#/common/positiveIntegerDefault0" }, + "maxItems": { "$ref": "#/definitions/positiveInteger" }, + "minItems": { "$ref": "#/definitions/positiveIntegerDefault0" }, "uniqueItems": { "type": "boolean", "default": false }, - "maxProperties": { "$ref": "#/common/positiveInteger" }, - "minProperties": { "$ref": "#/common/positiveIntegerDefault0" }, - "required": { "$ref": "#/common/stringArray" }, + "maxProperties": { "$ref": "#/definitions/positiveInteger" }, + "minProperties": { "$ref": "#/definitions/positiveIntegerDefault0" }, + "required": { "$ref": "#/definitions/stringArray" }, "additionalProperties": { "anyOf": [ { "type": "boolean" }, @@ -97,7 +97,7 @@ ], "default": {} }, - "patternProperties": { + "definitions": { "type": "object", "additionalProperties": { "$ref": "#" }, "default": {} @@ -107,12 +107,17 @@ "additionalProperties": { "$ref": "#" }, "default": {} }, + "patternProperties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} + }, "dependencies": { "type": "object", "additionalProperties": { "anyOf": [ { "$ref": "#" }, - { "$ref": "#/common/stringArray" } + { "$ref": "#/definitions/stringArray" } ] } }, @@ -123,18 +128,18 @@ }, "type": { "anyOf": [ - { "$ref": "#/common/simpleTypes" }, + { "$ref": "#/definitions/simpleTypes" }, { "type": "array", - "items": { "$ref": "#/common/simpleTypes" }, + "items": { "$ref": "#/definitions/simpleTypes" }, "minItems": 1, "uniqueItems": true } ] }, - "allOf": { "$ref": "#/common/schemaArray" }, - "anyOf": { "$ref": "#/common/schemaArray" }, - "oneOf": { "$ref": "#/common/schemaArray" }, + "allOf": { "$ref": "#/definitions/schemaArray" }, + "anyOf": { "$ref": "#/definitions/schemaArray" }, + "oneOf": { "$ref": "#/definitions/schemaArray" }, "not": { "$ref": "#" } }, "dependencies": { From 9fcd835d36b9b9d92e4b7fe3af62e6cb8410c701 Mon Sep 17 00:00:00 2001 From: Geraint Luff Date: Sat, 5 Jan 2013 09:28:48 +0000 Subject: [PATCH 0191/1659] Put an example on the main page --- index.html | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index ddef6251..5e3d4457 100644 --- a/index.html +++ b/index.html @@ -46,8 +46,11 @@

    What is JSON Schema

    JSON Schema by example

    -

    Let's pretend we're interacting with a JSON based product catalog. This catalog has a... - continue to the examples page to read more...

    +

    Here is a basic example of a JSON Schema: + + + +

    For more examples, see the examples page.

    JSON Schema standard draft

    From 1746c7282a191eef2b1745e58dd86748abfffc85 Mon Sep 17 00:00:00 2001 From: Geraint Luff Date: Sat, 5 Jan 2013 09:53:57 +0000 Subject: [PATCH 0192/1659] Update examples to draft v4 --- examples.html | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/examples.html b/examples.html index ec498127..4f8b9e28 100644 --- a/examples.html +++ b/examples.html @@ -23,7 +23,7 @@

    JSON Schema by example

    Example JSON data for a product API

    An example product in this API is:

    - +

    While generally straightforward, that example leaves some open questions. For example, one may ask:

    @@ -38,7 +38,7 @@

    Example JSON data for a product API

    Example schema for the product API

    To start a schema definition, let's begin with a basic to JSON schema.

    - +

    The above schema has a description saying we are going to describe a product, a type saying our product is a JSON object (versus a simple datapoint like a string/number), and a propertiessection for describing the data in that object.

    @@ -48,22 +48,22 @@

    What is id?

    id is a numeric value that uniquely identifies a product. Since this is the canonical identifier for a product, it doesn't make sense to have a product without one, so it is required.

    In JSON Schema terms, we can update our schema to:

    - +

    Is name required?

    name is a string value that describes a product. Since there isn't much to a product, it also is required. Adding this gives us the schema:

    - +

    Can price be 0?

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum, and by default minimum is exclusive of the minimum value. Therefore we can update our schema with price:

    - +

    Are all tags strings?

    -

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. Since required is an optional attribute of a propery (ironically), we can leave it out of the tags definition, giving us:

    +

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    - +

    Example summary

    The above example is by no means definitive of all the types of data JSON schema can define. For more definitive information see the full standard draft.

    @@ -73,11 +73,11 @@

    Example summary

    And also, since JSON Schema defines a reference schema for a geographic location, instead of coming up with our own, we'll reference the canonical one.

    Set of products:

    - +

    Set of products schema:

    - + From 85f8eb0eaee45f2b3692ab26e8649aaeec7efcb3 Mon Sep 17 00:00:00 2001 From: Geraint Luff Date: Sat, 5 Jan 2013 09:56:53 +0000 Subject: [PATCH 0193/1659] "minimum" is inclusive by default, not exclusive --- examples.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples.html b/examples.html index 4f8b9e28..dd7dc79e 100644 --- a/examples.html +++ b/examples.html @@ -56,7 +56,7 @@

    Is name required?

    Can price be 0?

    -

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum, and by default minimum is exclusive of the minimum value. Therefore we can update our schema with price:

    +

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum. By default this minimum is inclusive, so we need to specify exclusiveMinimum. Therefore we can update our schema with price:

    From 5b24e568612a16b4de8607877110d6f9b2ae06ee Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 04:38:43 +0100 Subject: [PATCH 0194/1659] JSON Schema is nothing close to XSD Remove reference. --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index ddef6251..84215621 100644 --- a/index.html +++ b/index.html @@ -32,7 +32,7 @@

    JSON Schema

    What is JSON Schema

    -

    JSON Schema is a JSON based format for describing JSON data. JSON Schema is to JSON as XSD is to XML.

    +

    JSON Schema is a JSON based format for describing JSON data.

    JSON Schema is a proposed Internet draft defining a JSON media type (application/schema+json) with the following goals:

    From a28846d90d908dadf7d501383bef9e4811e7b7e7 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 04:39:09 +0100 Subject: [PATCH 0195/1659] Update references to JSON Reference, JSON Pointer JSON Reference: 2 -> 3 JSON Pointer: 3 -> 7 --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 84215621..54c40f54 100644 --- a/index.html +++ b/index.html @@ -59,9 +59,9 @@

    JSON Schema standard draft

    JSON Schema also uses two other specifications:

    From 99d911849996e9f4b1351435cd76c039753b42a5 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 04:48:23 +0100 Subject: [PATCH 0196/1659] Split example schemas section There are JSON Schema "official" schemas and others. --- index.html | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/index.html b/index.html index 54c40f54..997c0aea 100644 --- a/index.html +++ b/index.html @@ -82,19 +82,22 @@

    Contributing

    Feature/pull requests are welcome.

    Reference schemas

    -

    The following are schemas that are available for referencing (more to come): + +

    JSON Schema defines meta schemas. These are schemas which can be used to +validate other schemas (including themselves). Those are:

    + +
    +
    Core Meta-Schema
    Used for schemas written +for pure validation.
    +
    Hyper Meta-Schema
    Used for schemas +written for validation and hyper linking.
    +
    + +

    Sample schemas

    + +

    These sample schemas describe simple data structures which can be expressed as JSON:

    +
    -
    Core Meta-Schema
    This is the meta-schema -definition for schemas themselves (the type/validation part of schemas).
    -
    Hyper Meta-Schema
    This is the extended -full meta-schema definition for schemas with link definitions (hyper -schemas).
    -
    JSON Referencing
    This is the schema that -defines a generic linking mechanism called JSON referencing (which is used by -the meta-schema for links).
    -
    JSON Schema Interfaces
    This is the -meta-schema definition for schemas which define class-style method interfaces -for programming languages.
    Geographic Coordinate
     
    Card
    A schema for microformat style representation of a person, company, organization, or place.
    From 5c450d1df7ddab34b8ff032cb33ed75ddcca1818 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 15:03:43 +0100 Subject: [PATCH 0197/1659] examples.html: update gists * Add "$schema" everywhere. * Add "description" as well. --- examples.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/examples.html b/examples.html index dd7dc79e..be24f54f 100644 --- a/examples.html +++ b/examples.html @@ -38,7 +38,7 @@

    Example JSON data for a product API

    Example schema for the product API

    To start a schema definition, let's begin with a basic to JSON schema.

    - +

    The above schema has a description saying we are going to describe a product, a type saying our product is a JSON object (versus a simple datapoint like a string/number), and a propertiessection for describing the data in that object.

    @@ -48,22 +48,22 @@

    What is id?

    id is a numeric value that uniquely identifies a product. Since this is the canonical identifier for a product, it doesn't make sense to have a product without one, so it is required.

    In JSON Schema terms, we can update our schema to:

    - +

    Is name required?

    name is a string value that describes a product. Since there isn't much to a product, it also is required. Adding this gives us the schema:

    - +

    Can price be 0?

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum. By default this minimum is inclusive, so we need to specify exclusiveMinimum. Therefore we can update our schema with price:

    - +

    Are all tags strings?

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    - +

    Example summary

    The above example is by no means definitive of all the types of data JSON schema can define. For more definitive information see the full standard draft.

    @@ -77,7 +77,7 @@

    Set of products:

    Set of products schema:

    - + From 1462a744043e1465dc2898305c2fb32b91d55fe4 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 15:06:33 +0100 Subject: [PATCH 0198/1659] examples.html: more descriptive introduction to the first schema --- examples.html | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/examples.html b/examples.html index be24f54f..babad42e 100644 --- a/examples.html +++ b/examples.html @@ -36,11 +36,21 @@

    Example JSON data for a product API

    When you're talking about a data format, you want to have metadata about what fields mean, and what valid inputs for those fields are. JSON schema is a specification for standardizing how to answer those questions for JSON data.

    Example schema for the product API

    -

    To start a schema definition, let's begin with a basic to JSON schema.

    +

    To start a schema definition, let's begin with a basic JSON schema:

    -

    The above schema has a description saying we are going to describe a product, a type saying our product is a JSON object (versus a simple datapoint like a string/number), and a propertiessection for describing the data in that object.

    +

    The above schema has four properties called keywords. + +The title and description keywords are descriptive only, in that they do not add +constraints to the data being validated. The intent of the schema is stated with these two keywords +(that is, this schema describes a product).

    + +

    The type keyword defines the first constraint on our JSON data: it has to be a JSON +Object.

    + +

    Finally, the $schema keyword states that this schema is written according to the draft +v4 specification.

    Next let's answer our previous questions about this API, starting with id.

    From 88e00ba7a4d676becd704a2d031bb571cf480fb9 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 15:09:05 +0100 Subject: [PATCH 0199/1659] Minor changes * Add a supposedly missing . * Fix a little point of grammar. * Fix an extraneous space. Minor, I tell you. --- examples.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/examples.html b/examples.html index babad42e..7d0080dd 100644 --- a/examples.html +++ b/examples.html @@ -61,17 +61,18 @@

    What is id?

    Is name required?

    -

    name is a string value that describes a product. Since there isn't much to a product, it also is required. Adding this gives us the schema:

    +

    name is a string value that describes a product. Since there isn't +much to a product without a name, it also is required. Adding this gives us the schema:

    Can price be 0?

    -

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum. By default this minimum is inclusive, so we need to specify exclusiveMinimum. Therefore we can update our schema with price:

    +

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum. By default this minimum is inclusive, so we need to specify exclusiveMinimum. Therefore we can update our schema with price:

    Are all tags strings?

    -

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    +

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    From 7675580b9a3a45b39299b584cbd8c9e41bc2c64b Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sat, 5 Jan 2013 15:23:48 +0100 Subject: [PATCH 0200/1659] examples.html: add two constraints to tags Require that there be at least one tag, and that all tags must be unique. --- examples.html | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/examples.html b/examples.html index 7d0080dd..ea89a8e7 100644 --- a/examples.html +++ b/examples.html @@ -72,9 +72,22 @@

    Can price be 0?

    Are all tags strings?

    -

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    +

    Finally, we come to the tags property. Unlike the previous +properties, tags have many values, and is represented as a JSON array. According +to Acme's docs, all tags must be strings, but you aren't required to specify +tags. We simply leave tags out of the list of required properties.

    - +

    However, Acme's docs add two constraints:

    + +
      +
    • there must be at least one tag,
    • +
    • all tags must be unique.
    • +
    + +

    The first constraint can be added with minItems, and the second one by +specifying uniqueItems as being true:

    + +

    Example summary

    The above example is by no means definitive of all the types of data JSON schema can define. For more definitive information see the full standard draft.

    @@ -88,7 +101,7 @@

    Set of products:

    Set of products schema:

    - + From 90e1041a2fe5837225d1e4da0df9c38d777e7e28 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sun, 6 Jan 2013 17:44:37 +0100 Subject: [PATCH 0201/1659] Add a new, more complex example --- example2.html | 179 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 example2.html diff --git a/example2.html b/example2.html new file mode 100644 index 00000000..fcc7d149 --- /dev/null +++ b/example2.html @@ -0,0 +1,179 @@ + + + + Another JSON Schema example + + + +
    +
    +
    + +
    +
    +
    +
    +

    Purpose of the example

    + +

    This example shows a possible JSON representation of a hypothetical machine's mount points as +represented in an /etc/fstab file.

    + +

    An entry in the fstab file can have many different forms. Here is a possible representation of a +full fstab:

    + + + +

    Not all constraints to an fstab file can be modeled using JSON Schema alone; however, it can +already represent a good number of them. We will add constraints one after the other until we get to +a satisfactory result.

    + +

    Base schema

    + +

    We will start with a base schema expressing the following constraints:

    + +
      +
    • the list of entries is a JSON object;
    • +
    • the member names (or property names) of this object must all be valid, absolute paths;
    • +
    • there must be an entry for the root filesystem (ie, /).
    • +
    + +

    We also want the schema to be regarded as a draft v4 schema, we must therefore specify +$schema:

    + + + +

    Note how the valid paths constraint is enforced here:

    + +
      +
    • we have a properties keyword with only a / entry;
    • +
    • we use patternProperties to match other property names via a regular +expression (note that it does not match /);
    • +
    • as additionalProperties is false, it constrains object properties to be either +/ or to match the regular expression.
    • +
    + +

    You will notice that the regular expression is explicitly anchored: in JSON Schema, regular +expressions (in patternProperties and in pattern) are not anchored by default, you +must add anchors if you need them.

    + +

    For now, the schemas describing individual entries are empty: we will start describing the +constraints in the following paragraphs, using another schema, which we will reference from the main +schema when we are ready.

    + +

    The entry schema

    + +

    The skeleton

    + +

    Here again we will proceed little by little. We will start with the global structure of our +schema, which will be as such:

    + + + +

    The expressed constraints you should already be familiar with: the JSON value must be an object, and this +object must have a property by the name storage; what is more, that storage +property must be an object. There are a couple of novelties:

    + +
      +
    • you will notice the appearance of JSON References, via the $ref keyword; here, all +references used are local to the schema, and the fragment part is a URI encoded JSON Pointer;
    • +
    • you will notice the appearance of an id: this is the URI of this resource; we assume +here that this URI is the actual URI of this schema;
    • +
    • the oneOf keyword is new; its argument is an array of schemas, and the data will be +valid if and only if it validates against only one of the schemas in the array;
    • +
    • finally, the definitions keyword is a standardized placeholder in which you can define +inline subschemas to be used in a schema. +
    + +

    The fstype, options and readonly properties

    + +

    Let us now extend this skeleton to add constraints to the aforementioned properties. Note that +none of them is required:

    + +
      +
    • we only support ext3, ext4 and btrfs as filesystem types;
    • +
    • the options array only allows strings; moreover, when specified, there must be at least +one option, and all options should be unique;
    • +
    • readonly can only be a boolean.
    • +
    + +

    With these added constraints, the schema now looks like this:

    + + + +

    It is now time we filled the different storage definitions.

    + +

    The diskDevice storage type

    + +

    This storage type has two required properties, type and device. The type can +only be disk, and the device must be an absolute path starting with /dev. No other +properties are allowed:

    + + + +

    The diskUUID storage type

    + +

    This storage type has two required properties, type and label. The type can +only be disk, and the label must be a valid UUID. No other properties are allowed:

    + + + +

    The nfs storage type

    + +

    This storage type has three required properties: type, server and +remotePath. What is more, the server may be either a host name, an IPv4 address or an IPv6 +address.

    + +

    For the constraints on server, we use a new keyword: format. While it is not +required that format be supported, we will suppose that it is here:

    + + + +

    The tmpfs storage type

    + +

    This storage type has two required properties: type and sizeInMB. The size can +only be an integer. What is more, we will require that the size be between 16 and 512, +inclusive:

    + + + +

    Plugging this into our main schema

    + +

    Now that all possible entries have been described, we can refer to the entry schema from our main +schema. We will, again, use a JSON Reference here:

    + + + +

    Wrap up

    + +

    This example is much more advanced than the previous example; you will have learned of schema +referencing and identification, you will have been introduced to other keywords. It also raises some +interesting points.

    + +

    The schema can be improved

    + +

    For instance:

    + +
      +
    • it makes no sense for / to be mounted on a tmpfs filesystem;
    • +
    • it makes no sense to specify the filesystem type if the storage is either NFS or tmpfs.
    • +
    + +

    As an exercise, you can always try and add these constraints. It would probably require splitting +the schema further.

    + +

    JSON Schema limits itself to structural validation

    + +

    The format keyword is the only exception to this (with it, you can do semantic +validation of primitive types, such as strings), but supporting it is not required.

    + +

    What is more, if we take an NFS entry as an example, it would be the role of your application +code to check that the submitted NFS server's hostname, or IP address, is actually correct.

    + +
    +
    +
    + + + From 805c94ff5626507b3765a08834e70c12a0b9acd5 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Sun, 6 Jan 2013 17:51:00 +0100 Subject: [PATCH 0202/1659] Refer to the two examples in index.html Also rename examples.html to example.html. --- examples.html => example.html | 0 index.html | 9 ++++++++- 2 files changed, 8 insertions(+), 1 deletion(-) rename examples.html => example.html (100%) diff --git a/examples.html b/example.html similarity index 100% rename from examples.html rename to example.html diff --git a/index.html b/index.html index d7a394ac..2f311818 100644 --- a/index.html +++ b/index.html @@ -50,7 +50,14 @@

    JSON Schema by example

    -

    For more examples, see the examples page.

    +

    The two examples below are step-by-step guides into building a schema:

    + +
      +
    • this first example is a simple example which covers a classical +product catalog description;
    • +
    • this second example is more advanced, and uses JSON Schema to +describe filesystem entries in a Unix-like /etc/fstab file.
    • +

    JSON Schema standard draft

    From d8485e43fe2662dd0014c4bdee49a283a0d68ff9 Mon Sep 17 00:00:00 2001 From: "user@server" Date: Sun, 6 Jan 2013 20:45:45 +0000 Subject: [PATCH 0203/1659] Added custom highlighting code --- examples.html | 182 ++++++++++++++++++++++++-- index.html | 23 +++- lib/json-highlight.css | 48 +++++++ lib/json-highlight.js | 287 +++++++++++++++++++++++++++++++++++++++++ 4 files changed, 531 insertions(+), 9 deletions(-) create mode 100644 lib/json-highlight.css create mode 100644 lib/json-highlight.js diff --git a/examples.html b/examples.html index dd7dc79e..d66eab57 100644 --- a/examples.html +++ b/examples.html @@ -3,6 +3,7 @@ +
    @@ -23,7 +24,14 @@

    JSON Schema by example

    Example JSON data for a product API

    An example product in this API is:

    - +
    +{
    +    "id": 1,
    +    "name": "A green door",
    +    "price": 12.50,
    +    "tags": ["home", "green"]
    +}
    +

    While generally straightforward, that example leaves some open questions. For example, one may ask:

    @@ -38,7 +46,13 @@

    Example JSON data for a product API

    Example schema for the product API

    To start a schema definition, let's begin with a basic to JSON schema.

    - +
    +{
    +    "title": "Product",
    +    "description": "A product from Acme's catalog",
    +    "type": "object"
    +}
    +

    The above schema has a description saying we are going to describe a product, a type saying our product is a JSON object (versus a simple datapoint like a string/number), and a propertiessection for describing the data in that object.

    @@ -48,22 +62,98 @@

    What is id?

    id is a numeric value that uniquely identifies a product. Since this is the canonical identifier for a product, it doesn't make sense to have a product without one, so it is required.

    In JSON Schema terms, we can update our schema to:

    - +
    +{
    +    "title": "Product",
    +    "type": "object",
    +    "properties": {
    +        "id": {
    +            "description": "The unique identifier for a product",
    +            "type": "integer"
    +        }
    +    },
    +    "required": ["id"]
    +}
    +

    Is name required?

    name is a string value that describes a product. Since there isn't much to a product, it also is required. Adding this gives us the schema:

    - +
    +{
    +    "title": "Product",
    +    "type": "object",
    +    "properties": {
    +        "id": {
    +            "description": "The unique identifier for a product",
    +            "type": "integer"
    +        },
    +        "name": {
    +            "description": "Name of the product",
    +            "type": "string"
    +        }
    +    },
    +    "required": ["id", "name"]
    +}
    +

    Can price be 0?

    According to Acme's docs, there are no free products. In JSON schema a number can have a minimum. By default this minimum is inclusive, so we need to specify exclusiveMinimum. Therefore we can update our schema with price:

    - +
    +{
    +    "title": "Product",
    +    "type": "object",
    +    "properties": {
    +        "id": {
    +            "description": "The unique identifier for a product",
    +            "type": "integer"
    +        },
    +        "name": {
    +            "description": "Name of the product",
    +            "type": "string"
    +        },
    +        "price": {
    +            "type": "number",
    +            "minimum": 0,
    +            "exclusiveMinimum": true
    +        }
    +    },
    +    "required": ["id", "name", "price"]
    +}
    +

    Are all tags strings?

    Finally, we come to the tags property. Unlike the previous properties, tags have many values, and is represented as a JSON array. According to Acme's docs, all tags must be strings, but you aren't required to specify tags. We simply leave tags out of the list of required properties, giving us:

    - +
    +{
    +    "title": "Product",
    +    "type": "object",
    +    "properties": {
    +        "id": {
    +            "description": "The unique identifier for a product",
    +            "type": "integer"
    +        },
    +        "name": {
    +            "description": "Name of the product",
    +            "type": "string"
    +        },
    +        "price": {
    +            "type": "number",
    +            "minimum": 0,
    +            "exclusiveMinimum": true
    +        },
    +        "tags": {
    +            "type": "array",
    +            "items": {
    +                "type": "string"
    +            }
    +        }
    +    },
    +    "required": ["id", "name", "price"]
    +}
    +

    Example summary

    The above example is by no means definitive of all the types of data JSON schema can define. For more definitive information see the full standard draft.

    @@ -73,15 +163,91 @@

    Example summary

    And also, since JSON Schema defines a reference schema for a geographic location, instead of coming up with our own, we'll reference the canonical one.

    Set of products:

    - +
    +[
    +    {
    +        "id": 2,
    +        "name": "An ice sculpture",
    +        "price": 12.50,
    +        "tags": ["cold", "ice"],
    +        "dimensions": {
    +            "length": 7.0,
    +            "width": 12.0,
    +            "height": 9.5
    +        },
    +        "warehouseLocation": {
    +            "latitude": -78.75,
    +            "longitude": 20.4
    +        }
    +    },
    +    {
    +        "id": 3,
    +        "name": "A blue mouse",
    +        "price": 25.50,
    +            "dimensions": {
    +            "length": 3.1,
    +            "width": 1.0,
    +            "height": 1.0
    +        },
    +        "warehouseLocation": {
    +            "latitude": 54.4,
    +            "longitude": -32.7
    +        }
    +    }
    +]
    +

    Set of products schema:

    - +
    +{
    +    "title": "Product set",
    +    "type": "array",
    +    "items": {
    +        "title": "Product",
    +        "type": "object",
    +        "properties": {
    +            "id": {
    +                "description": "The unique identifier for a product",
    +                "type": "number"
    +            },
    +            "name": {
    +                "type": "string"
    +            },
    +            "price": {
    +                "type": "number",
    +                "minimum": 0,
    +                "exclusiveMinimum": true
    +            },
    +            "tags": {
    +                "type": "array",
    +                    "items": {
    +                    "type": "string"
    +                }
    +            },
    +            "dimensions": {
    +                "type": "object",
    +                "properties": {
    +                    "length": {"type": "number"},
    +                    "width": {"type": "number"},
    +                    "height": {"type": "number"}
    +                },
    +                "required": ["length", "width", "height"]
    +            },
    +            "warehouseLocation": {
    +                "description": "Co-ordinates of the warehouse with the product",
    +                "$ref": "http://json-schema.org/geo"
    +            }
    +        },
    +        "required": ["id", "name", "price"]
    +    }
    +}
    +
    + diff --git a/index.html b/index.html index 5e3d4457..9a6d0a83 100644 --- a/index.html +++ b/index.html @@ -17,6 +17,7 @@ })(); +
    @@ -48,7 +49,26 @@

    JSON Schema by example

    Here is a basic example of a JSON Schema: - +

    +{
    +	"title": "Example Schema",
    +	"type": "object",
    +	"properties": {
    +		"firstName": {
    +			"type": "string"
    +		},
    +		"lastName": {
    +			"type": "string"
    +		},
    +		"age": {
    +			"description": "Age in years",
    +			"type": "integer",
    +			"minimum": 0
    +		}
    +	},
    +	"required": ["firstName", "lastName"]
    +}
    +

    For more examples, see the examples page.

    @@ -110,5 +130,6 @@

    Reference schemas

    + diff --git a/lib/json-highlight.css b/lib/json-highlight.css new file mode 100644 index 00000000..eff715a6 --- /dev/null +++ b/lib/json-highlight.css @@ -0,0 +1,48 @@ +.json, .json-schema { + background-color: #F4F4E8; + border: 1px solid #888; + border-radius: 5px; + padding: 0.5em; + font-family: Consolas, "Liberation Mono", Courier, monospace; + font-size: 13px; +} + +.json-punctuation { + font-weight: bold; +} + +.json-null, .json-true, .json-false { + font-weight: bold; +} + +.json-true { + color: #080; +} + +.json-false { + color: #800; +} + +.json-object-key { + color: #246; +} + +.json-keyword { + font-weight: bold; + color: #036; +} + +.json-number { + font-weight: bold; + color: #660; +} + +.json-string { + color: #800; +} + +.json-schema-map > .json-object-key { + color: #080; + font-style: italic; +} + diff --git a/lib/json-highlight.js b/lib/json-highlight.js new file mode 100644 index 00000000..9d60e3fa --- /dev/null +++ b/lib/json-highlight.js @@ -0,0 +1,287 @@ + var REGEX = { + whitespace: /^([ \r\n\t]| )*/, + number: /^(0x|0X)?[0-9]+(\.[0-9]+)?([eE][+\-]?[0-9]+)?/ + }; + + function Highlighter(stringData) { + this.remaining = stringData; + this.html = ""; + } + Highlighter.prototype = { + unshift: function (next) { + this.remaining = next + this.remaining; + }, + next: function () { + this.whitespace(); + return this.nextCharacter(); + }, + nextCharacter: function () { + if (this.remaining.length == 0) { + throw new Error("Unexpected end of input"); + } + if (this.remaining[0] == "&") { + var endIndex = this.remaining.indexOf(";") + 1; + if (endIndex == -1) { + endIndex = 1; + } + var result = this.remaining.substring(0, endIndex); + this.remaining = this.remaining.substring(endIndex); + return result; + } + var result = this.remaining[0]; + this.remaining = this.remaining.substring(1); + return result; + }, + whitespace: function () { + var ws = this.remaining.match(REGEX.whitespace)[0]; + this.html += ws; + this.remaining = this.remaining.substring(ws.length); + }, + highlightJson: function (keywords) { + if (keywords != undefined) { + this.html += keywords.wrapper[0]; + } + this.whitespace(); + var next = this.next(); + if (next == "{") { + this.highlightObject(keywords); + } else if (next == '[') { + this.highlightArray(keywords); + } else if (next == '"' || next == """) { + this.highlightString(); + } else if ((next + this.remaining).match(REGEX.number)) { + var numberString = (next + this.remaining).match(REGEX.number)[0]; + this.html += '' + numberString + ''; + this.remaining = this.remaining.substring(numberString.length - 1); + } else if (next == "n" && this.remaining.substring(0, 3) == "ull") { + this.remaining = this.remaining.substring(3); + this.html += 'null'; + } else if (next == "t" && this.remaining.substring(0, 3) == "rue") { + this.remaining = this.remaining.substring(3); + this.html += 'true'; + } else if (next == "f" && this.remaining.substring(0, 4) == "alse") { + this.remaining = this.remaining.substring(4); + this.html += 'false'; + } else { + this.html += next; + this.highlightJson(keywords); + } + if (keywords != undefined) { + this.html += keywords.wrapper[1]; + } + }, + highlightObject: function (keywords) { + this.html += '{'; + var next = this.next(); + while (next != "}") { + if (next == '"' || next == """) { + var keyHtml = ""; + next = this.next(); + while (next != '"' && next != '"') { + if (next == "\\") { + keyHtml += next; + next = this.nextCharacter(); + } + keyHtml += next; + next = this.next(); + } + if (keywords != undefined && keywords.isKeyword(keyHtml)) { + this.html += '"' + + keyHtml + + '"'; + } else { + this.html += '"' + + keyHtml + + '"'; + } + next = this.next(); + while (next != ":") { + this.html += next; + next = this.next(); + } + this.html += ':'; + var nextKeywords = null; + if (keywords != undefined) { + nextKeywords = keywords.forKey(keyHtml); + } + this.highlightJson(nextKeywords); + next = this.next(); + if (next == ",") { + this.html += ','; + next = this.next(); + continue; + } else while (next != "}") { + this.html += next; + next = this.next(); + } + } else { + this.html += next; + next = this.next(); + } + } + this.html += '}'; + }, + highlightArray: function (keywords) { + this.html += '['; + var next = this.next(); + var i = 0; + while (next != "]") { + this.unshift(next); + this.highlightJson(keywords != undefined ? keywords.forItem(i) : null); + next = this.next(); + if (next == ",") { + this.html += ','; + next = this.next(); + i++; + continue; + } else while (next != "]") { + this.html += next; + next = this.next(); + } + } + this.html += ']'; + }, + highlightString: function () { + this.html += '"'; + next = this.next(); + while (next != '"' && next != '"') { + if (next == "\\") { + this.html += next; + next = this.nextCharacter(); + } + this.html += next; + next = this.next(); + } + this.html += '"'; + } + }; + + function KeywordMap() { + } + KeywordMap.prototype = { + wrapper: ["", ""], + keywords: {}, + isKeyword: function (keyHtml) { + return this.keywords[keyHtml] !== undefined; + }, + forKey: function (keyHtml) { + return this.keywords[keyHtml]; + }, + forItem: function (keyHtml) { + return null; + } + }; + var schema = new KeywordMap(); + var schemaMedia = new KeywordMap(); + var mapToSchemas = new KeywordMap(); + var links = new KeywordMap(); + schema.keywords = { + // from v3 + type: null, + properties: mapToSchemas, + patternProperties: mapToSchemas, + additionalProperties: schema, + items: schema, + additionalItems: schema, + required: null, + dependencies: mapToSchemas, + minimum: null, + maximum: null, + exclusiveMinimum: null, + exclusiveMaximum: null, + minItems: null, + maxItems: null, + uniqueItems: null, + pattern: null, + minLength: null, + maxLength: null, + "enum": null, + "default": null, + title: null, + description: null, + format: null, + divisibleBy: null, + disallow: schema, + "extends": schema, + "id": null, + "$ref": null, + "$schema": null, + // from v4 core + multipleOf: null, + maxProperties: null, + minProperties: null, + allOf: schema, + anyOf: schema, + oneOf: schema, + not: schema, + definitions: mapToSchemas, + // from v4 hyper-schema + media: schemaMedia, + links: links, + pathStart: null, + fragmentResolution: null + }; + schema.forItem = function () { + return schema; + }; + schemaMedia.keywords = { + binaryEncoding: null, + type: null + }; + mapToSchemas.wrapper = ['', '']; + mapToSchemas.forKey = function () { + return schema; + }; + links.keywords = { + rel: null, + href:null, + method: null, + encType: null, + pathStart: null, + schema: schema, + targetSchema: schema + }; + links.forItem = function () { + return links; + }; + + function highlightElement(element, keywords) { + var highlighter = new Highlighter(element.innerHTML); + try { + highlighter.highlightJson(keywords); + } catch (e) { + throw e; + } + element.innerHTML = highlighter.html + highlighter.remaining; + } + + if (document.getElementsByClassName == undefined) { + document.getElementsByClassName = function(className) + { + var hasClassName = new RegExp("(?:^|\\s)" + className + "(?:$|\\s)"); + var allElements = document.getElementsByTagName("*"); + var results = []; + + var element; + for (var i = 0; (element = allElements[i]) != null; i++) { + var elementClass = element.className; + if (elementClass && elementClass.indexOf(className) != -1 && hasClassName.test(elementClass)) + results.push(element); + } + + return results; + } + } + + function highlightJson() { + var jsonNodes = document.getElementsByClassName('json'); + for (var i = 0; i < jsonNodes.length; i++) { + highlightElement(jsonNodes[i]); + } + var jsonSchemaNodes = document.getElementsByClassName('json-schema'); + for (var i = 0; i < jsonSchemaNodes.length; i++) { + highlightElement(jsonSchemaNodes[i], schema); + } + } + + highlightJson(); From 5964e1b48a08db44a67bd88dc696c7b485516ccf Mon Sep 17 00:00:00 2001 From: "user@server" Date: Tue, 8 Jan 2013 07:53:31 +0000 Subject: [PATCH 0204/1659] Deleted CNAME --- CNAME | 2 -- 1 file changed, 2 deletions(-) delete mode 100644 CNAME diff --git a/CNAME b/CNAME deleted file mode 100644 index 0d9c62bd..00000000 --- a/CNAME +++ /dev/null @@ -1,2 +0,0 @@ -json-schema.org - From 479ff62e0f74ede1ac5f27d742e113572c913aea Mon Sep 17 00:00:00 2001 From: "user@server" Date: Tue, 8 Jan 2013 08:03:15 +0000 Subject: [PATCH 0205/1659] Allow negative numbers (whoops) --- lib/json-highlight.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/json-highlight.js b/lib/json-highlight.js index 9d60e3fa..f15931df 100644 --- a/lib/json-highlight.js +++ b/lib/json-highlight.js @@ -1,6 +1,6 @@ var REGEX = { whitespace: /^([ \r\n\t]| )*/, - number: /^(0x|0X)?[0-9]+(\.[0-9]+)?([eE][+\-]?[0-9]+)?/ + number: /^-?[0-9]+(\.[0-9]+)?([eE][+\-]?[0-9]+)?/ }; function Highlighter(stringData) { From 35860418283d6e4ac1c3b674af465541fca04d66 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Tue, 8 Jan 2013 16:27:57 +0100 Subject: [PATCH 0206/1659] Improve example2.html * Some wording changes. * Separate storage schemas. * Rework wrap up section. --- example2.html | 286 ++++++++++++++++++-------------------------------- 1 file changed, 102 insertions(+), 184 deletions(-) diff --git a/example2.html b/example2.html index 9b56a722..416414c6 100644 --- a/example2.html +++ b/example2.html @@ -100,9 +100,9 @@

    Base schema

    / or to match the regular expression. -

    You will notice that the regular expression is explicitly anchored: in JSON Schema, regular -expressions (in patternProperties and in pattern) are not anchored by default, you -must add anchors if you need them.

    +

    You will notice that the regular expression is explicitly anchored (with ^ and +$): in JSON Schema, regular expressions (in patternProperties and in +pattern) are not anchored by default.

    For now, the schemas describing individual entries are empty: we will start describing the constraints in the following paragraphs, using another schema, which we will reference from the main @@ -112,8 +112,8 @@

    The entry schema

    The skeleton

    -

    Here again we will proceed little by little. We will start with the global structure of our -schema, which will be as such:

    +

    Here again we will proceed step by step. We will start with the global structure of our schema, +which will be as such:

     {
    @@ -142,31 +142,39 @@ 

    The skeleton

    }
    -

    The expressed constraints you should already be familiar with: the JSON value must be an object, and this -object must have a property by the name storage; what is more, that storage -property must be an object. There are a couple of novelties:

    +

    You should already be familiar with some of the constraints:

    + +
      +
    • an fstab entry must be an object ("type": "object");
    • +
    • it must have one property with name storage ("required": [ "storage" ]);
    • +
    • the storage property must also be an object.
    • +
    + +

    There are a couple of novelties:

    • you will notice the appearance of JSON References, via the $ref keyword; here, all references used are local to the schema, and the fragment part is a URI encoded JSON Pointer;
    • you will notice the appearance of an id: this is the URI of this resource; we assume here that this URI is the actual URI of this schema;
    • -
    • the oneOf keyword is new; its argument is an array of schemas, and the data will be -valid if and only if it validates against only one of the schemas in the array;
    • +
    • the oneOf keyword is new in draft v4; its value is an array of +schemas, and an instance is valid if and only if it is valid against exactly one +of these schemas;
    • finally, the definitions keyword is a standardized placeholder in which you can define -inline subschemas to be used in a schema. +inline subschemas to be used in a schema.

    The fstype, options and readonly properties

    -

    Let us now extend this skeleton to add constraints to the aforementioned properties. Note that -none of them is required:

    +

    Let us now extend this skeleton to add constraints to these three properties. Note that none of +them are required:

      -
    • we only support ext3, ext4 and btrfs as filesystem types;
    • -
    • the options array only allows strings; moreover, when specified, there must be at least -one option, and all options should be unique;
    • -
    • readonly can only be a boolean.
    • +
    • we will pretend that we only support ext3, ext4 and btrfs as +filesystem types;
    • +
    • options must be an array, and the items in this array must be strings; moreover, there +must be at least one item, and all items should be unique;
    • +
    • readonly must be a boolean.

    With these added constraints, the schema now looks like this:

    @@ -208,7 +216,8 @@

    The fstype, options and readonly properties

    } -

    It is now time we filled the different storage definitions.

    +

    For now, all definitions are empty (an empty JSON Schema validates all instances). We will write +schemas for individual definitions below, and fill these schemas into the entry schema.

    The diskDevice storage type

    @@ -218,51 +227,21 @@

    The diskDevice storage type

     {
    -    "id": "http://some.site.somewhere/entry-schema#",
    -    "$schema": "http://json-schema.org/draft-04/schema#",
    -    "description": "schema for an fstab entry",
    -    "type": "object",
    -    "required": [ "storage" ],
         "properties": {
    -        "storage": {
    -            "type": "object",
    -            "oneOf": [
    -                { "$ref": "#/definitions/diskDevice" },
    -                { "$ref": "#/definitions/diskUUID" },
    -                { "$ref": "#/definitions/nfs" },
    -                { "$ref": "#/definitions/tmpfs" }
    -            ]
    -        },
    -        "fstype": {
    -            "enum": [ "ext3", "ext4", "btrfs" ]
    -        },
    -        "options": {
    -            "type": "array",
    -            "minItems": 1,
    -            "items": { "type": "string" },
    -            "uniqueItems": true
    -        },
    -        "readonly": { "type": "boolean" }
    +        "type": { "enum": [ "disk" ] },
    +        "device": {
    +            "type": "string",
    +            "pattern": "^/dev/[^/]+(/[^/]+)*$"
    +        }
         },
    -    "definitions": {
    -        "diskDevice": {
    -            "properties": {
    -                "type": { "enum": [ "disk" ] },
    -                "device": {
    -                    "type": "string",
    -                    "pattern": "^/dev/[^/]+(/[^/]+)*$"
    -                }
    -            },
    -            "required": [ "type", "device" ],
    -            "additionalProperties": false
    -        },
    -        "diskUUID": {},
    -        "nfs": {},
    -        "tmpfs": {}
    -    }
    +    "required": [ "type", "device" ],
    +    "additionalProperties": false
     }
     
    +

    You will have noted that we need not speficy that type must be a string: the constraint +described by enum is enough.

    +

    The diskUUID storage type

    This storage type has two required properties, type and label. The type can @@ -270,58 +249,15 @@

    The diskUUID storage type

     {
    -    "id": "http://some.site.somewhere/entry-schema#",
    -    "$schema": "http://json-schema.org/draft-04/schema#",
    -    "description": "schema for an fstab entry",
    -    "type": "object",
    -    "required": [ "storage" ],
         "properties": {
    -        "storage": {
    -            "type": "object",
    -            "oneOf": [
    -                { "$ref": "#/definitions/diskDevice" },
    -                { "$ref": "#/definitions/diskUUID" },
    -                { "$ref": "#/definitions/nfs" },
    -                { "$ref": "#/definitions/tmpfs" }
    -            ]
    -        },
    -        "fstype": {
    -            "enum": [ "ext3", "ext4", "btrfs" ]
    -        },
    -        "options": {
    -            "type": "array",
    -            "minItems": 1,
    -            "items": { "type": "string" },
    -            "uniqueItems": true
    -        },
    -        "readonly": { "type": "boolean" }
    +        "type": { "enum": [ "disk" ] },
    +        "label": {
    +            "type": "string",
    +            "pattern": "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"
    +        }
         },
    -    "definitions": {
    -        "diskDevice": {
    -            "properties": {
    -                "type": { "enum": [ "disk" ] },
    -                "device": {
    -                    "type": "string",
    -                    "pattern": "^/dev/[^/]+(/[^/]+)*$"
    -                }
    -            },
    -            "required": [ "type", "device" ],
    -            "additionalProperties": false
    -        },
    -        "diskUUID": {
    -            "properties": {
    -                "type": { "enum": [ "disk" ] },
    -                "label": {
    -                    "type": "string",
    -                    "pattern": "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"
    -                }
    -            },
    -            "required": [ "type", "label" ],
    -            "additionalProperties": false
    -        },
    -        "nfs": {},
    -        "tmpfs": {}
    -    }
    +    "required": [ "type", "label" ],
    +    "additionalProperties": false
     }
     
    @@ -336,85 +272,51 @@

    The nfs storage type

     {
    -    "id": "http://some.site.somewhere/entry-schema#",
    -    "$schema": "http://json-schema.org/draft-04/schema#",
    -    "description": "schema for an fstab entry",
    -    "type": "object",
    -    "required": [ "storage" ],
         "properties": {
    -        "storage": {
    -            "type": "object",
    +        "type": { "enum": [ "nfs" ] },
    +        "remotePath": {
    +            "type": "string",
    +            "pattern": "^(/[^/]+)+$"
    +        },
    +        "server": {
    +            "type": "string",
                 "oneOf": [
    -                { "$ref": "#/definitions/diskDevice" },
    -                { "$ref": "#/definitions/diskUUID" },
    -                { "$ref": "#/definitions/nfs" },
    -                { "$ref": "#/definitions/tmpfs" }
    +                { "format": "host-name" },
    +                { "format": "ipv4" },
    +                { "format": "ipv6" }
                 ]
    -        },
    -        "fstype": {
    -            "enum": [ "ext3", "ext4", "btrfs" ]
    -        },
    -        "options": {
    -            "type": "array",
    -            "minItems": 1,
    -            "items": { "type": "string" },
    -            "uniqueItems": true
    -        },
    -        "readonly": { "type": "boolean" }
    +        }
         },
    -    "definitions": {
    -        "diskDevice": {
    -            "properties": {
    -                "type": { "enum": [ "disk" ] },
    -                "device": {
    -                    "type": "string",
    -                    "pattern": "^/dev/[^/]+(/[^/]+)*$"
    -                }
    -            },
    -            "required": [ "type", "device" ],
    -            "additionalProperties": false
    -        },
    -        "diskUUID": {
    -            "properties": {
    -                "type": { "enum": [ "disk" ] },
    -                "label": {
    -                    "type": "string",
    -                    "pattern": "^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"
    -                }
    -            },
    -            "required": [ "type", "label" ],
    -            "additionalProperties": false
    -        },
    -        "nfs": {
    -            "properties": {
    -                "type": { "enum": [ "nfs" ] },
    -                "remotePath": {
    -                    "type": "string",
    -                    "pattern": "^(/[^/]+)+$"
    -                },
    -                "server": {
    -                    "type": "string",
    -                    "oneOf": [
    -                        { "format": "host-name" },
    -                        { "format": "ipv4" },
    -                        { "format": "ipv6" }
    -                    ]
    -                }
    -            },
    -            "required": [ "type", "server", "remotePath" ],
    -            "additionalProperties": false
    -        },
    -        "tmpfs": {}
    -    }
    +    "required": [ "type", "server", "remotePath" ],
    +    "additionalProperties": false
     }
     
    -

    The tmpfs storage type

    +

    The tmpfs storage type

    This storage type has two required properties: type and sizeInMB. The size can only be an integer. What is more, we will require that the size be between 16 and 512, inclusive:

    +
    +{
    +    "properties": {
    +        "type": { "enum": [ "tmpfs" ] },
    +        "sizeInMB": {
    +            "type": "integer",
    +            "minimum": 16,
    +            "maximum": 512
    +        }
    +    },
    +    "required": [ "type", "sizeInMB" ],
    +    "additionalProperties": false
    +}
    +
    + +

    The full entry schema

    + +

    The resulting schema is quite large:

    +
     {
         "id": "http://some.site.somewhere/entry-schema#",
    @@ -521,15 +423,16 @@ 

    Plugging this into our main schema

    }
    -

    Wrap up

    +

    Wrapping up

    This example is much more advanced than the previous example; you will have learned of schema -referencing and identification, you will have been introduced to other keywords. It also raises some -interesting points.

    +referencing and identification, you will have been introduced to other keywords. There are also a +few additional points to consider.

    The schema can be improved

    -

    For instance:

    +

    This is only an example for learning purposes. Some additional constraints could be described. +For instance:

    • it makes no sense for / to be mounted on a tmpfs filesystem;
    • @@ -539,13 +442,28 @@

      The schema can be improved

      As an exercise, you can always try and add these constraints. It would probably require splitting the schema further.

      -

      JSON Schema limits itself to structural validation

      +

      Not all constraints can be expressed

      -

      The format keyword is the only exception to this (with it, you can do semantic -validation of primitive types, such as strings), but supporting it is not required.

      +

      JSON Schema limits itself to describing the structure of JSON data, it cannot express functional +constraints.

      -

      What is more, if we take an NFS entry as an example, it would be the role of your application -code to check that the submitted NFS server's hostname, or IP address, is actually correct.

      +

      If we take an NFS entry as an example, JSON Schema alone cannot check that the submitted NFS +server's hostname, or IP address, is actually correct: this check is left to applications.

      + +

      Tools have varying JSON Schema support

      + +

      While this is not a concern if you know that the schema you write will be used by you alone, you +should keep this in mind if you write a schema which other people can potentially use. The schema we +have written here has some features which can be problematic for portability:

      + +
        +
      • format support is optional, and as such other tools may ignore this keyword: this can +lead to a different validation outcome for the same data;
      • +
      • it uses regular expressions: care should be taken not to use any advanced features (such as +lookarounds), since they may not be supported at the other end;
      • +
      • it uses $schema to express the need to use draft v4 syntax, but not all tools support +draft v4 (in fact, most don't support it).
      • +
      From 97efd0b70cc370ec12eb47037b9988fc5fe955c9 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Wed, 9 Jan 2013 17:04:02 +0100 Subject: [PATCH 0207/1659] Some changes to the core specification --- proposals/json-schema-core.txt | 164 ++++++++++++++++++++++----------- proposals/json-schema-core.xml | 51 ++++------ 2 files changed, 128 insertions(+), 87 deletions(-) diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt index d1481423..8f1debb1 100644 --- a/proposals/json-schema-core.txt +++ b/proposals/json-schema-core.txt @@ -2,12 +2,12 @@ Internet Engineering Task Force fge. Galiegue -Internet-Draft November 23, 2012 +Internet-Draft January 9, 2013 Intended status: Informational -Expires: May 27, 2013 +Expires: July 13, 2013 - JSON Schema: core definitions and purposes + JSON Schema: core definitions and terminology json-schema-core Abstract @@ -34,11 +34,11 @@ 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 May 27, 2013. + This Internet-Draft will expire on July 13, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal @@ -52,9 +52,9 @@ Copyright Notice -Galiegue Expires May 27, 2013 [Page 1] +Galiegue Expires July 13, 2013 [Page 1] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 described in the Simplified BSD License. @@ -63,7 +63,7 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 - 3. Core terminology of JSON Schema . . . . . . . . . . . . . . . 3 + 3. Core terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Property, item . . . . . . . . . . . . . . . . . . . . . . 3 3.2. JSON Schema, keywords . . . . . . . . . . . . . . . . . . 3 3.3. Root schema, subschema . . . . . . . . . . . . . . . . . . 3 @@ -77,7 +77,7 @@ Table of Contents 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.4. Extending JSON Schema . . . . . . . . . . . . . . . . . . 6 5.5. Security considerations . . . . . . . . . . . . . . . . . 7 6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 7 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7 @@ -108,9 +108,9 @@ Table of Contents -Galiegue Expires May 27, 2013 [Page 2] +Galiegue Expires July 13, 2013 [Page 2] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 1. Introduction @@ -121,10 +121,11 @@ Internet-Draft JSON Schema November 2012 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 addressing. + This specification acts as a reference to other related + specifications, inasmuch as it defines JSON Schema core terminology + as well as its applications; related specifcations will use this core + terminology, and cover one or more of these applications in a + detailed manner. 2. Conventions and Terminology @@ -137,38 +138,38 @@ Internet-Draft JSON Schema November 2012 and "null" in this document are to be interpreted as defined in RFC 4627 [RFC4627]. -3. Core terminology of JSON Schema +3. Core terminology 3.1. Property, item - A property of a JSON object is equivalent to a member, as defined by - RFC 4627. + When refering to a JSON Object, as defined by [RFC4627], the terms + "member" and "property" may be used interchangeably. - An item of a JSON array is equivalent to an element, as defined by - RFC 4627. + When refering to a JSON Array, as defined by [RFC4627], the terms + "element" and "item" may be used interchangeably. 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 - schema keywords. + object. Object members (or properties) of a JSON Schema are called + keywords, or schema keywords. - A JSON Schema MAY be empty. + A JSON Schema MAY be empty. That is, it may have no members. 3.3. Root schema, subschema - This is a simple example of a JSON Schema, with no nested schemas: + This example of a JSON Schema has no subschemas: - { -Galiegue Expires May 27, 2013 [Page 3] +Galiegue Expires July 13, 2013 [Page 3] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 + { "title": "root" } @@ -198,8 +199,7 @@ Internet-Draft JSON Schema November 2012 boolean A JSON boolean. - integer A JSON number without a fraction or exponent part (see RFC - 4627, section 2.4 [RFC4627]). + integer A JSON number without a fraction or exponent part. number Any JSON number. Number includes integer. @@ -220,9 +220,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 4] +Galiegue Expires July 13, 2013 [Page 4] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 both are strings, and have the same value; or @@ -246,8 +246,7 @@ Internet-Draft JSON Schema November 2012 3.6. 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. + JSON Schemas. 4. Overview @@ -276,9 +275,10 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 5] + +Galiegue Expires July 13, 2013 [Page 5] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 4.2. Hypermedia and linking @@ -318,10 +318,10 @@ Internet-Draft JSON Schema November 2012 do not. As a consequence, for interoperability reasons, schema authors and - instance producers SHOULD ensure that integer numeric values be + instance providers SHOULD ensure that integer numeric values be written using their canonical mathematical representation. -5.4. JSON Schema extension +5.4. Extending JSON Schema Implementations MAY choose to define additional keywords to JSON Schema. Save for explicit agreement, schema authors SHALL NOT expect @@ -332,9 +332,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 6] +Galiegue Expires July 13, 2013 [Page 6] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 5.5. Security considerations @@ -388,9 +388,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 7] +Galiegue Expires July 13, 2013 [Page 7] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 7. Schema addressing @@ -444,9 +444,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 8] +Galiegue Expires July 13, 2013 [Page 8] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 { @@ -500,9 +500,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 9] +Galiegue Expires July 13, 2013 [Page 9] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 An implementation choosing to support inline addressing SHOULD @@ -556,9 +556,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 10] +Galiegue Expires July 13, 2013 [Page 10] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 Content-Type: application/my-media-type+json; @@ -612,9 +612,9 @@ Internet-Draft JSON Schema November 2012 -Galiegue Expires May 27, 2013 [Page 11] +Galiegue Expires July 13, 2013 [Page 11] -Internet-Draft JSON Schema November 2012 +Internet-Draft JSON Schema January 2013 [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer", @@ -627,36 +627,92 @@ Internet-Draft JSON Schema November 2012 Appendix A. ChangeLog - TODO + draft-04 -Author's Address + * Split draft: core definitions (this one), validation, hyper + schema. - Francis Galiegue + draft-03 - EMail: fgaliegue@gmail.com + * 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. + + + + +Galiegue Expires July 13, 2013 [Page 12] + +Internet-Draft JSON Schema January 2013 + * 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. + +Author's Address + + Francis Galiegue + + EMail: fgaliegue@gmail.com @@ -668,5 +724,5 @@ Author's Address -Galiegue Expires May 27, 2013 [Page 12] +Galiegue Expires July 13, 2013 [Page 13] diff --git a/proposals/json-schema-core.xml b/proposals/json-schema-core.xml index c36e0382..2a1cb3a9 100644 --- a/proposals/json-schema-core.xml +++ b/proposals/json-schema-core.xml @@ -13,7 +13,7 @@ - JSON Schema: core definitions and purposes + JSON Schema: core definitions and terminology
      @@ -21,7 +21,7 @@
      - + Internet Engineering Task Force JSON Schema @@ -49,10 +49,10 @@ - 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 addressing. + This specification acts as a reference to other related specifications, inasmuch as + it defines JSON Schema core terminology as well as its applications; related + specifcations will use this core terminology, and cover one or more of these + applications in a detailed manner.
    @@ -73,32 +73,34 @@
    -
    +
    - A property of a JSON object is equivalent to a member, as defined by RFC 4627. + When refering to a JSON Object, as defined by , the + terms "member" and "property" may be used interchangeably. - An item of a JSON array is equivalent to an element, as defined by RFC 4627. + When refering to a JSON Array, as defined by , the terms + "element" and "item" may be used interchangeably.
    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. + members (or properties) of a JSON Schema are called keywords, or schema keywords. - A JSON Schema MAY be empty. + A JSON Schema MAY be empty. That is, it may have no members.
    - This is a simple example of a JSON Schema, with no nested schemas: + This example of a JSON Schema has no subschemas:
    @@ -141,8 +143,7 @@ A JSON array. A JSON boolean. - A JSON number without a fraction or exponent part (see - RFC 4627, section 2.4). + A JSON number without a fraction or exponent part. Any JSON number. Number includes integer. The JSON null value. A JSON object. @@ -181,7 +182,6 @@
    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.
    @@ -254,12 +254,12 @@ As a consequence, for interoperability reasons, schema authors and instance - producers SHOULD ensure that integer numeric values be written using their + providers 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 @@ -603,27 +603,13 @@ Link: ; rel="describedBy"
    - TODO -
    From 3e44e14507697cdb3d773de0a10d871b90415ff3 Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Wed, 9 Jan 2013 17:04:02 +0100 Subject: [PATCH 0208/1659] More changes to the core specification * Quite a few wording changes * Separate definition for empty schema * More focus on HTTP, and why --- proposals/json-schema-core.txt | 420 ++++++++++++++------------------- proposals/json-schema-core.xml | 197 +++++++--------- 2 files changed, 267 insertions(+), 350 deletions(-) diff --git a/proposals/json-schema-core.txt b/proposals/json-schema-core.txt index 8f1debb1..07131b56 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 January 9, 2013 +Internet-Draft January 12, 2013 Intended status: Informational -Expires: July 13, 2013 +Expires: July 16, 2013 JSON Schema: core definitions and terminology @@ -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 July 13, 2013. + This Internet-Draft will expire on July 16, 2013. Copyright Notice @@ -52,7 +52,7 @@ Copyright Notice -Galiegue Expires July 13, 2013 [Page 1] +Galiegue Expires July 16, 2013 [Page 1] Internet-Draft JSON Schema January 2013 @@ -66,49 +66,49 @@ Table of Contents 3. Core terminology . . . . . . . . . . . . . . . . . . . . . . . 3 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 + 3.3. Empty schema . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.4. Root schema, subschema . . . . . . . . . . . . . . . . . . 4 + 3.5. JSON Schema primitive types . . . . . . . . . . . . . . . 4 + 3.6. JSON value equality . . . . . . . . . . . . . . . . . . . 5 + 3.7. Instance . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Instance validation . . . . . . . . . . . . . . . . . . . 5 + 4.1. Validation . . . . . . . . . . . . . . . . . . . . . . . . 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. Extending JSON Schema . . . . . . . . . . . . . . . . . . 6 - 5.5. Security considerations . . . . . . . . . . . . . . . . . 7 + 5.1. Applicability to all JSON values . . . . . . . . . . . . . 6 + 5.2. Programming language independence . . . . . . . . . . . . 6 + 5.3. JSON Schema and HTTP . . . . . . . . . . . . . . . . . . . 6 + 5.4. JSON Schema and other protocols . . . . . . . . . . . . . 6 + 5.5. Mathematical integers . . . . . . . . . . . . . . . . . . 7 + 5.6. Extending JSON Schema . . . . . . . . . . . . . . . . . . 7 + 5.7. Security considerations . . . . . . . . . . . . . . . . . 7 6. The "$schema" keyword . . . . . . . . . . . . . . . . . . . . 7 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6.2. Customization . . . . . . . . . . . . . . . . . . . . . . 7 + 6.2. Customization . . . . . . . . . . . . . . . . . . . . . . 8 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.4. Inline addressing . . . . . . . . . . . . . . . . . . . . 9 + 7.4.1. JSON Reference extension . . . . . . . . . . . . . . . 10 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 + HTTP protocol . . . . . . . . . . . . . . . . . . . . . . 11 + 8.2.1. Correlation by means of the "Content-Type" header . . 11 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 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 12 - - - -Galiegue Expires July 13, 2013 [Page 2] +Galiegue Expires July 16, 2013 [Page 2] Internet-Draft JSON Schema January 2013 @@ -121,11 +121,9 @@ Internet-Draft JSON Schema January 2013 intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data. - This specification acts as a reference to other related - specifications, inasmuch as it defines JSON Schema core terminology - as well as its applications; related specifcations will use this core - terminology, and cover one or more of these applications in a - detailed manner. + This specification defines JSON Schema core terminology and + mechanisms; related specifications build upon this specification and + define different applications of JSON Schema. 2. Conventions and Terminology @@ -151,24 +149,31 @@ Internet-Draft JSON Schema January 2013 3.2. JSON Schema, keywords A JSON Schema is a JSON document, and that document MUST be an - object. Object members (or properties) of a JSON Schema are called - keywords, or schema keywords. + object. Object members (or properties) defined by JSON Schema (this + specification, or related specifcations) are called keywords, or + schema keywords. - A JSON Schema MAY be empty. That is, it may have no members. + A JSON Schema MAY contain properties which are not schema keywords. -3.3. Root schema, subschema +3.3. Empty schema - This example of a JSON Schema has no subschemas: + An empty schema is a JSON Schema with no properties, or with + properties which are not schema keywords. -Galiegue Expires July 13, 2013 [Page 3] +Galiegue Expires July 16, 2013 [Page 3] Internet-Draft JSON Schema January 2013 +3.4. Root schema, subschema + + This example of a JSON Schema has no subschemas: + + { "title": "root" } @@ -191,7 +196,7 @@ Internet-Draft JSON Schema January 2013 In this example, "nested" and "alsoNested" are subschemas, and "root" is a root schema. -3.4. JSON Schema primitive types +3.5. JSON Schema primitive types JSON Schema defines seven primitive types for JSON values: @@ -209,81 +214,81 @@ Internet-Draft JSON Schema January 2013 string A JSON string. -3.5. JSON value equality - 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 - -Galiegue Expires July 13, 2013 [Page 4] +Galiegue Expires July 16, 2013 [Page 4] Internet-Draft JSON Schema January 2013 +3.6. JSON value equality + + 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 value; or both are numbers, and have the same mathematical value; or both are arrays, and: - have the same number of elements; and + have the same number of items; and - elements at the same index are equal according to this - definition; or + items at the same index are equal according to this definition; + or both are objects, and: - have the same set of members; and + have the same set of property names; and - values for a same member are equal according to this + values for a same property name are equal according to this definition. -3.6. Instance +3.7. Instance - An instance is any JSON value, which may be defined by one or more - JSON Schemas. + An instance is any JSON value. An instance may be described by one + or more schemas. + + An instance may also be referred to as "JSON instance", or "JSON + data". 4. Overview 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 - own specification. + identify JSON Schema for describing JSON data. JSON Schemas are + themselves written in JSON. This, and related specifications, define + keywords allowing to describe this data in terms of allowable values, + textual descriptions and interpreting relations with other resources. + The following sections are a summary of features defined by related + specifications. -4.1. Instance validation +4.1. Validation - 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 allows applications to validate instances, either non + interactively or interactively. For instance, an application may - - - - -Galiegue Expires July 13, 2013 [Page 5] +Galiegue Expires July 16, 2013 [Page 5] Internet-Draft JSON Schema January 2013 + collect JSON data and check that this data matches a given set of + constraints; another application may use a JSON Schema to build an + interactve interface in order to collect user input according to + constraints described by JSON Schema. + 4.2. Hypermedia and linking - JSON Schema provides a method for defining link relations from + JSON Schema provides a method for extracting 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 @@ -291,53 +296,67 @@ Internet-Draft JSON Schema January 2013 5. General considerations -5.1. Valid instances +5.1. Applicability to all JSON values - 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 described. + It is acknowledged that an 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 describe any JSON + value, including null. -5.2. Protocol and programming language independence +5.2. 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 - specification nevertheless suggests mechanisms to correlate an - instance to a schema over HTTP, which is the dominant protocol used - for Internet-enabled interactive applications. + JSON Schema is programming language agnostic. The only limitations + are the ones expressed by [RFC4627] and those of the host programming + language. -5.3. Integer numeric instances +5.3. JSON Schema and HTTP - 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. + This specification acknowledges the role of HTTP [RFC2616] as the + dominant protocol in use on the Internet, and the wealth of official + specifications related to it. - As a consequence, for interoperability reasons, schema authors and - instance providers SHOULD ensure that integer numeric values be - written using their canonical mathematical representation. + This specification uses a subset of these specifications to recommend + a set of mechanisms, usable by this protocol, to associate JSON + instances to one or more schemas. -5.4. Extending JSON Schema +5.4. JSON Schema and other protocols - 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. + JSON Schema does not define any semantics for the client-server + interface for any other protocols than HTTP. These semantics are + application dependent, or subject to agreement between the parties + involved in the use of JSON Schema for their own needs. -Galiegue Expires July 13, 2013 [Page 6] + + +Galiegue Expires July 16, 2013 [Page 6] Internet-Draft JSON Schema January 2013 -5.5. Security considerations +5.5. Mathematical integers + + It is acknowledged by this specification that some programming + languages, and their associated parsers, use different internal + representations for floating point numbers and integers, while others + do not. + + As a consequence, for interoperability reasons, any JSON used in the + context of JSON Schema, whether that JSON be a JSON Schema or an + instance, SHOULD ensure that mathematical integers be represented as + integers as defined by this specification. + +5.6. 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. + Implementations SHOULD ignore keywords they do not support. + +5.7. Security considerations Both schemas and instances are JSON values. As such, all security considerations defined in RFC 4627 [RFC4627] apply. @@ -362,13 +381,19 @@ Internet-Draft JSON Schema January 2013 "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); + against the current version of the specification); - "http://json-schema.org/draft-03/hyper-schema#" (JSON Schema + + + + +Galiegue Expires July 16, 2013 [Page 7] + +Internet-Draft JSON Schema January 2013 + + + "http://json-schema.org/draft-04/hyper-schema#" (JSON Schema hyperschema written against JSON Schema, draft v4); "http://json-schema.org/draft-03/schema#" (JSON Schema written @@ -380,18 +405,9 @@ Internet-Draft JSON Schema January 2013 6.2. Customization - 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. - - - - -Galiegue Expires July 13, 2013 [Page 7] - -Internet-Draft JSON Schema January 2013 - + When extending JSON Schema with custom keywords, schema authors + SHOULD define a custom URI to use for "$schema". This custom URI + MUST NOT be one of the predefined values. 7. Schema addressing @@ -424,6 +440,15 @@ Internet-Draft JSON Schema January 2013 [json-reference]. JSON References, when encountered, MUST be resolved against the URI of the current root schema. + + + + +Galiegue Expires July 16, 2013 [Page 8] + +Internet-Draft JSON Schema January 2013 + + 7.4. Inline addressing When "id" is encountered in a subschema, implementations MAY resolve @@ -438,17 +463,6 @@ Internet-Draft JSON Schema January 2013 This schema will be taken as an example: - - - - - - -Galiegue Expires July 13, 2013 [Page 8] - -Internet-Draft JSON Schema January 2013 - - { "id": "http://x.y.z/rootschema.json#", "schema1": { @@ -480,6 +494,17 @@ Internet-Draft JSON Schema January 2013 #/schema2/nested http://x.y.z/rootschema.json#bar + + + + + + +Galiegue Expires July 16, 2013 [Page 9] + +Internet-Draft JSON Schema January 2013 + + #/schema2/alsonested http://x.y.z/t/inner.json#a #/schema3 some://where.else/completely# @@ -498,13 +523,6 @@ Internet-Draft JSON Schema January 2013 } - - -Galiegue Expires July 13, 2013 [Page 9] - -Internet-Draft JSON Schema January 2013 - - An implementation choosing to support inline addressing SHOULD support this extension to JSON Reference. @@ -536,6 +554,13 @@ Internet-Draft JSON Schema January 2013 of, or restrictions on, protocol headers, such a correlation is out of the normative scope of this specification. + + +Galiegue Expires July 16, 2013 [Page 10] + +Internet-Draft JSON Schema January 2013 + + 8.2. Recommended correlation mechanisms for use with the HTTP protocol It is acknowledged by this specification that the majority of @@ -553,14 +578,6 @@ Internet-Draft JSON Schema January 2013 An example of such a header would be: - - - -Galiegue Expires July 13, 2013 [Page 10] - -Internet-Draft JSON Schema January 2013 - - Content-Type: application/my-media-type+json; profile=http://example.com/my-hyper-schema @@ -592,8 +609,21 @@ Internet-Draft JSON Schema January 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +Galiegue Expires July 16, 2013 [Page 11] + +Internet-Draft JSON Schema January 2013 + + 10.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. + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. @@ -605,21 +635,13 @@ Internet-Draft JSON Schema January 2013 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. - [json-reference] Bryan, P. and K. Zyp, "JSON Reference", - September 2012, . - - - + [json-reference] Bryan, P. and K. Zyp, "JSON Reference (work in + progress)", September 2012, . -Galiegue Expires July 13, 2013 [Page 11] - -Internet-Draft JSON Schema January 2013 - - - [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer", - September 2012, . + [json-pointer] Bryan, P. and K. Zyp, "JSON Pointer (work in + progress)", September 2012, . [json-schema-03] Court, G. and K. Zyp, "JSON Schema, draft 3", September 2012, + @@ -49,10 +50,9 @@
    - This specification acts as a reference to other related specifications, inasmuch as - it defines JSON Schema core terminology as well as its applications; related - specifcations will use this core terminology, and cover one or more of these - applications in a detailed manner. + This specification defines JSON Schema core terminology and mechanisms; related + specifications build upon this specification and define different applications of + JSON Schema.
    @@ -90,11 +90,19 @@
    A JSON Schema is a JSON document, and that document MUST be an object. Object - members (or properties) of a JSON Schema are called keywords, or schema keywords. + members (or properties) defined by JSON Schema (this specification, or related + specifcations) are called keywords, or schema keywords. - A JSON Schema MAY be empty. That is, it may have no members. + A JSON Schema MAY contain properties which are not schema keywords. + +
    + +
    + + An empty schema is a JSON Schema with no properties, or with properties which + are not schema keywords.
    @@ -163,15 +171,15 @@ 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 equal according to this - definition; or + have the same number of items; and + items 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 + have the same set of property names; and + values for a same property name are equal according to this definition. @@ -181,7 +189,12 @@
    - An instance is any JSON value, which may be defined by one or more JSON Schemas. + An instance is any JSON value. An instance may be described by one or more + schemas. + + + + An instance may also be referred to as "JSON instance", or "JSON data".
    @@ -190,30 +203,26 @@
    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 own specification. + Schema for describing JSON data. JSON Schemas are themselves written in JSON. This, + and related specifications, define keywords allowing to describe this data in terms + of allowable values, textual descriptions and interpreting relations with other + resources. The following sections are a summary of features defined by related + specifications. -
    +
    - 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 allows applications to validate instances, either non interactively + or interactively. For instance, an application may collect JSON data and check + that this data matches a given set of constraints; another application may use a + JSON Schema to build an interactve interface in order to collect user input + according to constraints described by JSON Schema.
    - JSON Schema provides a method for defining link relations from instances to + JSON Schema provides a method for extracting 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. @@ -223,39 +232,58 @@
    -
    +
    - It is acknowledged that a JSON instance may be any valid JSON value as defined + It is acknowledged that an 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 described. + instance be of a particular type: JSON Schema can describe any JSON value, + including null. + +
    + +
    + + JSON Schema is programming language agnostic. The only limitations are the ones + expressed by and those of the host programming + language. + +
    + +
    + + This specification acknowledges the role of HTTP + as the dominant protocol in use on the Internet, and the wealth of + official specifications related to it. + + + + This specification uses a subset of these specifications to recommend a set of + mechanisms, usable by this protocol, to associate JSON instances to one or more + schemas.
    -
    +
    - 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 for Internet-enabled interactive applications. + JSON Schema does not define any semantics for the client-server interface for + any other protocols than HTTP. These semantics are application dependent, or + subject to agreement between the parties involved in the use of JSON Schema for + their own needs.
    -
    +
    - 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. + It is acknowledged by this specification that some programming languages, and + their associated parsers, use different internal representations for floating + point numbers and integers, while others do not. - As a consequence, for interoperability reasons, schema authors and instance - providers SHOULD ensure that integer numeric values be written using their - canonical mathematical representation. + As a consequence, for interoperability reasons, any JSON used in the context of + JSON Schema, whether that JSON be a JSON Schema or an instance, SHOULD ensure + that mathematical integers be represented as integers as defined by this + specification.
    @@ -296,13 +324,11 @@ The following values are predefined: - "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 + against the current version of the specification); + "http://json-schema.org/draft-04/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); @@ -315,10 +341,9 @@
    - 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. + When extending JSON Schema with custom keywords, schema authors SHOULD define a + custom URI to use for "$schema". This custom URI MUST NOT be one of the + predefined values.
    @@ -558,13 +583,14 @@ Link: ; rel="describedBy" &RFC2119; + &RFC2616; &RFC3986; &RFC4627; &RFC5988; - JSON Reference + JSON Reference (work in progress) ForgeRock US, Inc. @@ -575,9 +601,9 @@ Link: ; rel="describedBy" + target="http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-07"> - JSON Pointer + JSON Pointer (work in progress) ForgeRock US, Inc. @@ -605,59 +631,6 @@ Link: ; rel="describedBy"
    - - - Split draft: core definitions (this one), validation, hyper schema. - - - - - 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 eb4805e94c3e27932352344767d19cc4c3c3381c Mon Sep 17 00:00:00 2001 From: Francis Galiegue Date: Wed, 16 Jan 2013 20:17:54 +0100 Subject: [PATCH 0209/1659] Update core schemas --- draft-04/schema | 233 +++++++++++++++++++-------------------------- schema | 246 ++++++++++++++++++++++-------------------------- 2 files changed, 210 insertions(+), 269 deletions(-) diff --git a/draft-04/schema b/draft-04/schema index 694459a2..85eb502a 100644 --- a/draft-04/schema +++ b/draft-04/schema @@ -1,185 +1,150 @@ { - "$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, + "$schema": "http://json-schema.org/draft-04/schema#", + "description": "Core schema meta-schema", + "definitions": { + "schemaArray": { + "type": "array", "minItems": 1, - "default": "any" - }, - - "disallow": { - "type": [ "string", "array" ], - "items": { - "type": [ "string", { "$ref": "#" } ] - }, - "uniqueItems": true, - "minItems": 1 - }, - - "extends": { - "type": [ {"$ref": "#" }, "array" ], - "items": { "$ref": "#" }, - "default": {} + "items": { "$ref": "#" } }, - - "enum": { + "positiveInteger": { + "type": "integer", + "minimum": 0 + }, + "positiveIntegerDefault0": { + "allOf": [ { "$ref": "#/definitions/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": { + "id": { + "type": "string", + "format": "uri" }, - - "minimum": { - "type": "number" + "$schema": { + "type": "string", + "format": "uri" + }, + "title": { + "type": "string" + }, + "description": { + "type": "string" + }, + "default": {}, + "multipleOf": { + "type": "number", + "minimum": 0, + "exclusiveMinimum": true }, - "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 + "minimum": { + "type": "number" }, - - "maxLength": { - "type": "integer" + "exclusiveMinimum": { + "type": "boolean", + "default": false }, - + "maxLength": { "$ref": "#/definitions/positiveInteger" }, + "minLength": { "$ref": "#/definitions/positiveIntegerDefault0" }, "pattern": { "type": "string", "format": "regex" }, - - "items": { - "type": [ { "$ref": "#" }, "array" ], - "items": {"$ref": "#"}, - "default": {} - }, - "additionalItems": { - "type": [ { "$ref": "#" }, "boolean" ], + "anyOf": [ + { "type": "boolean" }, + { "$ref": "#" } + ], "default": {} }, - - "minItems": { - "type": "integer", - "minimum": 0, - "default": 0 - }, - - "maxItems": { - "type": "integer", - "minimum": 0 + "items": { + "anyOf": [ + { "$ref": "#" }, + { "$ref": "#/definitions/schemaArray" } + ], + "default": {} }, - + "maxItems": { "$ref": "#/definitions/positiveInteger" }, + "minItems": { "$ref": "#/definitions/positiveIntegerDefault0" }, "uniqueItems": { "type": "boolean", "default": false }, - - "properties": { + "maxProperties": { "$ref": "#/definitions/positiveInteger" }, + "minProperties": { "$ref": "#/definitions/positiveIntegerDefault0" }, + "required": { "$ref": "#/definitions/stringArray" }, + "additionalProperties": { + "anyOf": [ + { "type": "boolean" }, + { "$ref": "#" } + ], + "default": {} + }, + "definitions": { "type": "object", "additionalProperties": { "$ref": "#" }, "default": {} }, - - "patternProperties": { + "properties": { "type": "object", "additionalProperties": { "$ref": "#" }, "default": {} }, - - "additionalProperties": { - "type": [ {"$ref": "#" }, "boolean" ], + "patternProperties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, "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" + "anyOf": [ + { "$ref": "#" }, + { "$ref": "#/definitions/stringArray" } + ] + } }, - - "title": { - "type": "string" + "enum": { + "type": "array", + "minItems": 1, + "uniqueItems": true }, - - "description": { - "type": "string" + "type": { + "anyOf": [ + { "$ref": "#/definitions/simpleTypes" }, + { + "type": "array", + "items": { "$ref": "#/definitions/simpleTypes" }, + "minItems": 1, + "uniqueItems": true + } + ] }, - - "default": { - "type": "any" - } + "allOf": { "$ref": "#/definitions/schemaArray" }, + "anyOf": { "$ref": "#/definitions/schemaArray" }, + "oneOf": { "$ref": "#/definitions/schemaArray" }, + "not": { "$ref": "#" } }, - "dependencies": { - "exclusiveMinimum": "minimum", - "exclusiveMaximum": "maximum" + "exclusiveMaximum": [ "maximum" ], + "exclusiveMinimum": [ "minimum" ] }, - "default": {} } diff --git a/schema b/schema index 7a1a2d38..85eb502a 100644 --- a/schema +++ b/schema @@ -1,174 +1,150 @@ { - "$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", { "$ref": "#" } ] - }, - "uniqueItems": true, - "default": "any" - }, - - "properties": { - "type": "object", - "additionalProperties": { "$ref": "#" }, - "default": {} + "id": "http://json-schema.org/draft-04/schema#", + "$schema": "http://json-schema.org/draft-04/schema#", + "description": "Core schema meta-schema", + "definitions": { + "schemaArray": { + "type": "array", + "minItems": 1, + "items": { "$ref": "#" } }, - - "patternProperties": { - "type": "object", - "additionalProperties": { "$ref": "#" }, - "default": {} + "positiveInteger": { + "type": "integer", + "minimum": 0 }, - - "additionalProperties": { - "type": [ { "$ref": "#" }, "boolean" ], - "default": {} + "positiveIntegerDefault0": { + "allOf": [ { "$ref": "#/definitions/positiveInteger" }, { "default": 0 } ] }, - - "items": { - "type": [ { "$ref": "#" }, "array" ], - "items": { "$ref": "#" }, - "default": {} + "simpleTypes": { + "enum": [ "array", "boolean", "integer", "null", "number", "object", "string" ] }, - - "additionalItems": { - "type": [ { "$ref": "#" }, "boolean" ], - "default": {} + "stringArray": { + "type": "array", + "items": { "type": "string" }, + "minItems": 1, + "uniqueItems": true + } + }, + "type": "object", + "properties": { + "id": { + "type": "string", + "format": "uri" }, - - "required": { - "type": "boolean", - "default": false + "$schema": { + "type": "string", + "format": "uri" }, - - "dependencies": { - "type": "object", - "additionalProperties": { - "type": [ "string", "array", { "$ref": "#" } ], - "items": { - "type": "string" - } - }, - "default": {} + "title": { + "type": "string" }, - - "minimum": { - "type": "number" + "description": { + "type": "string" + }, + "default": {}, + "multipleOf": { + "type": "number", + "minimum": 0, + "exclusiveMinimum": true }, - "maximum": { "type": "number" }, - - "exclusiveMinimum": { - "type": "boolean", - "default": false - }, - "exclusiveMaximum": { "type": "boolean", "default": false }, - - "minItems": { - "type": "integer", - "minimum": 0, - "default": 0 - }, - - "maxItems": { - "type": "integer", - "minimum": 0 + "minimum": { + "type": "number" }, - - "uniqueItems": { + "exclusiveMinimum": { "type": "boolean", "default": false }, - + "maxLength": { "$ref": "#/definitions/positiveInteger" }, + "minLength": { "$ref": "#/definitions/positiveIntegerDefault0" }, "pattern": { "type": "string", "format": "regex" }, - - "minLength": { - "type": "integer", - "minimum": 0, - "default": 0 - }, - - "maxLength": { - "type": "integer" - }, - - "enum": { - "type": "array", - "minItems": 1, - "uniqueItems": true + "additionalItems": { + "anyOf": [ + { "type": "boolean" }, + { "$ref": "#" } + ], + "default": {} }, - - "default": { - "type": "any" + "items": { + "anyOf": [ + { "$ref": "#" }, + { "$ref": "#/definitions/schemaArray" } + ], + "default": {} }, - - "title": { - "type": "string" + "maxItems": { "$ref": "#/definitions/positiveInteger" }, + "minItems": { "$ref": "#/definitions/positiveIntegerDefault0" }, + "uniqueItems": { + "type": "boolean", + "default": false }, - - "description": { - "type": "string" + "maxProperties": { "$ref": "#/definitions/positiveInteger" }, + "minProperties": { "$ref": "#/definitions/positiveIntegerDefault0" }, + "required": { "$ref": "#/definitions/stringArray" }, + "additionalProperties": { + "anyOf": [ + { "type": "boolean" }, + { "$ref": "#" } + ], + "default": {} }, - - "format": { - "type": "string" + "definitions": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} }, - - "divisibleBy": { - "type": "number", - "minimum": 0, - "exclusiveMinimum": true, - "default": 1 - }, - - "disallow": { - "type": [ "string", "array" ], - "items": { - "type": [ "string", { "$ref": "#" } ] - }, - "uniqueItems": true + "properties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, + "default": {} }, - - "extends": { - "type": [ { "$ref": "#" }, "array" ], - "items": { "$ref": "#" }, + "patternProperties": { + "type": "object", + "additionalProperties": { "$ref": "#" }, "default": {} }, - - "id": { - "type": "string", - "format": "uri" + "dependencies": { + "type": "object", + "additionalProperties": { + "anyOf": [ + { "$ref": "#" }, + { "$ref": "#/definitions/stringArray" } + ] + } }, - - "$ref": { - "type": "string", - "format": "uri" + "enum": { + "type": "array", + "minItems": 1, + "uniqueItems": true }, - - "$schema": { - "type": "string", - "format": "uri" - } + "type": { + "anyOf": [ + { "$ref": "#/definitions/simpleTypes" }, + { + "type": "array", + "items": { "$ref": "#/definitions/simpleTypes" }, + "minItems": 1, + "uniqueItems": true + } + ] + }, + "allOf": { "$ref": "#/definitions/schemaArray" }, + "anyOf": { "$ref": "#/definitions/schemaArray" }, + "oneOf": { "$ref": "#/definitions/schemaArray" }, + "not": { "$ref": "#" } }, - "dependencies": { - "exclusiveMinimum": "minimum", - "exclusiveMaximum": "maximum" + "exclusiveMaximum": [ "maximum" ], + "exclusiveMinimum": [ "minimum" ] }, - "default": {} } From 18c4be7f953606a170205d5feabb5bfa12bbb072 Mon Sep 17 00:00:00 2001 From: Geraint Luff Date: Sun, 20 Jan 2013 11:48:50 +0000 Subject: [PATCH 0210/1659] Started re-vamp of website --- content/implementations.html | 109 ++++++++++ content/index.html | 49 +++++ generate.php | 88 ++++++++ implementations.html | 268 ++++++++++++----------- index.html | 222 +++++++------------ lib/links.js | 52 ----- lib/validate.js | 322 ---------------------------- package.json | 31 --- style/css/green-page-background.png | Bin 0 -> 281 bytes style/css/green-theme.css | 155 +++++++++++++ style/css/grey-block-background.png | Bin 0 -> 100 bytes style/js/jquery.js | 4 + style/js/show-hide.js | 24 +++ {lib => style}/json-highlight.css | 0 {lib => style}/json-highlight.js | 0 test/tests.js | 95 -------- 16 files changed, 655 insertions(+), 764 deletions(-) create mode 100644 content/implementations.html create mode 100644 content/index.html create mode 100644 generate.php delete mode 100644 lib/links.js delete mode 100644 lib/validate.js delete mode 100644 package.json create mode 100644 style/css/green-page-background.png create mode 100644 style/css/green-theme.css create mode 100644 style/css/grey-block-background.png create mode 100644 style/js/jquery.js create mode 100644 style/js/show-hide.js rename {lib => style}/json-highlight.css (100%) rename {lib => style}/json-highlight.js (100%) delete mode 100644 test/tests.js diff --git a/content/implementations.html b/content/implementations.html new file mode 100644 index 00000000..c7c2c7e9 --- /dev/null +++ b/content/implementations.html @@ -0,0 +1,109 @@ +
    +

    Implementations below are written in different languages, and support part, or all, of the + specification.

    + +

    Implementations below are classified based on their functionality. When known, the + license of the project is also mentioned.

    +
    + +
    +

    Validators

    +
    +

    JavaScript

    + + +

    Python

    + + +

    Ruby

    + + +

    PHP

    + + +

    Java

    + + +

    .NET

    + + +

    ActionScript 3

    + + +

    C

    + + +

    Haskell

    + +
    + +
    +

    Schema generation

    +
    +

    .NET

    +
      +
    • Json.NET (MIT) - generates schemas from .NET types
    • +
    + +

    Online (web tool)

    + +
    + +
    +

    Data parsing

    +
    +

    Haskell

    + + +

    Ruby

    + +
    + +
    +

    Documentation generation

    +
    +

    JavaScript

    + +
    + +
    +

    Other

    +
    +

    JavaScript

    +
      +
    • Orderly (BSD)
    • +
    • Dojo (AFL or BSD) - supports some aspects of JSON Schema
    • +
    +
    \ No newline at end of file diff --git a/content/index.html b/content/index.html new file mode 100644 index 00000000..c426037c --- /dev/null +++ b/content/index.html @@ -0,0 +1,49 @@ +

    What does it do?

    +
    + + + + + + + + + +
    JSON Schemadescribes your JSON data format
    JSON Hyper-Schematurns your JSON data into hyper-text
    +
    + +

    Advantages

    +
    +

    JSON Schema

    +
      +
    • describes your existing data format
    • +
    • clear, human- and machine-readable documentation
    • +
    • complete structural validation, useful for +
        +
      • automated testing
      • +
      • validating client-submitted data
      • +
      +
    • +
    +

    JSON Hyper-Schema

    +
      +
    • describes your existing API - no new structures required
    • +
    • links (including URI Templates for target URIs)
    • +
    • forms - specify a JSON Schema for the desired data
    • +
    +
    + +

    More

    +
    +

    Interested? Check out: +

    +

    Questions? Feeling helpful? Get involved on: +

    +
    diff --git a/generate.php b/generate.php new file mode 100644 index 00000000..eb3ba12c --- /dev/null +++ b/generate.php @@ -0,0 +1,88 @@ + "index.html", + "docs" => "documentation.html", + "examples" => "examples.html", + "software" => "implementations.html" +); + +$pages = array( + "index.html" => array( + "content" => "content/index.html", + "menu" => "about", + "pageTitle" => "JSON Schema and Hyper-Schema" + ), + "implementations.html" => array( + "content" => "content/implementations.html", + "menu" => "software", + "pageTitle" => "JSON Schema Software" + ) +); + +foreach ($pages as $outputFile => $pageSpec) { + echo "Rendering: $outputFile:\n"; + ob_start(); +?> + + + + <?php echo $pageSpec['pageTitle']; ?> + + + + + + +
    + + +
    + + + +
    +
    + + + + + \ No newline at end of file diff --git a/implementations.html b/implementations.html index 38ac0a44..fb972082 100644 --- a/implementations.html +++ b/implementations.html @@ -1,126 +1,146 @@ - - - - JSON Schema Implementations - - - - - - -
    -
    -
    - -
    -
    - -
    -
    - -

    Preliminary note

    - -

    Implementations below are written in different languages, and support part, or all, of the -specification. This page only lists the implementaions and links to them, and does not specify the -level of JSON Schema support.

    - -

    Implementations below are classified based on their programming language. When known, the -license of the project is also mentioned.

    - -
    -
    - -

    C

    - - - -

    Java

    - - - -

    .NET

    - - -

    ActionScript 3

    - - - -

    Haskell

    - - - -

    Python

    - - - -
    - -
    - -

    Ruby

    - - - - -

    PHP

    - - - -

    JavaScript

    - - - -
    -
    -
    -
    -
    - + + + JSON Schema Software + + + + + + +
    + + +
    + + +
    +

    Implementations below are written in different languages, and support part, or all, of the + specification.

    + +

    Implementations below are classified based on their functionality. When known, the + license of the project is also mentioned.

    +
    + +
    +

    Validators

    +
    +

    JavaScript

    + + +

    Python

    + + +

    Ruby

    + + +

    PHP

    + + +

    Java

    + + +

    .NET

    + + +

    ActionScript 3

    + + +

    C

    + + +

    Haskell

    + +
    + +
    +

    Schema generation

    +
    +

    .NET

    +
      +
    • Json.NET (MIT) - generates schemas from .NET types
    • +
    + +

    Online (web tool)

    + +
    + +
    +

    Data parsing

    +
    +

    Haskell

    + + +

    Ruby

    + +
    + +
    +

    Documentation generation

    +
    +

    JavaScript

    + +
    + +
    +

    Other

    +
    +

    JavaScript

    +
      +
    • Orderly (BSD)
    • +
    • Dojo (AFL or BSD) - supports some aspects of JSON Schema
    • +
    +
    +
    + + + diff --git a/index.html b/index.html index 4b23e886..c4744456 100644 --- a/index.html +++ b/index.html @@ -1,145 +1,87 @@ - - - JSON Schema - - - - - -
    -
    -
    - -
    -
    -
    -
    - -

    What is JSON Schema

    - -

    JSON Schema is a JSON based format for describing JSON data.

    - -

    JSON Schema is a proposed Internet draft defining a JSON media type (application/schema+json) with the following goals:

    - -
    -
    Validation
    You can use JSON Schema to validate your JSON data.
    -
    Documentation
    You can extract documentation information from a JSON -Schema, match this documentation to your data, and use that information for user -interaction.
    -
    Hyperlinking
    You can pair your JSON data with the defining JSON -Schema to build hyperlinks into parts of that JSON data.
    -
    -

    JSON Schema by example

    - -

    Here is a basic example of a JSON Schema: - -

    -{
    -	"title": "Example Schema",
    -	"type": "object",
    -	"properties": {
    -		"firstName": {
    -			"type": "string"
    -		},
    -		"lastName": {
    -			"type": "string"
    -		},
    -		"age": {
    -			"description": "Age in years",
    -			"type": "integer",
    -			"minimum": 0
    -		}
    -	},
    -	"required": ["firstName", "lastName"]
    -}
    -
    - -

    The two examples below are step-by-step guides into building a schema:

    - -
      -
    • this first example is a simple example which covers a classical -product catalog description;
    • -
    • this second example is more advanced, and uses JSON Schema to -describe filesystem entries in a Unix-like /etc/fstab file.
    • -
    - -

    JSON Schema standard draft

    - -

    The latest IETF published draft is v3. While not yet published, -v4 - of the draft is being updated on github.

    -

    JSON Schema also uses two other specifications:

    - - - -

    Implementations

    - -

    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.

    - -

    Contributing

    - -

    JSON Schema as a whole (this site, the specifications, and related projects) -can be found on GitHub. -Feature/pull requests are welcome.

    - -

    Reference schemas

    - -

    JSON Schema defines meta schemas. These are schemas which can be used to -validate other schemas (including themselves). Those are:

    - -
    -
    Core Meta-Schema
    Used for schemas written -for pure validation.
    -
    Hyper Meta-Schema
    Used for schemas -written for validation and hyper linking.
    -
    - -

    Sample schemas

    + + + JSON Schema and Hyper-Schema + + + + + + +
    + + +
    + + +

    What does it do?

    +
    + + + + + + + + + +
    JSON Schemadescribes your JSON data format
    JSON Hyper-Schematurns your JSON data into hyper-text
    +
    -

    These sample schemas describe simple data structures which can be expressed as JSON:

    +

    Advantages

    +
    +

    JSON Schema

    +
      +
    • describes your existing data format
    • +
    • clear, human- and machine-readable documentation
    • +
    • complete structural validation, useful for +
        +
      • automated testing
      • +
      • validating client-submitted data
      • +
      +
    • +
    +

    JSON Hyper-Schema

    +
      +
    • describes your existing API - no new structures required
    • +
    • links (including URI Templates for target URIs)
    • +
    • forms - specify a JSON Schema for the desired data
    • +
    +
    -
    -
    Geographic Coordinate
     
    -
    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.
    -
    -

    -
    -
    +

    More

    +
    +

    Interested? Check out: +

    +

    Questions? Feeling helpful? Get involved on: +

    - - +
    +
    + + + diff --git a/lib/links.js b/lib/links.js deleted file mode 100644 index 5b1bbbfd..00000000 --- a/lib/links.js +++ /dev/null @@ -1,52 +0,0 @@ -/** - * JSON Schema link handler - * Copyright (c) 2007 Kris Zyp SitePen (www.sitepen.com) - * Licensed under the MIT (MIT-LICENSE.txt) license. - */ -({define:typeof define!="undefined"?define:function(deps, factory){module.exports = factory();}}). -define([], 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/validate.js b/lib/validate.js deleted file mode 100644 index be4a93b2..00000000 --- a/lib/validate.js +++ /dev/null @@ -1,322 +0,0 @@ -/** - * 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: -"property" which indicates which property had the error -"message" which indicates what the error was - */ -({define:typeof define!="undefined"?define:function(deps, factory){module.exports = factory();}}). -define([], function(){ -var exports = validate; -// setup primitive classes to be JSON Schema types -exports.Integer = {type:"integer"}; -var primitiveConstructors = { - String: String, - Boolean: Boolean, - Number: Number, - Object: Object, - Array: Array, - Date: Date -} -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). - // 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, {changing: false});//, coerce: false, existingOnly: 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, {changing: property || "property"}); - }; -var validate = exports._validate = function(/*Any*/instance,/*Object*/schema,/*Object*/options) { - - 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){ - - var l; - if(typeof i !== 'undefined') { - if(typeof i === 'number') { - path += '[' + i + ']'; - } else { - var escaped = i.replace(/\./g, '\\.'); - path += path ? ('.' + escaped) : escaped; - } - } - 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, value); - } - }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",schema:schema,value:value}]; - } - 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.required){ - addError("is missing and it is required"); - } - }else{ - errors = errors.concat(checkType(getType(schema),value)); - if(schema.disallow && !checkType(schema.disallow,value).length){ - addError(" disallowed value was matched", value); - } - if(value !== null){ - if(value instanceof Array){ - if(schema.items){ - var itemsIsArray = schema.items instanceof Array; - var propDef = schema.items; - for (var i = 0, l = value.length; i < l; i += 1) { - if (itemsIsArray) - propDef = schema.items[i]; - if (options.coerce) - value[i] = options.coerce(value[i], propDef); - errors.concat(checkProp(value[i],propDef,path,i)); - } - } - if(schema.minItems && value.length < schema.minItems){ - 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", 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.", value); - break; - } - } - } - } - }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, value); - } - if(schema.maxLength && typeof value == 'string' && value.length > schema.maxLength){ - 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", value); - } - if(typeof schema.minimum !== undefined && typeof value == typeof schema.minimum && - schema.minimum > value){ - 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, value); - } - 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(", "), 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", value); - } - } - } - return null; - } - // 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){ - addError("an object is required", instance); - } - - for(var i in objTypeDef){ - if(objTypeDef.hasOwnProperty(i)){ - 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(options.coerce && i in instance){ - value = instance[i] = options.coerce(value, propDef); - } - checkProp(value,propDef,path,i); - } - } - } - 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]; - continue; - } else { - 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)){ - 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))){ - 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)); - } - } - 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 || ''); - } - 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")); - } -} - -return exports; -}); diff --git a/package.json b/package.json deleted file mode 100644 index 0ff652a7..00000000 --- a/package.json +++ /dev/null @@ -1,31 +0,0 @@ -{ - "name": "json-schema", - "version": "0.2.2", - "author": "Kris Zyp", - "description": "JSON Schema validation and specifications", - "maintainers":[ - {"name": "Kris Zyp", "email": "kriszyp@gmail.com"}], - "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" }, - "main": "./lib/validate.js", - "devDependencies": { "vows": "*" }, - "scripts": { "test": "echo TESTS DISABLED vows --spec test/*.js" } -} - diff --git a/style/css/green-page-background.png b/style/css/green-page-background.png new file mode 100644 index 0000000000000000000000000000000000000000..9467ec5a7509e08057ee3586e9f0db85c274f7ea GIT binary patch literal 281 zcmV+!0p|XRP)l1oWTYJv5G^j2ge=Rs`l9Sccnu&Pa!Zq6FoxKt&l z?WMlG2PzkBG*~-x`bE`8tqn<=#vDg?_n5UQe*syyQR+%%N70&&t-1 in e)}function r(e){var t=Tt[e]={};return st.each(e.match(lt)||[],function(e,n){t[n]=!0}),t}function i(e,n,r,i){if(st.acceptData(e)){var o,a,s=st.expando,u="string"==typeof n,l=e.nodeType,c=l?st.cache:e,f=l?e[s]:e[s]&&s;if(f&&c[f]&&(i||c[f].data)||!u||r!==t)return f||(l?e[s]=f=K.pop()||st.guid++:f=s),c[f]||(c[f]={},l||(c[f].toJSON=st.noop)),("object"==typeof n||"function"==typeof n)&&(i?c[f]=st.extend(c[f],n):c[f].data=st.extend(c[f].data,n)),o=c[f],i||(o.data||(o.data={}),o=o.data),r!==t&&(o[st.camelCase(n)]=r),u?(a=o[n],null==a&&(a=o[st.camelCase(n)])):a=o,a}}function o(e,t,n){if(st.acceptData(e)){var r,i,o,a=e.nodeType,u=a?st.cache:e,l=a?e[st.expando]:st.expando;if(u[l]){if(t&&(r=n?u[l]:u[l].data)){st.isArray(t)?t=t.concat(st.map(t,st.camelCase)):t in r?t=[t]:(t=st.camelCase(t),t=t in r?[t]:t.split(" "));for(i=0,o=t.length;o>i;i++)delete r[t[i]];if(!(n?s:st.isEmptyObject)(r))return}(n||(delete u[l].data,s(u[l])))&&(a?st.cleanData([e],!0):st.support.deleteExpando||u!=u.window?delete u[l]:u[l]=null)}}}function a(e,n,r){if(r===t&&1===e.nodeType){var i="data-"+n.replace(Nt,"-$1").toLowerCase();if(r=e.getAttribute(i),"string"==typeof r){try{r="true"===r?!0:"false"===r?!1:"null"===r?null:+r+""===r?+r:wt.test(r)?st.parseJSON(r):r}catch(o){}st.data(e,n,r)}else r=t}return r}function s(e){var t;for(t in e)if(("data"!==t||!st.isEmptyObject(e[t]))&&"toJSON"!==t)return!1;return!0}function u(){return!0}function l(){return!1}function c(e,t){do e=e[t];while(e&&1!==e.nodeType);return e}function f(e,t,n){if(t=t||0,st.isFunction(t))return st.grep(e,function(e,r){var i=!!t.call(e,r,e);return i===n});if(t.nodeType)return st.grep(e,function(e){return e===t===n});if("string"==typeof t){var r=st.grep(e,function(e){return 1===e.nodeType});if(Wt.test(t))return st.filter(t,r,!n);t=st.filter(t,r)}return st.grep(e,function(e){return st.inArray(e,t)>=0===n})}function p(e){var t=zt.split("|"),n=e.createDocumentFragment();if(n.createElement)for(;t.length;)n.createElement(t.pop());return n}function d(e,t){return e.getElementsByTagName(t)[0]||e.appendChild(e.ownerDocument.createElement(t))}function h(e){var t=e.getAttributeNode("type");return e.type=(t&&t.specified)+"/"+e.type,e}function g(e){var t=nn.exec(e.type);return t?e.type=t[1]:e.removeAttribute("type"),e}function m(e,t){for(var n,r=0;null!=(n=e[r]);r++)st._data(n,"globalEval",!t||st._data(t[r],"globalEval"))}function y(e,t){if(1===t.nodeType&&st.hasData(e)){var n,r,i,o=st._data(e),a=st._data(t,o),s=o.events;if(s){delete a.handle,a.events={};for(n in s)for(r=0,i=s[n].length;i>r;r++)st.event.add(t,n,s[n][r])}a.data&&(a.data=st.extend({},a.data))}}function v(e,t){var n,r,i;if(1===t.nodeType){if(n=t.nodeName.toLowerCase(),!st.support.noCloneEvent&&t[st.expando]){r=st._data(t);for(i in r.events)st.removeEvent(t,i,r.handle);t.removeAttribute(st.expando)}"script"===n&&t.text!==e.text?(h(t).text=e.text,g(t)):"object"===n?(t.parentNode&&(t.outerHTML=e.outerHTML),st.support.html5Clone&&e.innerHTML&&!st.trim(t.innerHTML)&&(t.innerHTML=e.innerHTML)):"input"===n&&Zt.test(e.type)?(t.defaultChecked=t.checked=e.checked,t.value!==e.value&&(t.value=e.value)):"option"===n?t.defaultSelected=t.selected=e.defaultSelected:("input"===n||"textarea"===n)&&(t.defaultValue=e.defaultValue)}}function b(e,n){var r,i,o=0,a=e.getElementsByTagName!==t?e.getElementsByTagName(n||"*"):e.querySelectorAll!==t?e.querySelectorAll(n||"*"):t;if(!a)for(a=[],r=e.childNodes||e;null!=(i=r[o]);o++)!n||st.nodeName(i,n)?a.push(i):st.merge(a,b(i,n));return n===t||n&&st.nodeName(e,n)?st.merge([e],a):a}function x(e){Zt.test(e.type)&&(e.defaultChecked=e.checked)}function T(e,t){if(t in e)return t;for(var n=t.charAt(0).toUpperCase()+t.slice(1),r=t,i=Nn.length;i--;)if(t=Nn[i]+n,t in e)return t;return r}function w(e,t){return e=t||e,"none"===st.css(e,"display")||!st.contains(e.ownerDocument,e)}function N(e,t){for(var n,r=[],i=0,o=e.length;o>i;i++)n=e[i],n.style&&(r[i]=st._data(n,"olddisplay"),t?(r[i]||"none"!==n.style.display||(n.style.display=""),""===n.style.display&&w(n)&&(r[i]=st._data(n,"olddisplay",S(n.nodeName)))):r[i]||w(n)||st._data(n,"olddisplay",st.css(n,"display")));for(i=0;o>i;i++)n=e[i],n.style&&(t&&"none"!==n.style.display&&""!==n.style.display||(n.style.display=t?r[i]||"":"none"));return e}function C(e,t,n){var r=mn.exec(t);return r?Math.max(0,r[1]-(n||0))+(r[2]||"px"):t}function k(e,t,n,r,i){for(var o=n===(r?"border":"content")?4:"width"===t?1:0,a=0;4>o;o+=2)"margin"===n&&(a+=st.css(e,n+wn[o],!0,i)),r?("content"===n&&(a-=st.css(e,"padding"+wn[o],!0,i)),"margin"!==n&&(a-=st.css(e,"border"+wn[o]+"Width",!0,i))):(a+=st.css(e,"padding"+wn[o],!0,i),"padding"!==n&&(a+=st.css(e,"border"+wn[o]+"Width",!0,i)));return a}function E(e,t,n){var r=!0,i="width"===t?e.offsetWidth:e.offsetHeight,o=ln(e),a=st.support.boxSizing&&"border-box"===st.css(e,"boxSizing",!1,o);if(0>=i||null==i){if(i=un(e,t,o),(0>i||null==i)&&(i=e.style[t]),yn.test(i))return i;r=a&&(st.support.boxSizingReliable||i===e.style[t]),i=parseFloat(i)||0}return i+k(e,t,n||(a?"border":"content"),r,o)+"px"}function S(e){var t=V,n=bn[e];return n||(n=A(e,t),"none"!==n&&n||(cn=(cn||st("