Array Properties

Array properties hold an array of one or more objects, which are usually description objects.

For example, the tables property is an array property. A table group description might contain:

"tables": [{
  "url": "https://example.org/countries.csv",
  "tableSchema": "https://example.org/countries.json"
}, {
  "url": "https://example.org/country_slice.csv",
  "tableSchema": "https://example.org/country_slice.json"
}]
          

in which case the tables property has a value that is an array of two table description objects.

Any items within an array that are not valid objects of the type expected are ignored. If the supplied value of an array property is not an array (e.g. if it is an integer), compliant applications MUST issue a warning and proceed as if the property had been supplied with an empty array.

Link Properties

Link properties hold a single reference to another resource by URL. Their value is a string — resolved as a URL against the base URL. If the supplied value of a link property is not a string (e.g. if it is an integer), compliant applications MUST issue a warning and proceed as if the property had been supplied with an empty string.

For example, the url property is a link property. A table description might contain:

"url": "example-2014-01-03.csv"
          

in which case the url property on the table would have a single value, a link to example-2014-01-03.csv, resolved against the base URL of the metadata document in which this was located. For example if the metadata document contained:

"@context": [ "http://www.w3.org/ns/csvw", { "@base": "http://example.org/" }]
          

this is equivalent to specifying:

"url": "http://example.org/example-2014-01-03.csv"
          

URI Template Properties

URI template properties contain a [[!URI-TEMPLATE]] which can be used to generate a URI. These URI templates are expanded in the context of each row by combining the template with a set of variables with values as defined in [[!URI-TEMPLATE]]. The following variables are set:

column names

a variable is set for each column within the schema; the name of the variable is the column name of the column from the annotated table and the value is derived from the value of the cell in that column in the row that is currently being processed, namely one of:

• null,
• the canonical representation of the value of the cell, based on its datatype as defined in [[!xmlschema11-2]], if it has a single value, or
• a list of canonical representations of the values of the cell, if it has a sequence value.

The languages of cell values are ignored.

_column

_column is set to the column number of the column from the annotated table that is currently being processed.

_sourceColumn

_sourceColumn is set to the source number of the column that is currently being processed; this usually varies from _column by skip columns.

_row

_row is set to the row number of the row from the annotated table that is currently being processed.

_sourceRow

_sourceRow is set to the source number of the row that is currently being processed; this usually varies from _row by skip rows and header rows.

_name

_name is set to the URI decoded column name annotation, as defined in [[!tabular-data-model]], for the column that is currently being processed. (Percent-decoding is necessary as name may have been encoded if taken from titles; this prevents double percent-encoding.)

The annotation value is the result of:

1. applying the template against the cell in that column in the row that is currently being processed.
2. expanding any prefixes as if the value were the name of a common property, as described in .
3. resolving the resulting URL against the base URL of the table url if not null.

If the supplied value of a URI template property is not a string (e.g. if it is an integer), compliant applications MUST issue a warning and proceed as if the property had been supplied with an empty string.

For example, the aboutUrl property holds a URI template that is used to generate a URL identifier for each row, which might look like:

"aboutUrl": "http://example.org/example.csv#row.{_row}"
          

The about URL annotations that are generated and used as identifiers for the rows would then look like http://example.org/example.csv#row.1, http://example.org/example.csv#row.2 and so on.

Alternatively, with the CSV and metadata in the , the aboutUrl might look like:

"aboutUrl": "http://example.org/tree/{on_street}/{GID}"
          

This would generate URIs such as http://example.org/tree/ADDISON%20AV/1 and http://example.org/tree/EMERSON%20ST/2.

If the value of the on_street or GID column were null, the URL would still be generated with the null value generating an empty string in the URL. For example if on_street were null and GID were 3, the generated URL would be http://example.org/tree//3.

Once the URI has been generated, it is resolved against the url of the table (e.g. the CSV file) to create an absolute URI. For example, given a aboutUrl within a schema such as:

"aboutUrl": "#row.{_row}"
          

and given a CSV file at http://example.com/temp.csv, the URL for the first row will be http://example.com/temp.csv#row.1.

The propertyUrl property might be defined as "{#_name}", meaning that it resolves as a fragment identifier relative to the URL of the source of the table. For example, accessing it from a column with the column name GID would look like:

"http://example.org/example.csv#GID"
          

