Objects and Properties
An object is enclosed in curly braces and maps a key to a value, like this: "MyKey": Value. The key must always be a string and must therefore be enclosed in quotes. The value can be any JSON data type. Each key:value pair is known as a property of the object (see screenshot below).
Here is an example of an instantiated object that has three properties:
{
"emailtype": "home",
"emailaddress": "contact01.home@altova.com",
"citycode": 22
}
The schema for the object would look something like this in Design View.
Notice the following:
•Each of the properties must be present in the instance. This is indicated by the solid borders of the properties. If a property is optional, the border is a dashed line. You can set whether a property is required or optional in the property's context menu or via the Details entry helper.
•The order in which properties must occur in the instance is not—and cannot be—defined in the schema. This means that the order in which properties are defined in the schema is irrelevant.
•The blue-square-within-braces symbol signifies a property (as opposed to a pattern property or property wildcard, both of which are indicated by other symbols; see below).
•The type of a property can be edited by double-clicking the type in the diagram and selecting an option from the dropdown list that appears. Alternatively, the type can be selected in the Details entry helper.
•The constraint value of the emailaddress property is defined in the Constraints entry helper.
Properties, pattern properties, property wildcards, and property names schemas
An object can have properties, pattern properties, property wildcards, and property names schemas (new in draft-07). These can be added to the object via the context menus: (i) of the object, (ii) of the yellow properties box (right-click the Properties title of the box), and (iii) of individual properties. Properties have been described above. We now look at pattern properties and property wildcards.
Pattern property
A pattern property (screenshot below) defines the property's name as a regular expression. In the screenshot below, for example, the regular expression specifies that the property must: (i) have a name that begins with an underscore, and (ii) have a boolean as its value. There is no requirement constraint for a pattern property. You can add any number of pattern properties. Notice the icon for pattern properties.
Property wildcard
A property wildcard (screenshot below) specifies that any number of properties can occur in addition to the other properties of the object's property set. The wildcard can however define a type for these occurrences. The screenshot below left shows a property wildcard that defines properties with any name but having numeric values. There can be only one property wildcard per object. If the wildcard is set to Any type, however, then you can set constraints for each type in the Constraints entry helper. Notice the icon for property wildcards.
From draft-2019-09 onwards, property wildcards have a new keyword unevaluatedProperties, which is processed only if the additionalProperties keyword is missing. The values of these two keywords are produced by setting appropriate values for the Specified, Applies to, and Type entries in a wildcard's Details entry helper (screenshot below).
The effect of these values on the keywords unevaluatedProperties and additionalProperties (and, vice versa, the effect of the keywords on the editor's entry helper values) are given in the table below. The screenshot above, for example, sets unevaluatedProperties=true.
addtionalProperties | unevaluatedProperties |
| Specified | Applies to | Type |
-- | -- | <=> | false | All | Unconstrained |
true | ignored | <=> | true | All | Unconstrained |
false | ignored | <=> | -- | -- | -- |
Schema | ignored | <=> | true | All | Schema type |
-- | true | <=> | true | Unevaluated | Unconstrained |
-- | false | <=> | true | Unevaluated | Forbidden |
-- | Schema | <=> | true | Unevaluated | Schema type |
Note the following points:
•If addtionalProperties and unevaluatedProperties are present, then unevaluatedProperties is ignored.
•Specified=false only works with Scope=All and Type=Unconstrained.
Property names schema
A property names schema (screenshot below) constrains the names of that object's properties. (This feature is new in draft-07.) For example, in the screenshot below, we can see that the names of properties must be strings. Additionally, we can specify further constraints for the property name via the Constraints entry helper: for example, that the property's name fall within a certain character length range or that it have a certain pattern.
| Note: | There are no minimum or maximum occurrence settings for a pattern property or property wildcard. See the section about property validation to understand this better. |
How properties are validated
When a property is encountered in the instance, it is validated as follows:
1.The property's name is checked in the schema against all the named properties of that object.
2.If no match is found, the name is checked against all pattern properties in the object's property set.
3.If still no match is found, then the wildcard is invoked if it exists.
4.If still no match is found for the name, a validity error is reported. If the name matches that of a property or pattern property, or if a wildcard exists, then the value is checked against the value of the corresponding property definition.
5.If the instance value matches the type and constraints of the corresponding property definition, then the property is valid. Otherwise it is invalid.
Example
The screenshot below defines an object which:
•must have three properties named emailtype, emailaddress, and citycode
•can have one or more properties with a name that begins with an underscore and a value that is a boolean (see the pattern property in the screenshot below)
•can have one or more additional properties with any name and any value
