The JSON Schema View entry helpers are located by default on the right-hand side of the application window. They are available in both modes of the main window: (i) Definitions Overview Grid, and (ii) Design View. You can drag entry helper windows by their title bars to other locations on the screen, and you can double-click an entry helper's title bar to alternatively dock and undock that entry helper. For more information about these actions, see the section Entry Helpers.
The Overview entry helper (screenshot below) lists the current schema definition and all the global definitions of the current schema. Double-clicking a definition, opens that definition in Design View, where it can be edited. If you wish to use definitions from external schemas, first add the external schema, then reuse the definition you want.
Add the external schema by clicking the Add New Schema icon in the Overview entry helper and then browsing for the schema you wish to add. Once a schema has been added, its definitions are displayed in the Overview entry helper. The screenshot below, for example, shows that the schema TelNumbers.json has been added, and that this schema has one definition named USTelephoneNumbers. You can add as many external schemas as you like.
After an external schema has been added, its definitions become available for reuse in the definitions of the importing schema. When one definition reuses another definition (by referencing it), it takes on the properties of that definition. The referencing can be done in two ways:
•In Design View: By dragging a definition from the Overview entry helper onto the definition where it is wanted
•In Definitions Overview Grid or Design View: Via the Reference field of the Details entry helper of the definition where the reuse is wanted. This is explained below in the description of the Details entry helper.
|Note:||The Refresh icon next to the External Schemas entry in the Overview window updates all added external schemas. Note that, If no definition from an added external schema has been reused, then that schema will be removed from the list when the list is refreshed.|
The properties of a definition can be entered in the Details and Constraints windows when the definition is selected in either mode of the main window: Definitions Overview Grid or Design View. The screenshot below shows the definition of USTelephoneNumbers in Design View, together with the Detail and Constraints entry helpers. Notice that the information in the two entry helpers is also displayed in the definition's (blue) box in Design View. The properties that can be set in these two entry helpers are listed below.
The following details can be entered in the Details entry helper:
•Name: The name of the definition.
•Reference: If you want a definition to reuse another definition, click the Additional Dialog button of the Reference field (see screenshot above). This displays the Edit Reference dialog, which lists all available definitions (from the current schema and external schemas). Select the definition you want to reuse, select the Relative Path option if you want a relative path, and click OK. See Global and Local Definitions for details.
•Type: Select the definition's datatype from the dropdown list of the combo box. Note that changing the type will lead to the removal of keywords specific to the previous type. If you wish to go back to the previous definitions, press Undo (Ctrl-Z). The types are explained in JSON Data and Type Selectors (Any, Multiple, etc).
•ID: This is an optional keyword that defines a URI for the schema. This URI can be used to reference the schema and is used as the base URI for other URI references within the schema. The ID value must be a string that is a URI. Note that the Altova JSON validator uses canonical de-referencing only. See the JSON specification for more information.
•Anchor (new in draft-2019-09): This is an optional identifier keyword that provides a plain name fragment (and not a URI as is the case with ID). The value of Anchor must be a string as described in the respective drafts.
•Title, Description: The values of these two keywords are used for descriptive purposes that can be read by the end-user.
•Comment (new in draft-07): Intended for notes to schema maintainers, as opposed to Description, which is intended for end-users.
•Const (new in draft-06): A constant value, like a one-value enumeration.
•Default: The default value of the definition.
•Read-only, Write-only (new in draft-07): These indicate, respectively, read-only and write-only fields. An example of a write-only field would be a password field.
•Deprecated (new in draft-2019-09): An indicator that the selected definition may be removed in the future. Applications can handle such definitions in a special way.
A definition's constraints depends on its type. The constraints of each type are described below. (See also Atomic Types.)
If a type does not appear in the list below, no constraint can be defined for it. Note, however, that enumerations can be defined for all types:
•String: The length of the string, and the pattern of the string; the pattern is specified by means of a regular expression. In the Format field, you can select one of the string formats defined in the specification (see screenshot above, which shows the formats available in draft-04); additional formats have been defined in later versions. Content Media Type and Content Encoding (both new in draft-07) select the media type and encoding of non-JSON data encoded in a JSON string.
•Numeric: The range of allowed values
•Array: The number of items allowed in the array and whether items must be unique
•Object: The number of allowed properties
The Constraints entry helper for all types has an Enumerations tab. In it, you can specify a list of allowed items of that definition's type. Additionally, an Examples tab is available (new in draft-06) for all types except Forbidden. This is an array of examples with no validation effect; the value of default is usable as an example without repeating it under this keyword.