JSON Structure: Core

JSON Structure Core Specification

Schema Elements

Schema A "schema" is a JSON object that describes, constrains, and interprets a JSON node. This schema constrains a JSON node to be of type string: In the case of a schema that references a compound type (object, set, array, map, tuple, choice), the schema further describes the structure of the compound type. Schemas can be placed into a namespace () for reuse in other schemas. All schemas have an associated name that serves as an identifier. In the example above where the schema is a root object, the name is the value of the name property. When the schema is placed into a namespace () or embedded into a properties () section of an object type, the name is the key under which the schema is stored. Further rules for schemas are defined in . A "schema document" is a schema that represents the root of a schema hierarchy and is the container format in which schemas are stored on disk or exchanged. A schema document MAY contain multiple type declarations and namespaces. The structure of schema documents is defined in . JSON Structure is extensible. All keywords that are not explicitly defined in this document MAY be used for custom annotations and extensions. This also applies to keywords that begin with the $ character. A complete list of reserved keywords is provided in . The semantics of keywords defined in this document MAY be expanded by extension specifications, but the core semantics of the keywords defined in this document MUST NOT be altered. Be mindful that the use of custom keywords and annotations might conflict with future versions of this specification or other extensions and that the authors of this specification will not go out of their way to avoid such conflicts. details the extensibility features. Formally, a schema is a constrained non-schema () that requires a type () keyword or a $ref () keyword to be a schema.

Non-Schema Non-schemas are objects that do not declare or refer to a type. The root of a schema document () is a non-schema unless it contains a type keyword. A namespace is a non-schema that contains type declarations and other namespaces.

Meta-Schemas A meta-schema is a schema document that defines the structure and constraints of another schema document. Meta-schemas are used to validate schema documents and to ensure that schemas are well-formed and conform to the JSON Structure specification. The meta-schemas for JSON Structure and the extension specifications are enumerated in the Appendix: Metaschemas (). Meta-schemas can extend existing meta-schemas by adding new keywords or constraints. The $schema keyword is used to reference the meta-schema that a schema document conforms to, the $id keyword is used to define the identifier of the new meta-schema, and the $import keyword defined in the extension specification is used to import all definitions from the foundational meta-schema.

Data Types The data types that can be used with the type keyword are categorized into JSON primitive types, extended types, compound types, and reusable types . While JSON Structure builds on the JSON data type model, it introduces a rich set of types to represent structured data more accurately and to allow more precise integration with common data types used in programming languages and data formats. All these extended types have a well-defined representation in JSON primitive types.

JSON Primitive Types These types map directly to the underlying JSON representation:

string A sequence of Unicode characters enclosed in double quotes.

Base type: string
Annotations: The maxLength keyword can be used on a schema with the string type to specify the maximum length of the string. By default, the maximum length is unlimited. The purpose of the keyword is to inform consumers of the maximum space required to store the string.

number A numeric literal without quotes.

Base type: number

Note that the number representation in JSON is a textual representation of a decimal number (base-10) and therefore cannot accurately represent all possible values of IEE754 floating-point numbers (base-2), in spite of JSON number leaning on the IEEE754 standard as a reference for the value space.

integer An alias for int32 (), provided for compatibility with JSON Schema.

Base type: number
Constraints:
- The numeric literal MUST be in the range -2³¹ to 2³¹–1.
- No decimal points or quotes are allowed.

boolean A literal true or false (without quotes).

Base type: boolean

null A literal null (without quotes).

Base type: null

Extended Primitive Types Extended types impose additional semantic constraints on the underlying JSON types. These types are used to represent binary data, high-precision numeric values, date and time information, and structured data. Large integer and decimal types are used to represent high-precision numeric values that exceed the range of IEEE 754 double-precision format, which is the foundation for the number type in JSON. Per , interoperable JSON numbers have a range of -2⁵³ to 2⁵³–1, which is less than the range of 64-bit and 128-bit values. Therefore, the int64, uint64, int128, uint128, and decimal types are represented as strings to preserve precision. The syntax for strings representing large integer and decimal types is based on the syntax for integers and decimals:

integer = [minus] int
decimal = [minus] int frac

binary A binary value. The default encoding is Base64 . The type annotation keywords contentEncoding, contentCompression, and contentMediaType can be used to specify the encoding, compression, and media type of the binary data.

Base type: string
Constraints:
- The string value MUST be an encoded binary value, with the encoding specified in the contentEncoding keyword.

