Versions Compared

Old Version 11

changes.mady.by.user Former user

Saved on

compared with

New Version 12

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Validation JSON file types

Introduction

This function is designed to validate data according by processing the received data according to the designated rules and conventions in UDP. Regarding the JSON file types and objects, they are to be checked according the official JSON Schema Validation definitions, approved by the IETF Trust. Each JSON schema object is to be independently examined by the built-in engine for validity.

Interoperability Considerations

For the purpose of maintaining interoperability and according to the official JSON Schema regulations, several considerations are accounted for during validation. All of the listed conditions are implemented by following the official regulations. No exceptions or special cases are made, unless they are explicitly specified in the official UDP documentation.

...

It is important to note that at all times JSON schema data should be entered in accordance with the official specifications.=

Validation keywords for all instance types

Validation for keywords for all instance types are governed by the following rules for each JSON file type object:

...

  • tuple – Tuple refers to a set of objects which are ordered together and immutable. They cannot be changed and operate the same manner as “string” data types. Validation is performed for the whole array of items placed inside the tuple instance. 
  • oneOf – oneOf validation is used to compare data between items exactly as shown in the current schema configuration. 
  • nestedObject – Nested objects are complex structures that includes a “parent” JSON object that has “child” properties attached to it. Validation is performed on the whole iteration. 
  • reference – A reference keyword is a valid instance that points to a given location, that is indicated by the referenced value. 

Validation keywords for Numeric Instance Types

This section lists the validation framework for the JSON numeric instance types:

  • multipleOf – The entered value must be a number greater than 0. Validation is performed when the division of the entered value results in an integer.
  • maximum – The entered value must be a number, representing an upper limit for the given numeric instance. Validation is performed when the instance is less or equal to the “maximum” value.
  • exclusiveMaximum -- The entered value must be a number, representing an upper limit for the given numeric instance. Validation is performed when the instance is less than the “exclusive maximum” value. It will not validate if it is equal to the value.
  • minimum – The entered value must be a number, representing an inclusive lower limit for the given numeric instance. Validation is performed if the instance is greater or equal to the “minimum” value.
  • exclusiveMinimum – The entered value must be a number, representing an exclusive lower limited for the given numeric instance. Validation is performed when the instance is greater than the “exclusive Minimum” value.

Validation keywords for String Instance Types

This section lists the validation framework for the JSON string instance types:

  • maxLength – The entered value must be a non-negative integer. Validation is performed when the string instance is equal to a length that is less than, or equal to the designated keyword value.
  • minLength – The entered value must be a non-negative integer. Validation is performed when the string instance is greater than, or equal to the designated keyword value. When this keyword is omitted, the UDP service will treat it as being a value with “0” length.
  • pattern – The entered value must be a valid string expression. Validation is performed if the expression matches the defined instance.

Validation keywords for Array Instance Types

This section lists the validation framework for the JSON array instance types:

  • 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 for each name that appears in both the instance and the keyword value name corresponding to the array item. 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.

...

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 if it contains the “contentMediaType” property with appropriate structure descriptions. This keyword may be used with any media type that is capable to be mapped to the valid JSON schema model. If “contentMediaType” is not present, the whole property value will be ignored.

Meta-Data Annotations Considerations

The keywords found in this section are commonly used for documentation and user interface display purposes. They are not designed to be used in comprehensive feature sets.

  • “title” and “description” – Both of these vales must be of the string data type. They are used to decorate a user interface about the data found in them. It is recommended to keep the “title” short, whereas the “description” should carry the explanation for the purpose of the instance.
  • “default” – No restrictions are placed on this keyword value. Duplicated entries should be removed, if such are found. The “default” keyword is used to supply a default JSON value to be used with a given schema.
  • “deprecated” – This keyword value must be of the boolean data type. If multiple occurrences are applicable to a single instance, the applications will consider the location to be deprecated. If the boolean value is “true”, then the service should refrain from using the given property. A root schema that contains the “deprecated” keyword with a “true” boolean status will indicate that the entire resource may be removed in the future. This keyword will apply to each instance location to which the schema object applies to. If this keyword is omitted, the service will consider it as having the same behaviour as a value of “false”.
  • “readOnly” and “writeOnly” – The values that are input for this keyword must be of the Boolean data type. If there are multiple occurrences, then the results will be processed as considering them as “true” statements. If the “readOnly” boolean value is set to “true”, then the service will process the value in accordance with the owning authority. Any external attempts to modify value properties will be ignored or rejected. Instances that are marked with “writeOnly” for the whole document, may produce an error upon retrieval. This keyword can be used to mark sections like password input fields. When these keywords are omitted, then their behavior for a “false” statement will be considered.
  • “examples” – The value of this keyword must be an array; no restrictions are placed for the values inside of it. If there are multiple occurrences of this keyword, then the implementation is to provide a flat array of all listed values. This keyword is used to provide sample JSON values that are associated with a particular example. It is recommended that the input values are valid according to the defined schema model. Users can use the “default” value as an additional example.

Security Considerations

When validation of JSON schema is performed, the users need to carefully consider possible security-related implications and possible issues. There are some important best practices that are regulated by the applicable standards. This is especially true for Unicode characters, where a security standard is in place.

...