A value defined within the data is also subject to expansion. For example, consider the following table:

project_name,project_type,keywords
CSVW,foaf:Project,table;data;conversion
          

The project_type column might have a valueUrl specified as "{project_type}". In the first row the cell value is "foaf:Project". The foaf prefix is understood, as described in , to expand to http://xmlns.com/foaf/0.1/Project.

Similarly, the keywords column might have a valueUrl specified as "https://duckduckgo.com/?q={keywords}". If the column also specifies "separator": ";", then the cell value of the keywords column would be an array of the three values table, data, and conversion. This is set as the value of the keywords variable within the URI template, which means the result would be https://duckduckgo.com/?q=table,data,conversion.

If the value in the keywords column were an empty sequence (created from an empty cell in the original data), the reference to that column would be expanded to an empty string, generating https://duckduckgo.com/?q=.

When a cell's value is not a string, the canonical representation of that value is used within the expanded URL. For example, the data may include dates such as those in:

The Inventory Date column description would indicate that these were dates with the format M/d/yyyy:

{
  "name": "inventory_date",
  "titles": "Inventory Date",
  "datatype": {
    "base": "date",
    "format": "M/d/yyyy"
  }
}
          

The string value of the inventory_date column in the first row is parsed to create the date 18th October 2010. When the inventory_date column is referenced within a URI template such as http://example.org/event/{inventory_date}, the canonical representation of that date, as defined in [[!xmlschema11-2]] is used within the URL, giving the result http://example.org/event/2010-10-18.

Column Reference Properties

Column reference properties hold one or more references to other column description objects. The referenced description object must have a name property. Column reference properties can then reference column description objects through values that are:

• strings — which MUST match the name on a column description object within the metadata document.
• arrays — lists of strings as above.

Compliant applications MUST issue a warning and proceed as if the column reference property had not been specified if:

• the supplied value is not a string or array (e.g. if it is an integer).
• the supplied value is an empty array.
• any of the values in the supplied array are not strings.
• any of the supplied strings do not reference one or more columns.

For example, the primaryKey property is a column reference property on the schema. It has to hold references to columns defined elsewhere in the schema, and the descriptions of those columns must have name properties. It can hold a single reference, like this:

"tableSchema": {
  "columns": [{
    "name": "GID"
  }, ... ],
  "primaryKey": "GID"
}
          

or it can contain an array of references, like this:

"tableSchema": {
  "columns": [{
    "name": "givenName"
  }, {
    "name": "familyName"
  }, ... ],
  "primaryKey": [ "givenName", "familyName" ]
}
          

If the primaryKey property were given an invalid value, such as 1, or a column name were misspelled, the processor MUST issue a warning and ignore the value.

On the other hand, the columnReference property is a required property; if it has an invalid value, such as an empty array, then the processor will issue an error as if the property were not specified at all.

Object Properties

Object properties hold either a single object or a reference to an object by URL. Their values may be:

• strings — resolved as URLs against the base URL.
• objects — interpreted as structured objects.

If the supplied value of an object property is not a string or object (e.g. if it is an integer), compliant applications MUST issue a warning and proceed as if the property had been specified as an object with no properties.

Object properties are often used when the values can be or should be values within controlled vocabularies, or structured information which may be held elsewhere. For example, the dialect of a table is an object property. It could be provided as a URL that indicates a commonly used dialect, like this:

"dialect": "http://example.org/tab-separated-values"
          

or a structured object, like this:

"dialect": {
  "delimiter": "\t",
  "encoding": "utf-8"
}
          

When specified as a string, the resolved URL is used to fetch the referenced object during normalization as described in . For example, if http://example.org/tab-separated-values resolved to:

{
  "@context": "http://www.w3.org/ns/csvw",
  "quoteChar": null,
  "header": true,
  "delimiter": "\t"
}
          

Following normalization, the value of the dialect property would then be:

"dialect": {
  "@id": "http://example.org/tab-separated-values",
  "quoteChar": null,
  "header": true,
  "delimiter": "\t"
}
          

Natural Language Properties

Natural language properties hold natural language strings. Their values may be:

• strings — interpreted as natural language strings in the default language.
• arrays — interpreted as alternative natural language strings in the default language.
• objects whose properties MUST be language codes as defined by [[!BCP47]] and whose values are either strings or arrays, providing natural language strings in that language.

