2 Datatype System
This section describes the conceptual framework behind the datatype system defined in this specification. The framework has been influenced by the [ISO 11404] standard on language-independent datatypes as well as the datatypes for [SQL] and for programming languages such as Java.
The datatypes discussed in this specification are for the most part well known abstract concepts such as integer and date. It is not the place of this specification to thoroughly define these abstract concepts; many other publications provide excellent definitions. However, this specification will attempt to describe the abstract concepts well enough that they can be readily recognized and distinguished from other abstractions with which they may be confused.
2.4 Datatype
Distinctions
2.4.2 Special vs. Primitive vs. Ordinary Datatypes
2.4.3 Definition, Derivation, Restriction, and Construction
2.4.4 Built-in vs. User-Defined Datatypes
It is useful to categorize the datatypes defined in this specification along various dimensions, defining terms which can be used to characterize datatypes and the Simple Type Definitions which define them.
2.4.1 Atomic vs. List vs. Union Datatypes
First, we distinguish ·atomic·, ·list·, and ·union· datatypes.
- [Definition:] Atomic datatypes are those having values treated by this specification as indivisible. Atomic datatypes are anyAtomicType and all datatypes ·derived· from it.
- [Definition:] List datatypes are
those having values each of which consists of a finite-length
(possibly empty) sequence of values of an ·atomic· datatype (or a ·union·
of ·atomic· datatypes), which is the ·item type· of the list.
↑↑Note: It is a consequence of constraints normatively specified elsewhere in this document that the ·item type· of a list may be any ·atomic· datatype, or any ·union· datatype whose ·transitive membership· consists solely of ·atomic· datatypes (so a ·list· of a ·union· of ·atomic· datatypes is possible, but not a ·list· of a ·union· of ·lists·). The ·item type· of a list must not itself be a list datatype.
- [Definition:] Union datatypes
are (a) those whose ·value
spaces·, ·lexical spaces·, and ·lexical mappings· are the union of the ·value spaces·, ·lexical
spaces·, and ·lexical mappings· of one or more other datatypes, which
are the ·member types· of the union, or (b) those derived by
·facet-based
restriction· of another union
datatype.
↑↑Note: It is a consequence of constraints normatively specified elsewhere in this document that any ·primitive· or ·ordinary· datatype may occur among the ·member types· of a ·union·. (In particular, ·union· datatypes may themselves be members of ·unions·, as may ·lists·.) The only prohibition is that no ·special· datatype may be a member of a ·union·.
For example, a single token which ·matches· Nmtoken from [XML] is in the value space of the ·atomic· datatype NMTOKEN, while a sequence of such tokens is in the value space of the ·list· datatype NMTOKENS.
2.4.1.3 Union datatypes
Union types may be defined in either of two ways. When a union type is ·constructed· by ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are the "ordered unions" of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·member types·. When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·. ·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·built-in· ·union· datatypes.
<attributeGroup name="occurs">
<attribute name="minOccurs" type="nonNegativeInteger"
use="optional" default="1"/>
<attribute name="maxOccurs"use="optional" default="1">
<simpleType>
<union>
<simpleType>
<restriction base='nonNegativeInteger'/>
</simpleType>
<simpleType>
<restriction base='string'>
<enumeration value='unbounded'/>
</restriction>
</simpleType>
</union>
</simpleType>
</attribute>
</attributeGroup>
Any number ↓(greater than 0)↓↓(zero or more)↓ of ordinary or ·primitive· ·datatypes· can participate in a ·union· type.
[Definition:] The datatypes that participate in the definition of a ·union· datatype are known as the member types of that ·union· datatype.
[Definition:] The transitive membership of a ·union· is the set of its own ·member types·, and the ·member types· of its members, and so on. More formally, if U is a ·union·, then (a) its ·member types· are in the transitive membership of U, and (b) for any datatypes T1 and T2, if T1 is in the transitive membership of U and T2 is one of the ·member types· of T1, then T2 is also in the transitive membership of U.
[Definition:] Those members of the ·transitive membership· of a ·union· datatype U which are themselves not ·union· datatypes are the basic members of U.
[Definition:] If a datatype M is in the ·transitive membership· of a ·union· datatype U, but not one of U's ·member types·, then a sequence of one or more ·union· datatypes necessarily exists, such that the first is one of the ·member types· if U, each is one of the ·member types· of its predecessor in the sequence, and M is one of the ·member types· of the last in the sequence. The ·union· datatypes in this sequence are said to intervene between M and U. When U and M are given by the context, the datatypes in the sequence are referred to as the intervening unions. When M is one of the ·member types· of U, the set of intervening unions is the empty set.
[Definition:] In a valid instance of any ·union·, the first of its members in order which accepts the instance as valid is the active member type. [Definition:] If the ·active member type· is itself a ·union·, one of its members will be its ·active member type·, and so on, until finally a ·basic (non-union) member· is reached. That ·basic member· is the active basic member of the union.
The order in which the ·member
types· are specified in the
definition (that is, in the case of datatypes defined in a schema
document, the order of the <simpleType> children of the
<union> element, or the order of the QNames in the memberTypes attribute) is
significant. During validation, an element or attribute's value is
validated against the ·member
types· in the order in which
they appear in the definition until a match is found. The
evaluation order can be overridden with the use of xsi:type.
<xsd:element name='size'>
<xsd:simpleType>
<xsd:union>
<xsd:simpleType>
<xsd:restriction base='integer'/>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base='string'/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>
</xsd:element>
<size>1</size> <size>large</size> <size xsi:type='xsd:string'>1</size>
The ·canonical mapping· of a ·union· datatype maps each value onto the ·canonical representation· of that value obtained using the ·canonical mapping· of the first ·member type· in whose value space it lies.
4 Datatype components
...
4.1 Simple Type Definition
4.1.2 XML Representation of Simple Type Definition Schema Components
4.1.3 Constraints on XML Representation of Simple Type Definition
4.1.4 Simple Type Definition Validation Rules
4.1.5 Constraints on Simple Type Definition Schema Components
4.1.6 Built-in Simple Type Definitions
Simple Type Definitions provide for:
- In the case of ·primitive· datatypes, identifying a datatype with its definition in this specification.
- In the case of ·constructed· datatypes, defining the datatype in terms of other datatypes.
- Attaching a QName to the datatype.
4.1.1 The Simple Type Definition Schema Component
The Simple Type Definition schema component has the following properties:
Either an Attribute Declaration, an Element Declaration, a Complex Type Definition or a Simple Type Definition.
With one exception, the {base type definition} of any Simple Type Definition is a Simple Type Definition. The exception is ·anySimpleType·, which has anyType, a Complex Type Definition, as its {base type definition}.
If not absent, must be a ·primitive· built-in definition.
↓Must not be empty↓↑Must be present (but may be empty)↑ if {variety} is union, otherwise must be absent.
Simple type definitions are identified by their {name} and {target namespace}. Except for anonymous Simple Type Definitions (those with no {name}), Simple Type Definitions must be uniquely identified within a schema. Within a valid schema, each Simple Type Definition uniquely determines one datatype. The ·value space·, ·lexical space·, ·lexical mapping·, etc., of a Simple Type Definition are the ·value space·, ·lexical space·, etc., of the datatype uniquely determined (or "defined") by that Simple Type Definition.
If {variety} is ·atomic· then the ·value space· of the datatype defined will be a subset of the ·value space· of {base type definition} (which is a subset of the ·value space· of {primitive type definition}). If {variety} is ·list· then the ·value space· of the datatype defined will be the set of finite-length sequences of values from the ·value space· of {item type definition}. If {variety} is ·union· then the ·value space· of the datatype defined will be a subset (possibly an improper subset) of the union of the ·value spaces· of each Simple Type Definition in {member type definitions}.
If {variety} is ·atomic· then the {variety} of {base type definition} must be ·atomic·, unless the {base type definition} is anySimpleType. If {variety} is ·list· then the {variety} of {item type definition} must be either ·atomic· or ·union·, and if {item type definition} is ·union· then all its ·basic members· must be ·atomic·. If {variety} is ·union· then {member type definitions} must be a list of Simple Type Definitions.
The {facets} property determines the ·value space· and ·lexical space· of the datatype being defined by imposing constraints which must be satisfied by values and ·lexical representations·.
The {fundamental facets} property provides some basic information about the datatype being defined: its cardinality, whether an ordering is defined for it by this specification, whether it has upper and lower bounds, and whether it is numeric.
If {final} is the empty set then the type can be used in deriving other types; the explicit values restriction, list and union prevent further derivations of Simple Type Definitions by ·facet-based restriction·, ·list· and ·union· respectively; the explicit value extension prevents any derivation of Complex Type Definitions by extension.
The {context} property is only relevant for anonymous type definitions, for which its value is the component in which this type definition appears as the value of a property, e.g. {item type definition} or {base type definition}.