Datatypes for document content validation

Part 5 of the Document Schema Description Language (DSDL) defines a set of primitive datatypes, a set of DSDL datatypes, a set of commonly required derived datatypes and a method for defining customized datatypes that can be used to validate the contents of specific elements and attributes within DSDL document instances. The specification also includes a set of constraints that can be used to limit the range of primitive datatypes and their derivatives.

1. Primitive Datatypes

The following primitive datatypes can be used to derive other datatypes:

[Issue 1-6: Should the language independent datatypes defined in ISO 11404 ( not incorporated into XML Schema Part 2 be considered, given that this document is currently under review by SC22, having first been published in 1996?

NB: ISO 11404 primitives are:

primitive-type = boolean-type | state-type | enumerated-type | character-type | ordinal-type | time-type | integer-type | rational-type | scaled-type | real-type | complex-type | void-type 

The types that specifically need to be considered for inclusion are "state-type", "ordinal-type", "scaled-type" and "void-type". The "boolean-type", "character-type", "time-type" and "real-type" can be equated to existing definitions. Whether "complex-type" and "enumerated-type" are true datatypes or expressions of ways in which datatypes can be created from basic types is questionable.

Other ISO 11404 types of possible interest include:

generated-type = pointer-type | procedure-type | choice-type | aggregate-type 
aggregate-type = record-type | set-type | sequence-type | bag-type | array-type | table-type

2. DSDL Datatypes

The following datatypes are used to identify constructs that conform to DSDL constraints:

NB: This list will need to be revised in the light of the development of DSDL.

[Issue 2-1: At what point is datatype validation applied? Do we really need all of these?]

[Issue 2-6: What other types of DSDL data types will there be?]

[Issue 2-7: Should we include DSSSL types such as quantity, pair, real (if floating point is not defined in an acceptable form for DSSSL) and number (if not directly mappable to the fixed point number construct)?]

3. Commonly Required Derived Datatypes

The following commonly used datatypes can be derived from primitive datatypes:

[Issue 3-10: Do we need to define all the alternative ISO 8601 date variants (e.g. without hyphens and colons, etc), or will the limited dateTime primitive definitions shown above be sufficient?]

[Issue 3-11: What other options do we need to allow for? Should ISO 639 language be included (if so what about the IETF rules re extensions)? What about currency as used in XForms, in support of ISO 4217 (or is this simply an application of decimal)?]

4. Constraining Properties

The following properties can be used to constrain datatypes that are derived from strings:


The following properties can be used to constrain datatypes that are derived from fixed point and floating point numbers:

The following additional properties can be used to constrain fixed point numbers:

The following properties can be used to constrain any datatype:

[Issue 4.2: Should more than one pattern grammar be allowed for by applying a pointer to the relevant grammar at some higher level in the syntax?]

5. Deriving Customized Datatypes

Each type defined in a DSDL schema must be assigned a unique identifier as its name, which must not be identical to any of the names assigned to primitive or derived datatypes defined in this standard, or to the name of any customized datatype imported into the schema. The datatype name must conform to the rules for defining DSDL names.

[Issue 5-1: Should datatype names be DSDL unique identifiers or keys? How can we ensure that imported datatypes do not share the same name?]

Each set of constraints defined for a datatype shall be based on either a primitive datatype, a derived datatype defined in this standard or a customized datatype defined in, or imported into, the same schema. The unique identifier of the base datatype must be specified as an attrribute of the constraint element.

Constraining properties shall be entered as subelements of the constraints definition using elements whose name is shown in brackets after the name of the property. Only those properties relevant for the primitive datatype from which the datatype is derived may be defined.

[Issue 5-2: How will DSDL allow us to manage the fact that models of the constraints element will be dependent on the value given to the base attribute, which may in its turn be derived from a customized datatype rather than a primitive?]

[Issue 5-3: How will patterns be specified? How can we restrict the number of times a part of a pattern is repeated?]

Where only specified values are to be permitted a list of validValues may be specified. These values can be assigned a value for the rule attribute of either "no-others" to indicate that only specified values are valid, or of "with-others" to indicate that the list of  validValues only indicates currently known values, which the user can extend by entering any other value that conforms to the constraints assigned to the datatype. Where no value is specified for the rule attribute the default value of "no-others" applies. Optionally a statement of meaning can be assigned to each value. 

The invalidValues element can be used to identify specific values that may not be used as valid entries. Optionally a statement of the reason why the value is invalid can be assigned to each value.

[Issue 5-4: Should datatype be allowed to have structured values? (NB: XML Schema defines permitted enumeration values as attributes, which allows the element itself to consist solely of annotation.)]

The following example shows how customized datatypes can be expressed using the elements defined in Appendix A.

<datatype name="type-a">
 <constraints base="string">
  <validValues rule="no-others">
    <meaning>Latin alphabet</meaning>
    <meaning>Braille alphabet</meaning>
    <reason>Can be confused with bed.</reason>

Appendix A: DSDL Schema for the Specification of Datatypes

To follow