Natural language properties are used for titles. For example, the titles property on a column description provides a natural language label for a column. If it's a plain string like this:

"titles": "Project title"
          

then that string is assumed to be in the default language (or have an undefined language, und, if there is no such property). Multiple alternative values can be given in an array:

"titles": [
  "Project title",
  "Project"
]
          

It's also possible to provide multiple values in different languages, using an object structure. For example:

"titles": {
  "en": "Project title",
  "fr": "Titre du projet"
}
          

and within such an object, the values of the properties can themselves be arrays:

"titles": {
  "en": [ "Project title", "Project" ],
  "fr": "Titre du projet"
}
          

The annotation value of a natural language property is an object whose properties are language codes and where the values of those properties are an array of strings (see Language Maps in [[!JSON-LD]]).

When extracting a annotation value from a metadata that will have already been normalized, a natural language property will already have this form.

If the supplied value of a natural language property is not a string, array or object (e.g. if it is an integer), compliant applications MUST issue a warning and proceed as if the property had been specified as an empty array. If the supplied value is an array, any items in that array that are not strings MUST be ignored. If the supplied value is an object, any properties that are not valid language codes as defined by [[!BCP47]] MUST be ignored, as must any properties whose value is not a string or an array, and any items that are not strings within array values of these properties.

Atomic Properties

Atomic properties hold atomic values. Their values may be:

• numbers — interpreted as integers or doubles.
• booleans — interpreted as booleans (true or false).
• strings — interpreted as defined by the property.
• objects — interpreted as defined by the property.
• arrays — lists of numbers, booleans, strings, or objects.

The annotation value of a boolean atomic property is false if unset; otherwise, the annotation value of an atomic property is normalized value of that property, or the defined default value or null, if unset. Processors MUST issue a warning if a property is set to an invalid value type, such as a boolean atomic property being set to the number 1 or a numeric atomic property being set to the string "3.1415", and act as if the property had not been specified (which may mean using the default value for the property, or may mean raising an error and halting processing if the property is a required property).

Required Properties

tables

An array property of table descriptions for the tables in the group, namely those listed in the tables annotation on the group of tables being described. Compliant application MUST raise an error if this array does not contain one or more table descriptions.

Optional Properties

The description of a group of tables MAY also contain:

dialect

An object property that provides a single dialect description. If provided, dialect provides hints to processors about how to parse the referenced files to create tabular data models for the tables in the group. This may be provided as an embedded object or as a URL reference. See for more details.

notes

An array property that provides an array of objects representing arbitrary annotations on the annotated group of tables. The value of this property becomes the value of the notes annotation for the group of tables. The properties on these objects are interpreted equivalently to common properties as described in .

The Web Annotation Working Group is developing a vocabulary for expressing annotations. In future versions of this specification, we anticipate referencing that vocabulary.

tableDirection

An atomic property that MUST have a single string value that is one of "rtl", "ltr", or "auto". Indicates whether the tables in the group should be displayed with the first column on the right, on the left, or based on the first character in the table that has a specific direction. The value of this property becomes the value of the table direction annotation for all the tables in the table group. See Bidirectional Tables in [[!tabular-data-model]] for details. The default value for this property is "auto".

tableSchema

An object property that provides a single schema description as described in , used as the default for all the tables in the group. This may be provided as an embedded object within the JSON metadata or as a URL reference to a separate JSON object that is a schema description.

transformations

An array property of transformation definitions that provide mechanisms to transform the tabular data into other formats. The value of this property becomes the value of the transformations annotation for all the tables in the table group.

@id

If included, @id is a link property that identifies the group of tables, as defined by [[!tabular-data-model]], described by this table group description. It MUST NOT start with _:. The value of this property becomes the value of the id annotation for the group of tables.

@type

If included, @type is an atomic property that MUST be set to "TableGroup". Publishers MAY include this to provide additional information to JSON-LD based toolchains.

The description MAY contain any common properties to provide extra metadata about the group of tables as a whole.

The description MAY contain inherited properties to describe cells within the tables.

Table Group Description Compatibility

Two table group descriptions are compatible if any table descriptions they contain with matching normalized url properties are themselves compatible as defined in .

Required Properties

url

This link property gives the single URL of the CSV file that the table is held in, relative to the location of the metadata document. The value of this property is the value of the url annotation for the annotated table this table description describes.

Optional Properties