int8 An 8-bit signed integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range -2⁷ to 2⁷–1.
- No decimal points or quotes are allowed.

uint8 An 8-bit unsigned integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range 0 to 2⁸–1.
- No decimal points or quotes are allowed.

int16 A 16-bit signed integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range -2¹⁵ to 2¹⁵–1.
- No decimal points or quotes are allowed.

uint16 A 16-bit unsigned integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range 0 to 2¹⁶–1.
- No decimal points or quotes are allowed.

int32 A 32-bit signed integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range -2³¹ to 2³¹–1.
- No decimal points or quotes are allowed.

uint32 A 32-bit unsigned integer.

Base type: number
Constraints:
- The numeric literal MUST be in the range 0 to 2³²–1.
- No decimal points or quotes are allowed.

int64 A 64-bit signed integer.

Base type: string
Constraints:
- The string MUST conform to the definition for the [minus] int syntax.
- The string value MUST represent a 64-bit integer in the range -2⁶³ to 2⁶³–1.

uint64 A 64-bit unsigned integer.

Base type: string
Constraints:
- The string MUST conform to the definition for the int syntax.
- The string value MUST represent a 64-bit integer in the range 0 to 2⁶⁴–1.

int128 A 128-bit signed integer.

Base type: string
Constraints:
- The string MUST conform to the definition for the [minus] int syntax.
- The string value MUST represent a 128-bit integer in the range -2¹²⁷ to 2¹²⁷–1.

uint128 A 128-bit unsigned integer.

Base type: string
Constraints:
- The string MUST conform to the definition for the int syntax.
- The string value MUST represent a 128-bit integer in the range 0 to 2¹²⁸–1.

float8 An 8-bit floating-point number.

Base type: number
Constraints:
- Conforms to IEEE 754 single-precision value range limits (8 bits), which are 3 bits of significand and 4 bits of exponent, with a range of approximately ±3.4×10³.

float A single-precision floating-point number.

Base type: number
Constraints:
- Conforms to IEEE 754 single-precision value range limits (32 bits), which are 24 bits of significand and 8 bits of exponent, with a range of approximately ±3.4×10³⁸.

IEEE754 binary32 are base-2 encoded and therefore cannot represent all decimal numbers accurately, and vice versa. In cases where you need to encode IEEE754 values precisely, store the IEE754 binary32 value as an int32 or uint32 number.

double A double-precision floating-point number.

Base type: number
Constraints:
- Conforms to IEEE 754 double-precision value range limits (64 bits), which are 53 bits of significand and 11 bits of exponent, with a range of approximately ±1.7×10³⁰⁸.

IEEE754 binary64 are base-2 encoded and therefore cannot represent all decimal numbers accurately, and vice versa. In cases where you need to encode IEEE754 values precisely, store the IEE754 binary64 value as an int64 or uint64 number.

decimal A decimal number supporting high-precision values.

Base type: string
Constraints:
- The string value MUST conform to the definition for the [minus] int frac syntax.
- Defaults: 34 significant digits and 7 fractional digits, which is the maximum precision supported by the IEEE 754 decimal128 format.
Annotations:
- The precision keyword MAY be used to specify the total number of significant digits.
- The scale keyword MAY be used to specify the number of fractional digits.

date A date in YYYY-MM-DD form.

Base type: string
Constraints:
- The string value MUST conform to the full-date format.

datetime A date and time value with time zone offset.

Base type: string
Constraints:
- The string value MUST conform to the date-time format.

time A time-of-day value.

Base type: string
Constraints:
- The string value MUST conform to the time format.

duration A time duration.

Base type: string
Constraints:
- The string value MUST conform to the duration format.

uuid A universally unique identifier.

Base type: string
Constraints:
- The string value MUST conform to the UUID format.

uri A URI reference, relative or absolute.

Base type: string
Constraints:
- The string value MUST conform to the uri-reference format.

jsonpointer A JSON Pointer reference.

Base type: string
Constraints:
- The string value MUST conform to the JSON Pointer format.

Compound Types Compound types are used to structure related data elements. JSON Structure supports the following compound types:

