...
- maxItems – The entered value must be a non-negative integer. Validation is performed when the array size is less than, or equal to the value of the input keyword.
- minItems – The entered value must be a non-negative integer. Validation is performed when the array size is greater than, or equal to the value of the input keyword. When this keyword is omitted, the UDP service will treat it as being a value with “0” length.
- uniqueItems – The entered value must be a Boolean. Validation will be done if the value is “false”. “True” validation is done only when all of the array instances are unique. When this keyword is omitted, the UDP service will treat it as having a value of “false”.
- maxCointains – The entered value must be a non-integer. The keyword will have no effect if the “contains” values are not present within the same schema object. Validation is performed, depending on the annotation results of the adjacent “contains” keyword in two ways. Validation will pass if the annotation results is an array with a length that is less or equal to the “maxContains” value. The other validation option is by having the annotation result as a “true” boolean value with an array instance with a length that is less or equal to the “maxContains” value.
- minContains – The entered value must be a non-negative integer. The keyword will have no effect if the “contains” values are not present within the same schema object. Validation is performed, depending on the annotation results of the adjacent “contains” keyword in two ways. Validation will pass if the annotation result is an array with a length that is greater or equal to the “minContains” value. The other validation option is by having the annotation result as a “true” Boolean value with an array instance that is greater or equal to the “minContains” value. When this keyword is omitted, the UDP service will treat is having the same behavior as a value of “1”. Validation allows a value of “0”, but that is only useful for setting up a range a of occurrences from “0” going up to the value of “maxContains”.
Validation keywords for Object Instance Types
This section lists the validation framework for the JSON object instance types:
- maxProperties – The entered value must be a non-negative integer. Validation is performed for this object instance when the number of the properties Is less than, or equal to the value of this keyword.
- minProperties – The entered value must be a non-negative integer. Validation is performed for this object instance when the number of the properties is greater than, or equal to the value of the keyword.
- required – The entered value must be an array. Its elements (if any) must be of string data types and uniquely named. Validation is performed if every item in the array is the name of the property in the instance. When this keyword is omitted, the keyword will be regarded as having the same behaviour as an empty array.
- dependentRequired – The entered value must be an object. If there are any properties, they must be of the array data type. Their elements (if any) must be of string data types and uniquely named. This particular keyword will have specific properties, depending on the available properties. Requirements for them are dependent on the presence of other properties within the schema. Validation is performed when for each name that appears in both the instance and the keyword value name corresponds to the item in the array. These items must have the names of the properties in the given instance. When this keyword is omitted, the keyword will be regarded as having the same behaviour as an empty object.
Validation keywords for Semantic content with “format”
Utilization of certain values cannot be done by solely relying on structural validation. For this reason, the “format” annotation keyword has been defined for JSON schema. It is intended to convey semantic information for a fixed subset of values. The values that correspond to the “format” semantic content are called format attributes.
These format attributes must be of the string data type. They generally validate only a given set of instance types. If the validation type is not part of this set, then the overall validation for the format attribution should succeed during processing. The format attributes can be specified to any instance types as defined by the current JSON schema data model.
As such there are two specific vocabularies that have been developed and implemented in the service:
- Format-Annotation Vocabulary – The value of this format must be collected as an annotation, if the used implementation supports such a collection. This is done to ensure the validation is done on an application-level, if the schema validation for individual objects is not available. Implementations can still be treated as a “format” in certain situations, as assertions that can attempt to validate the values. In such cases these implementations are to document their level of support for the validation.
- Format-Assertion Vocabulary – The vocabulary will be declared with “true” value when implementations provide full validation support for all formats. If these implementations cannot validate the full schema, processing will not occur.
Custom format attributes may be supported in the listed implementations. It is recommended to define the additional keywords in the custom vocabulary.
Validation for Defined Formats
Attributes apply to the string instances that correspond to defined formats. They are standardized according to international agreements and technical specifications. When implemented they should uphold the following rules:
- date-time – This string instance is valid if it is a correct representation according to the “date-time” production specification.
- date – This string instance is valid if it is a correct representation according to the “full-date” production specification.
- time – This string instance is valid if it is a correct representation according to the “full-time” production specification.
- duration – This string instance is valid if it is a correct representation according to the “duration” production specification.
- email – This string instance is valid if it is a correct representation of an Internet email address. Strings valid against the “email” attribute are also valid against “idn-email” as well.
- idn-email – This string instance is valid if it is a correct representation of an “extended mailbox” attribute.
- hostname – This string instance is valid if it is a correct representation of an Internet hostname. Strings that are valid against “hostname” are also valid against the “idn-hostname” attribute.
- idn-hostname – This string instance is valid if it is a correct representation of an internationalized hostname.
- ipv4 – This string instance is valid if it is a correct representation of an IP address as defined by the “dotted-quad” ABNF syntax.
- ipv6 – This string instance is valid if it is a correct representation of an IP address confronting to Ipv6 specifications.
- uri – This string instance is valid if it is a correct URI (Uniform Resource Identifier) according to the relevant RFC specifications. To indicate UUIDs as URNs, use the “uri” format, with a “pattern” regular expression of "^urn:uuid:" to indicate the URI scheme and URN namespace.
- uri-reference – This string instance is valid if it is a correct reference, corresponding to either a URI or a relative-reference to it, according to the relevant RFC specifications.
- iri – This string instance is valid if it is a correct representation of an IRI (Internationalized Resource Identifier), according to the relevant RFC specifications.
- iri-reference – This string instance is valid if it is a correct representation of a IRI reference or a relative-reference, according to the relevant RFC specifications.
- uuid – This string instance is valid if it is a correct representation of an UUID (Universally unique identifier), according to specifications. This format supports only “plain” UUIDs.
- uri-template – This string instance is valid if it is a correct URI Template, according to the relevant RFC specifications.
- json-pointer – This string instance is valid if it is a correct JSON string representation of a JSON pointer, according to the relevant RFC specifications.
- relative-json-pointer – This string instance is valid if it is a correct relative JSON pointer, according to the relevant RFC specifications.
- regex – This string instance is valid if it is a correct regular expression, according to the ECMA-262 regular expression dialect specifications.
Validation for string-encoded data contents
This section lists the validation requirements for the contents that comprise of string-encoded data. There are specific implementation rules that need to be followed to perform a successful validation. For security purposes the entered implementations must not perform decode, parse and/or validate the string contents automatically. Each string-encoded document is to be evaluated according to the set standards on a conditional basis. All keywords in this section apply only to string data types and have no effect on other data types. Validation is performed for the following data contents:
- contentEncoding – Validation is performed if this string instance confronts to several standards. Possible values that are accepted by the system include base-16/32/64 encodings that are listed in RFC-4648. Validation is also done for encodings that are used in MIME file types, according to RFC 2045. All encoding results consist of 7-bit ASCII characters. If the “contentMediaType” is present, but “contentEncoding” is absent, then this will indicate that no transformation is required to represent the content in a UTF-8 string.
- contentMediaType – This string instance is valid if it corresponds to the media type of the relevant contents. If “contentencoding” is present, then this property will refer to the decoded string. The string that is entered must be a valid media type, as defined by the relevant RFC specifications.
- contentSchema – This string instance is valid
Meta-Data Annotations Considerations
...