The description of a table MAY also contain:

dialect

As defined for table groups.

notes

An array property that provides an array of objects representing arbitrary annotations on the annotated tabular data model. The value of this property becomes the value of the notes annotation for the table. The properties on these objects are interpreted equivalently to common properties as described in .

The Web Annotation Working Group is developing a vocabulary for expressing annotations. In future versions of this specification, we anticipate referencing that vocabulary.

suppressOutput

A boolean atomic property. If true, suppresses any output that would be generated when converting this table. The value of this property becomes the value of the suppress output annotation for this table. The default is false.

tableDirection

As defined for table groups. The value of this property becomes the value of the table direction annotation for this table.

tableSchema

An object property that provides a single schema description as described in . This may be provided as an embedded object within the JSON metadata or as a URL reference to a separate JSON schema document. If a table description is within a table group description, the tableSchema from that table group acts as the default for this property.

If a tableSchema is not declared in table description, it may be declared on the table group description, which is then used as the schema for this table description.

The @id property of the tableSchema, if there is one, becomes the value of the schema annotation for this table.

When a schema is referenced by URL, this URL becomes the value of the @id property in the normalized schema description, and thus the value of the schema annotation on the table.

transformations

As defined for table groups. The value of this property becomes the value of the transformations annotation for this table.

@id

If included, @id is a link property that identifies the table, as defined in [[!tabular-data-model]], described by this table description. It MUST NOT start with _:. The value of this property becomes the value of the id annotation for this table.

@type

If included, @type is an atomic property that MUST be set to "Table". Publishers MAY include this to provide additional information to JSON-LD based toolchains.

The description MAY contain any common properties to provide extra metadata about the table as a whole.

The description MAY contain inherited properties to describe cells within the table.

Table Description Compatibility

Two table descriptions are compatible if they have equivalent normalized url properties, and have compatible schemas as defined in .

Schema Compatibility

Two schemas are compatible if they have the same number of non-virtual column descriptions, and the non-virtual column descriptions at the same index within each are compatible with each other. Column descriptions are compatible under the following conditions:

• If either column description has neither name nor titles properties.
• If there is a case-sensitive match between the name properties of the columns.
• If there is a non-empty case-sensitive intersection between the titles values, where matches must have a matching language; und matches any language, and languages match if they are equal when truncated, as defined in [[!BCP47]], to the length of the shortest language tag.
• If not validating, and one schema has a name property but not a titles property, and the other has a titles property but not a name property.

A column description within embedded metadata where the header dialect property is false will have neither name nor titles properties.

Names of Common Properties

The names of common properties are prefixed names, in the syntax prefix:name.

Prefixed names can be expanded to provide a URI, by replacing the prefix and following colon with the URI that the prefix is associated with. Expansion is intended to be entirely consistent with Section 6.3 IRI Expansion in [[!JSON-LD-API]] and implementations MAY use a JSON-LD processor for performing prefixed name and IRI expansion.

The prefixes that are recognized are those defined for [[rdfa-core]] within the RDFa 1.1 Initial Context and other prefixes defined within [[csvw-context]] and these MUST NOT be overridden. These prefixes are periodically extended; refer to [[csvw-context]] for details. Properties from other vocabularies MUST be named using absolute URLs.

Forbidding the declaration of new prefixes ensures consistent processing between JSON-LD-aware and non-JSON-LD-aware processors.

This specification does not define how common properties are interpreted by implementations. Implementations SHOULD treat the prefixed names for common properties and the URLs that they expand into in the same way. For example, if an implementation recognises and displays the value of the dc:description property, it should also recognise and display the value of the http://purl.org/dc/terms/description property in the same way.

Values of Common Properties

Common properties can take any JSON value, so long as any objects within the value (for example as items of an array or values of properties on other objects) adhere to the following restrictions, which are designed to ensure compatibility between JSON-LD-aware and non-JSON-LD-aware processors:

• If a @value property is used on an object, that object MUST NOT have any other properties aside from either @type or @language, and MUST NOT have both @type and @language as properties. The value of the @value property MUST be a string, number, or boolean value.

  If @type is also used, its value MUST be one of:

  • a built-in datatype, as defined in .
  • a prefixed name using any of the pre-defined prefixes as described in .
  • a string, which MUST be interpreted as an absolute URL.

  If a @language property is used, it MUST have a string value that adheres to the syntax defined in [[!BCP47]], or be null.