object The object type is used to define structured data with named properties. It's represented as a JSON object, which is an unordered collection of key–value pairs. The object type MUST include a name attribute that defines the name of the type. The object type MUST include a properties attribute that defines the properties of the object. The properties attribute MUST be a JSON object where each key is a property name and each value is a schema definition for the property. The object MUST contain at least one property definition. The object type MAY include a required attribute that defines the required properties of the object. The object type MAY include an additionalProperties attribute that defines whether additional properties are allowed and/or what their schema is. Example:

array An array type is used to define an ordered collection of elements. It's represented as a JSON array, which is an ordered list of values. The items attribute of an array MUST reference a reusable type or a primitive type or a locally declared compound type. Examples:

set The set type is used to define an unordered collection of unique elements. It's represented as a JSON array where all elements are unique. The items attribute of a set MUST reference a reusable type or a primitive type or a locally declared compound type. Example:

map The map type is used to define dynamic key–value pairs. It's represented as a JSON object where the keys are strings and the values are of a specific type. Map keys MAY be any valid JSON string. The values attribute of a map MUST reference a reusable type or a primitive type or a locally declared compound type. Example:

tuple The tuple type is used to define an ordered collection of elements with a specific length. It's represented as a JSON array where each element is of a specific type. The elements are defined using a properties map as with the object () type and each element is named. This permits straightforward mapping into application constructs. All declared properties of a tuple are implicitly REQUIRED. The order of the elements in a tuple is declared using the tuple keyword , which is REQUIRED. The tuple keyword MUST be a JSON array of strings, where each declared property name MUST be an element of the array. The order of the elements in the array defines the order of the properties in the tuple. A tuple type MUST include a name attribute that defines the name of the type. Example: The following JSON node is an valid instance of the tuple type defined above:

any The any type is used to define a type that can be any JSON value, including primitive types, compound types, and extended types. Example:

choice The choice type is used to define a "discriminated union" of types. A choice is a set of types where only one type can be selected at a time and where the selected type is determined by the value of a selector. The choice type can declare two variants of discriminated unions that are represented differently in JSON:

Tagged unions: The choice type is represented as a JSON object with a single property whose name is the selector of the type as declared in the choices () map and whose value is of the selected type.
Inline unions: The choice type is represented as a JSON object of the selected type with the selector as a property of the object.

Tagged Unions A tagged union is declared as follows: The JSON node described by the schema above is a tagged union. For the example, the following JSON node is a valid instance of the MyChoice type: or:

Inline Unions Inline unions require for all type choices to extend a common base type. This is expressed by using the $extends () keyword in the choice declaration. The $extends keyword MUST refer to a schema that defines the base type and the base type MUST be abstract. If $extends is present, the selector property declares the name of the injected property that acts as the selector for the inline union. The type of the selector property is string. The selector property MAY shadow a property of the base type; in this case, the base type property MUST be of type string. The selector is defined as a property of the base type and the value of the selector property MUST be a string that matches the name of one of the options in the choices map. Example: The JSON node described by the schema above is an inline union. This example shows a JSON node that is a street address: This example shows a JSON node that is a post office box address:

Document Structure A JSON Structure document is a JSON object that contains schemas () The root of a JSON Structure document MUST be a JSON object. The root object MUST contain the following REQUIRED keywords:

$id: A URI that is the unique identifier for this schema document.
$schema: A URI that identifies the version and meta-schema of the JSON Structure specification used.
name: A string that provides a name for the document. If the root object defines a type, the name attribute is also the name of the type.

The presence of both keywords identifies the document as a JSON Structure document. The root object MAY contain the following OPTIONAL keywords:

$root: A JSON Pointer that designates a reusable type as the root type for instances.
definitions: The root of the type declaration namespace hierarchy.
type: A type declaration for the root type of the document. Mutually exclusive with $root.
if type is present, all annotations and constraints applicable to this declared root type are also permitted at the root level.

Namespaces A namespace is a JSON object that provides a scope for type declarations or other namespaces. Namespaces MAY be nested within other namespaces. The definitions keyword forms the root of the namespace hierarchy for reusable type definitions. All type declarations immediately under the definitions keyword are in the root namespace. A type definition at the root is placed into the root namespace as if it were a type declaration under definitions. Any object in the definitions map that is not a type declaration is a namespace. Example with inline type: Example with $root: Example with the root type in a namespace:

$schema Keyword The value of the REQUIRED $schema keyword MUST be an absolute URI. The keyword has different functions in JSON Structure documents and JSON documents.