• If a @type property is used on an object without a @value property, its value MUST be one of:

  • one of the legitimate values for @type as defined for any of the description objects in this specification.
  • a prefixed name using any of the pre-defined prefixes as described in .
  • a string, which MUST be interpreted as an absolute URL.

  A @type property can also have a value that is an array of such values.

• The values of @id properties are link properties and are treated as URLs. During normalization, as described in , they will have any prefix expanded and the result resolved against the base URL. Therefore, if an @id property is used on an object, it MUST have a value that is a string and that string MUST NOT start with _:.

• A @language property MUST NOT be used on an object unless it also has a @value property.

• Aside from @value, @type, @language, and @id, the properties used on an object MUST NOT start with @.

These restrictions are also described in , from the perspective of a processor that otherwise supports JSON-LD. Examples of common property values and the impact of normalization are given in .

Required Properties

Transformation definitions MUST have the following properties:

url

A link property giving the single URL of the file that the script or template is held in, relative to the location of the metadata document.

scriptFormat

A link property giving the single URL for the format that is used by the script or template. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/application/javascript. Otherwise, it can be any URL that describes the script or template format.

The scriptFormat URL is intended as an informative identifier for the template format, and applications SHOULD NOT access the URL. The template formats that an application supports are implementation defined.

targetFormat

A link property giving the single URL for the format that will be created through the transformation. If one has been defined, this should be a URL for a media type, in the form http://www.iana.org/assignments/media-types/media-type such as http://www.iana.org/assignments/media-types/text/calendar. Otherwise, it can be any URL that describes the target format.

The targetFormat URL is intended as an informative identifier for the target format, and applications SHOULD NOT access the URL.

Optional Properties

Transformation definitions MAY have the following properties:

source

A single string atomic property that provides, if specified, the format to which the tabular data should be transformed prior to the transformation using the script or template. If the value is json, the tabular data MUST first be transformed to JSON as defined by [[!csv2json]] using standard mode. If the value is rdf, the tabular data MUST first be transformed to an RDF graph as defined by [[!csv2rdf]] using standard mode. If the source property is missing or null (the default) then the source of the transformation is the annotated tabular data model. No other values are valid; applications MUST generate a warning and behave as if the property had not been specified.

titles

A natural language property that describes the format that will be generated from the transformation. This is useful if the target format is a generic format (such as application/json) and the transformation is creating a specific profile of that format.

@id

If included, @id is a link property that identifies the transformation described by this transformation definition. It MUST NOT start with _:.

@type

If included, @type is an atomic property that MUST be set to "Template". Publishers MAY include this to provide additional information to JSON-LD based toolchains.

The transformation definition MAY contain any common properties to provide extra metadata about the transformation.

Processing Transformation Definitions

Implementations MAY present users with options for transformations based on the available transformation definitions and their properties. Implementations SHOULD filter this list to only include those transformations whose scriptFormat they understand and can apply, and whose source property, if present, specifies a format that the implementation can convert to. Users may find the targetFormat and titles properties useful in deciding which transformation to apply.

When directed by a user to transform a table using a transformation definition, implementations MUST:

1. Convert the table to the format specified by the source property, if this is specified and not null.
2. Fetch the script or template from the location specified by the url property and raise an error if this does not exist.
3. Use the scriptFormat property to determine how to interpret that script or template, and apply it to the table (or the result of converting the table).

Built-in Datatypes

The possible built-in datatypes, as shown on the diagram, are:

• the datatypes defined in [[!xmlschema11-2]] as derived from and including anyAtomicType, whose identifier URLs are generated by prefixing the name with http://www.w3.org/2001/XMLSchema#.
• the datatype number whose identifier URL is http://www.w3.org/2001/XMLSchema#double.
• the datatype binary whose identifier URL is http://www.w3.org/2001/XMLSchema#base64Binary.
• the datatype datetime whose identifier URL is http://www.w3.org/2001/XMLSchema#dateTime.
• the datatype any whose identifier URL is http://www.w3.org/2001/XMLSchema#anyAtomicType.
• the datatype xml, a sub-type of string, whose identifier URL is http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral and which indicates the value is an XML fragment.
• the datatype html, a sub-type of string, whose identifier URL is http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML and which indicates the value is an HTML fragment.
• the datatype json, a sub-type of string, whose identifier URL is http://www.w3.org/ns/csvw#JSON and which indicates the value is serialized JSON.