In JSON Structure schema documents, the $schema keyword references a meta-schema that this document conforms to.
In JSON documents, the $schema keyword references a JSON Structure schema document that defines the structure of the JSON document.

The value of $schema MUST correspond to the $id of the referenced meta-schema or schema document. The $schema keyword MUST be used at the root level of the document. Example: Use of the keyword $schema does NOT import the referenced schema document such that its types become available for use in the current document.

$id Keyword The REQUIRED $id keyword is used to assign a unique identifier to a JSON Structure schema document. The value of $id MUST be an absolute URI. It SHOULD be a resolvable URI (a URL). The $id keyword is used to identify a schema document in references like $schema. The $id keyword MUST only be used once in a document, at the root level. Example:

$root Keyword The OPTIONAL $root keyword is used to designate any reusable type defined in the document as the root type of this schema document. The value of $root MUST be a valid JSON Pointer that resolves to an existing type definition inside the definitions object. The $root keyword MUST only be used once in a document, at the root level. Its use is mutually exclusive with the type keyword. Example:

definitions Keyword The definitions keyword defines a namespace hierarchy for reusable type declarations. The keyword MUST be used at the root level of the document. The value of the definitions keyword MUST be a map of types and namespaces. The namespace at the root level of the definitions keyword is the root namespace. A namespace is a JSON object that provides a scope for type declarations or other namespaces. Any JSON object under the definitions keyword that is not a type definition (containing the type attribute) is considered a namespace. Example:

$ref Keyword References to type declarations within the same document MUST use a schema containing a single property with the name $ref as the value of type. The value of $ref MUST be a valid JSON Pointer Fragment Identifier (see ) that resolves to an existing type definition. Example: The $ref keyword is only permitted inside the type attribute value of a schema definition, including in type unions. $ref is NOT permitted in other attributes and MUST NOT be used inside the type of the root object.

Cross-references In JSON Structure documents, the $schema keyword references the meta-schema of this specification. In JSON documents, the $schema keyword references the schema document that defines the structure of the JSON document. The value of $schema is a URI. Ideally, the URI SHOULD be a resolvable URL to a schema document, but it's primarily an identifier. As an identifier, it can be used as a lookup key in a cache or schema-registry. The OPTIONAL extension specification is the exception and provides a mechanism for importing definitions from external schemas.

Type System Rules

Schema Declarations

Every schema element MUST declare a type referring to a primitive, compound, or reusable type.
To reference a reusable type, the type attribute MUST be a schema with a single $ref property resolving to an existing type declaration.
Compound types SHOULD be declared in the definitions section as reusable types. Inline compound types in arrays, maps, unions, or property definitions MUST NOT be referenced externally.
Primitive and compound type declarations are confined to this specification.
Defined types:
- JSON Primitives: string, number, integer, boolean, null.
- Extended Primitives: int32, uint32, int64, uint64, int128, uint128, float, double, decimal, date, datetime, time, duration, uuid, uri, binary, jsonpointer.
- JSON Compounds: object, array.
- Extended Compounds: map, set, tuple, any, choice.

Reusable Types

Reusable types MUST be defined in the definitions section.
Each declaration in definitions MUST have a unique, case-sensitive name within its namespace. The same name MAY appear in different namespaces.

Type References

Use $ref to reference types declared in the same document.
$ref MUST be a valid JSON Pointer to an existing type declaration.
$ref MAY include a description attribute for additional context.

Dynamic Structures

Use the map type for dynamic key–value pairs. The object type requires at least one property and cannot model fully dynamic properties with additionalProperties.
The values attribute of a map and the items attribute of an array or set MUST reference a reusable type, a primitive type, or a locally declared compound type.

Composition Rules This section defines the rules for composing schemas. Further, OPTIONAL composition rules are defined in the extension specification.

Unions

Non-discriminated type unions are formed as sets of primitive types and type references. It is NOT permitted to define a compound type inline inside a non-discriminated type union. Discriminated unions are formed as a choice () type to which the rules of this section do not apply.
A type union is a composite type reference and not a standalone compound type and is therefore not named.
The JSON node described by a schema with a type union MUST conform to at least one of the types in the union.
If the JSON node described by a schema with a type union conforms to more than one type in the union, the JSON node MUST be considered to be of the first matching type in the union.

Examples: Union of a string and a compound type: Union of a string and an int32: A valid union of a string and a map of strings: An inline definition of a compound type in a union is NOT permitted:

Prohibition of Top-Level Unions