Derived Datatypes

More specialized datatypes can be defined through a datatype description. A datatype description may have any of the following properties, all of which are optional.

base

An atomic property that contains a single string: the name of one of the built-in datatypes, as listed above (and which are defined as terms in the default context). Its default is string. All values of the datatype MUST be valid values of the base datatype. The value of this property becomes the base annotation for the described datatype.

format

An atomic property that contains either a single string or an object that defines the format of a value of this type, used when parsing a string value as described in Parsing Cells in [[!tabular-data-model]]. The value of this property becomes the format annotation for the described datatype.

length

A numeric atomic property that contains a single integer that is the exact length of the value. The value of this property becomes the length annotation for the described datatype. See Length Constraints in [[!tabular-data-model]] for details.

minLength

An atomic property that contains a single integer that is the minimum length of the value. The value of this property becomes the minimum length annotation for the described datatype. See Length Constraints in [[!tabular-data-model]] for details.

maxLength

A numeric atomic property that contains a single integer that is the maximum length of the value. The value of this property becomes the maximum length annotation for the described datatype. See Length Constraints in [[!tabular-data-model]] for details.

minimum

An atomic property that contains a single number or string that is the minimum valid value (inclusive); equivalent to minInclusive. The value of this property becomes the minimum annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

maximum

An atomic property that contains a single number or string that is the maximum valid value (inclusive); equivalent to maxInclusive. The value of this property becomes the maximum annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

minInclusive

An atomic property that contains a single number or string that is the minimum valid value (inclusive). The value of this property becomes the minimum annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

maxInclusive

An atomic property that contains a single number or string that is the maximum valid value (inclusive). The value of this property becomes the maximum annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

minExclusive

An atomic property that contains a single number or string that is the minimum valid value (exclusive). The value of this property becomes the minimum exclusive annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

maxExclusive

An atomic property that contains a single number or string that is the maximum valid value (exclusive). The value of this property becomes the maximum exclusive annotation for the described datatype. See Value Constraints in [[!tabular-data-model]] for details.

@id

If included, @id is a link property that identifies the datatype described by this datatype description. The value of this property becomes the id annotation for the described datatype. It MUST NOT start with _: and it MUST NOT be the URL of a built-in datatype.

@type

If included, @type is an atomic property that MUST be set to "Datatype". Publishers MAY include this to provide additional information to JSON-LD based toolchains.

The datatype description MAY contain any common properties to provide extra metadata about the datatype, such as a title or description.

Applications MUST raise an error if the @id property has the value of a built-in datatype and any other property is specified. In these cases, the other properties are ignored.

Applications MUST raise an error if both length and minLength are specified and length is less than minLength. Similarly, applications MUST raise an error if both length and maxLength are specified and length is greater than maxLength. Applications MUST raise an error if minLength and maxLength are both specified and minLength is greater than maxLength. Applications MUST raise an error if length, maxLength, or minLength are specified and the base datatype is neither string, a subtype of string, nor a binary type.

In all ways, including the errors described below, the minimum property is equivalent to the minInclusive property and the maximum property is equivalent to the maxInclusive property. Applications MUST raise an error if both minimum and minInclusive are specified and they do not have the same value. Similarly, applications MUST raise an error if both maximum and maxInclusive are specified and they do not have the same value.

Applications MUST raise an error if both minInclusive and minExclusive are specified, or if both maxInclusive and maxExclusive are specified. Applications MUST raise an error if both minInclusive and maxInclusive are specified and maxInclusive is less than minInclusive, or if both minInclusive and maxExclusive are specified and maxExclusive is less than or equal to minInclusive. Similarly, applications MUST raise an error if both minExclusive and maxExclusive are specified and maxExclusive is less than minExclusive, or if both minExclusive and maxInclusive are specified and maxInclusive is less than or equal to minExclusive.

Applications MUST raise an error if minimum, minInclusive, maximum, maxInclusive, minExclusive, or maxExclusive are specified and the base datatype is not a numeric, date/time, or duration type.

Validation against these properties is as defined in [[!xmlschema11-2]].

{
  "datatype": "date",
  "format": "dd/MM/yyyy",
  "minimum": "2000-01-01"
}