The root of a JSON Structure document MUST NOT be an array.
If a type union is desired as the type of the root of a document instance, the $root keyword MUST be used to designate a type union as the root type.

Identifier Rules All property names and type names MUST conform to the regular expression [A-Za-z_][A-Za-z0-9_]*. They MUST begin with a letter or underscore and MAY contain letters, digits, and underscores. Keys and type names are case-sensitive. If names need to contain characters outside of this range, consider using the extension specification to define those.

Structural Keywords

The type Keyword Declares the type of a schema element as a primitive or compound type. The type keyword MUST be present in every schema element. For unions, the value of type MUST be an array of type references or primitive type names. Example:

The properties Keyword properties defines the properties of an object type. The properties keyword MUST contain a map of property names mapped to schema definitions. Example:

The required Keyword required defines the required properties of an object type. The required keyword MUST only be used in schemas of type object. The value of the required keyword is a simple array of property names or an array of arrays of property names. An array of arrays is used to define alternative sets of required properties. When alternative sets are used, exactly one of the sets MUST match the properties of the object, meaning they are mutually exclusive. Property names in the required array MUST be present in properties. Example: Example with alternative sets: Because the name property is required in both sets, the name property is required in all objects. The fins property is required in the first set, and the legs property is required in the second set. That means that an object MUST have either fins or legs but not both.

The items Keyword Defines the schema for elements in an array or set type. The value is a type reference or a primitive type name or a locally declared compound type. Examples:

The values Keyword Defines the schema for values in a map type. The values keyword MUST reference a reusable type or a primitive type or a locally declared compound type. Example:

The const Keyword Constrains the values of the JSON node described by the schema to a single, specific value. The const keyword MUST appear only in schemas with a primitive type, and the instance value MUST match the provided constant exactly. Example:

The enum Keyword Constrains a schema to match one of a specific set of values. The enum keyword MUST appear only in schemas with a primitive type, and all values in the enum array MUST match that type. Values MUST be unique. Example: It is NOT permitted to use enum in conjunction with a type union in type.

The additionalProperties Keyword additionalProperties defines whether additional properties are allowed in an object type and, optionally, what their schema is. The value MUST be a boolean or a schema. If set to false, no additional properties are allowed. If provided with a schema, each additional property MUST conform to it. Example:

The choices Keyword choices defines the choices of a choice type. The value MUST be a map of type names to schemas. Each type name MUST be unique within the choices map. The value of each type name MUST be a schema. Inline compound types are permitted. The choices keyword MUST only be used in schemas of type choice (). *Example:

The selector Keyword The selector keyword defines the name of the property that acts as the selector for the type in a choice type. The value of selector MUST be a string. The selector keyword MUST only be used in schemas of type choice (). See choice () for an example.

The tuple Keyword The tuple keyword defines the order of properties in a tuple type. The value of tuple MUST be an array of strings, where each string is the name of a property defined in the properties map. The order of the strings in the array defines the order of the properties in the tuple. The tuple keyword MUST only be used in schemas of type tuple (). See tuple () for an example.

Type Annotation Keywords Type annotation keywords provide additional metadata about the underlying type. These keywords are used for documentation and validation of additional constraints on types.

The maxLength Keyword Specifies the maximum allowed length for a string. The maxLength keyword MUST be used only with string types, and the string’s length MUST not exceed this value. The purpose of maxLength is to provide a known storage constraint on the maximum length of a string. The value MAY be used for validation. Example:

The precision Keyword Specifies the total number of significant digits for numeric values. The precision keyword is used as an annotation for number or decimal types. Example:

The scale Keyword Specifies the number of digits to the right of the decimal point for numeric values. The scale keyword is used as an annotation for number or decimal types to constrain the fractional part. Example:

The contentEncoding Keyword Specifies the encoding of a binary value. The contentEncoding keyword is used as an annotation for binary types. The permitted values for contentEncoding are defined in :

base64: The binary value is encoded as a base64 string.
base64url: The binary value is encoded as a base64url string.
base16: The binary value is encoded as a base16 string.
base32: The binary value is encoded as a base32 string.
base32hex: The binary value is encoded as a base32hex string.

Example:

The contentCompression Keyword Specifies the compression algorithm used for a binary value before encoding. The contentCompression keyword is used as an annotation for binary types. The permitted values for contentCompression are:

gzip: The binary value is compressed using the gzip algorithm. See .
deflate: The binary value is compressed using the deflate algorithm. See .
zlib: The binary value is compressed using the zlib algorithm. See .
brotli: The binary value is compressed using the brotli algorithm. See .

Example:

The contentMediaType Keyword Specifies the media type of a binary value. The contentMediaType keyword is used as an annotation for binary types. The value of contentMediaType MUST be a valid media type as defined in . Example:

Documentation Keywords Documentation keywords provide descriptive information for schema elements. They are OPTIONAL but RECOMMENDED for clarity.

The description Keyword Provides a human-readable description of a schema element. The description keyword SHOULD be used to document any schema element. Example: For multi-lingual descriptions, the companion provides an extension to define several concurrent descriptions in multiple languages.

The examples Keyword Provides example instance values that conform to the schema. The examples keyword SHOULD be used to document potential instance values. Example:

Extensions and Add-Ins The abstract and $extends keywords enable controlled type extension, supporting basic object-oriented-programming-style inheritance while not permitting subtype polymorphism where a sub-type value can be assigned a base-typed property. This approach avoids validation complexities and mapping issues between JSON schemas, programming types, and databases. An extensible type is declared as abstract and serves as a base for extensions. For example, a base type Address MAY be extended by StreetAddress and PostOfficeBoxAddress via $extends, but Address cannot be used directly. Example: A add-in type is declared as abstract and $extends a specific type that does not need to be abstract. For example, an add-in type DeliveryInstructions might be applied to any StreetAddress types in a document: Add-in types are options that a document author can enable for a schema. The definitions of add-in types are not part of the main schema by default, but are injected into the designated schema type when the document author chooses to use them. Add-in types are advertised in the schema document through the $offers keyword, which is a map that defines add-in names for add-in schema definitions that exist in the document. Add-ins are applied to a schema by referencing the add-in name in the $uses keyword that is available only in instance documents. The $uses keyword is a set of add-in names that are applied to the schema for the document.

The abstract Keyword The abstract keyword declares a type as abstract. This prohibits its direct use in any type declaration or as the type of a schema element. Abstract types are used as base types for extension via $extends or as add-in types via $addins. Abstract types implicitly permit additional properties (additionalProperties is always true).

Value: A boolean (true or false).
Rules:
- The abstract keyword MUST only be used in schemas of type object and tuple.
- Abstract types MUST NOT be used as the type of a schema element or referenced via $ref.
- The additionalProperties keyword MUST NOT be used on abstract types (its value is implicitly true).
- Abstract types MAY extend other abstract types via $extends.

The $extends Keyword The $extends keyword merges all properties from one or more abstract base types into the extending type. If the type using $extends is marked as abstract and referenced via $addins, the composite type replaces the base type in the type model of the document.

Value: A JSON Pointer to an abstract type, or an array of JSON Pointers to abstract types.
Rules:
- The $extends keyword MUST only be used in schemas of type object and tuple.
- The value of $extends MUST be a valid JSON Pointer or an array of valid JSON Pointers that point to abstract types within the same document.
- The extending type MUST merge the abstract type's properties and constraints and MUST NOT redefine any inherited property.
- When multiple base types are specified, properties are merged in array order. If multiple base types define a property with the same name, the property from the first base type in the array takes precedence.

The $offers Keyword The $offers keyword is used to advertise add-in types that are available for use in a schema document. The $offers keyword is a map of add-in names to add-in schema definitions.

Value: A map of add-in names to add-in schema definitions.
Rules:
- The $offers keyword MUST only be used in the root object of a schema document.
- The value of $offers MUST be a map where each key is a string and each value is a JSON Pointer to an add-in schema definition in the same document or a set of JSON Pointers to add-in schema definitions in the same document. If the value is a set, the add-in name selects all add-in schema definitions at the same time.
- The keys in the $offers map MUST be unique.

The $uses Keyword The $uses keyword is used to apply add-in types to a schema in an instance document that references the schema. The keyword MAY be used in a meta-schema that references a parent schema.

Value: A set of add-in names or JSON Pointers to add-in schema definitions in the same meta-schema document.
Rules:
- The $uses keyword MUST only be used in instance documents.
- The value of $uses MUST be a set of strings that are either:
  - add-in names advertised in the $offers keyword of the schema document referenced by the $schema keyword of the instance document or
  - JSON Pointers to add-in schema definitions in the same meta-schema document.