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.
Note: Only those operations and relations needed for schema processing
are defined in this specification. Applications using these datatypes
are generally expected to implement appropriate additional functions
and/or relations to make the datatype generally useful. For
example, the description herein of the
float datatype
does not define addition or multiplication, much less all of the
operations defined for that datatype in
[IEEE 754-1985] on
which it is based.
For some datatypes (e.g.
language or
anyURI) defined in part by
reference to other specifications which impose constraints not part of
the datatypes as defined here, applications may also wish to check
that values conform to the requirements given in the current version
of the relevant external specification.
2.1 Datatype
[Definition:] In
this specification, a datatype has
three properties:
Note: This specification only defines the operations and relations needed
for schema processing. The choice of terminology for
describing/naming the datatypes is selected to guide users and
implementers in how to expand the datatype to be generally
useful—i.e., how to recognize the "real world"
datatypes and their variants for which the datatypes defined herein
are meant to be used for data interchange.
Along with the ·lexical mapping· it is
often useful to have an inverse which provides a standard
·lexical representation· for each value. Such
a ·canonical mapping· is not required for
schema processing, but is described herein for the benefit of users of
this specification, and other specifications which might find it
useful to reference these descriptions normatively.
For some datatypes, notably
QName and NOTATION, the mapping from
lexical representations to values is context-dependent; for these
types, no ·canonical mapping· is defined.
2.2 Value space
[Definition:] The value space of a
datatype is the set of values for that
datatype. Associated with each value space are
selected operations and relations necessary to permit proper schema
processing. Each value in the value space of a datatype is
denoted by one or more character strings in its ·lexical space·,
according to ·the lexical
mapping·. (If the mapping is restricted during a
derivation in such a way that a value has no denotation, that value is
dropped from the value space.)
The value spaces of datatypes are abstractions,
and are defined in Built-in Datatypes and Their Definitions (§3)
to the extent needed to clarify them for readers. For example,
in defining the numerical datatypes, we assume some general numerical
concepts such as number and integer are known. In many cases we
provide references to other documents providing more complete
definitions.
Note: The value spaces and the values therein are
abstractions. This specification does not prescribe any
particular internal representations that must be used when
implementing these datatypes. In some cases, there are
references to other specifications which do prescribe specific
internal representations; these specific internal representations must
be used to comply with those other specifications, but need not be
used to comply with this specification.
In addition, other applications are expected to define additional
appropriate operations and/or relations on these value spaces (e.g.,
addition and multiplication on the various numerical datatypes'
value spaces), and are permitted where appropriate to even redefine
the operations and relations defined within this specification,
provided that
for schema processing the relations and operations
used are those defined herein.
The ·value space· of a datatype can
be defined in one of the following ways:
- defined elsewhere
axiomatically from fundamental notions (intensional definition) [see
·primitive·]
- enumerated outright from values
of an already defined datatype (extensional definition) [see
·enumeration·]
- defined by restricting the ·value space· of an already
defined datatype to a particular subset with a given set of properties
[see derived]
- defined as a combination of values from one or more already
defined ·value space·(s) by a specific construction procedure [see
·list· and ·union·]
The relations of identity,
equality, and order are required for each
value space. A very few datatypes have other relations or
operations prescribed for the purposes of this specification.
2.2.1 Identity
The identity relation is always defined. Every value space
inherently has an identity relation. Two things are
identical if and only
if they are actually the same thing: i.e., if there is no way
whatever to tell them apart. The identity relation is used when
making ·facet-based restrictions· by enumeration, when checking identity
constraints, and when checking value
constraints. These are the only uses of
identity for schema processing.
Note: This does not preclude implementing datatypes by using more than
one internal representation for a given value, provided
no mechanism inherent in the datatype implementation (i.e., other than
bit-string-preserving "casting" of the datum to a different
datatype) will distinguish between the two representations.
In the identity relation defined herein, values from different
·primitive· datatypes' ·value spaces· are made artificially
distinct if they might otherwise be considered identical. For
example, there is a number two in the decimal datatype and a number two in the float datatype. In the identity relation defined herein,
these two values are considered distinct. Other applications
making use of these datatypes may choose to consider values such as
these identical, but for the view of ·primitive· datatypes'
·value spaces· used herein, they are distinct.
WARNING: Care must be taken when identifying
values across distinct primitive datatypes. The
·literals· '0.1' and '0.10000000009' map
to the same value in float (neither is in the value
space, and each is mapped to the nearest value, namely
0.100000001490116119384765625), but map to distinct values in decimal.
2.2.2 Equality
Each ·primitive· datatype has prescribed an equality relation for
its value space. The equality relation for most datatypes is the
identity relation. In the few cases where it is not, equality has been carefully defined so that for
most operations of
interest to the datatype, if
two values are equal and one is substituted for the other as an
argument to any of the operations, the results will always also be
equal.
On the other hand, equality need not cover the entire value space
of the datatype (though it usually does). In particular, NaN <> NaN in the precisionDecimal, float, and double datatypes.
The equality relation is used in conjunction with order when making
·facet-based restrictions· involving order. This is the only use of
equality for schema processing.
Note: In the prior version of this specification (1.0), equality was
always identity. This has been changed to permit the datatypes
defined herein to more closely match the "real world"
datatypes for which they are intended to be used as transmission
formats.
For example, the
float datatype has an equality
which is not the identity ( −0 = +0 , but
they are not identical—although they
were identical
in the 1.0 version of this specification), and whose domain excludes
one value, NaN, so that NaN ≠ NaN .
For another example, the
dateTime datatype
previously lost any timezone information in the
·lexical representation· as the value was converted to
·UTC·; now the timezone
is retained and two values representing the same "moment in
time" but with different remembered timezones are now
equal but not
identical.
In the equality relation defined herein, values from different
primitive data spaces are made artificially unequal even if they might
otherwise be considered equal. For example, there is a number
two in the decimal datatype and a number
two in the float datatype. In the
equality relation defined herein, these two values are considered
unequal. Other applications making use of these datatypes may
choose to consider values such as these equal (and must do so if they
choose to consider them identical); nonetheless, in the equality
relation defined herein, they are unequal.
For the purposes of this specification, there is one equality
relation for all values of all datatypes (the union of the various
datatype's individual equalities, if one consider relations to be
sets of ordered pairs). The equality relation is
denoted by '=' and its negation by
'≠', each used as a binary infix predicate:
x = y and
x ≠ y . On the other
hand, identity relationships are always described in
words.
2.2.3 Order
Each datatype has an order relation prescribed. This order may be
a partial order, which means that there may be values in
the ·value space· which are neither equal, less-than, nor
greater-than. Such value pairs are
incomparable. In many cases, the prescribed order
is the "null order": the ultimate partial
order, in which no pairs are less-than or greater-than; they are all
equal or ·incomparable·. [Definition:] Two
values that are neither equal, less-than, nor greater-than are
incomparable. Two values
that are not ·incomparable· are
comparable. The order relation is used
in conjunction with equality when making ·facet-based restrictions·
involving order. This is the only use of order for
schema processing.
In this specification, this less-than order relation is denoted by
'<' (and its inverse by '>'),
the weak order by '≤' (and its inverse by
'≥'), and the resulting ·incomparable· relation by
'<>', each used as a binary infix predicate:
x < y ,
x ≤ y ,
x > y ,
x ≥ y , and
x <> y .
Note: The weak order "less-than-or-equal" means
"less-than" or "equal"
and one
can tell which. For example, the
duration P1M (one month) is
not
less-than-or-equal P31D (thirty-one days) because P1M is not less than
P31D, nor is P1M equal to P31D. Instead, P1M is
·incomparable· with P31D.) The formal
definition of order for
duration (
duration (§3.3.7)) insures that this is true.
The value spaces of primitive datatypes are abstractions, which may
have values in common. In the order relation defined herein,
these value spaces are made artificially ·incomparable·. For example, the numbers two
and three are values in both the precisionDecimal
datatype and the float datatype. In the order relation defined
herein, two in the decimal datatype and three in the float datatype
are incomparable values. Other applications making use of these
datatypes may choose to consider values such as these comparable.
While it is not an error to attempt to compare values from the
value spaces of two different primitive datatypes, they will always be
·incomparable· and therefore unequal:
If x and y are in the value spaces of different
primitive datatypes then
x <> y (and hence
x ≠ y ).
2.4 Datatype
Distinctions
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.
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.2 List Datatypes
Several type systems (such as the one described in
[ISO 11404]) treat ·list· datatypes as
special cases of the more general notions of aggregate or collection
datatypes.
·List·
datatypes are always ·constructed· from
some other type; they are never ·primitive·.
The ·value space· of a ·list·
datatype is a set of finite-length sequences of
·atomic·
values. The ·lexical space· of a
·list· datatype is a set of
·literals·
each
of which
is a space-separated sequence of
·literals·
of the
·item type·.
[Definition:]
The ·atomic· or ·union·
datatype that participates in the definition of a ·list· datatype
is the
item type
of that ·list· datatype. If
the ·item type· is a ·union·, each of its
↓·member types·↓↑·basic members·↑ must be
·atomic·.
<simpleType name='sizes'>
<list itemType='decimal'/>
</simpleType>
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
A ·list· datatype can be
·constructed·
from an ordinary
or
·primitive· ·atomic·
datatype whose ·lexical space· allows space
(such as string or anyURI) or a
·union· datatype any of whose
{member type definitions}'s
·lexical space· allows space.
Since ·list·
items are separated at whitespace before the
·lexical representations·
of the items are mapped to values, no whitespace will ever occur
in the ·lexical representation·
of a ·list· item, even when the item
type would in principle allow it.
For the same reason, when every possible
·lexical representation· of a given
value in the ·value space· of the ·item type·
includes whitespace,
that value can never occur as an item in any value of the
·list· datatype.
<simpleType name='listOfString'>
<list itemType='string'/>
</simpleType>
<someElement xsi:type='listOfString'>
this is not list item 1
this is not list item 2
this is not list item 3
</someElement>
When a datatype is derived
by
·restricting· a
·list· datatype, the following
·constraining facets· apply:
For each of ·length·, ·maxLength·
and ·minLength·, the
length is
measured in number
of list
items. The value of ·whiteSpace·
is fixed to the value collapse.
For ·list· datatypes the ·lexical space·
is composed of space-separated
·literals·
of the
·item type·.
Any
·pattern· specified when a new datatype is
derived from a ·list· datatype
applies
to the members of the ·list· datatype's
·lexical space·, not to the members of the ·lexical space·
of the ·item type·.
<xs:simpleType name='myList'>
<xs:list itemType='xs:integer'/>
</xs:simpleType>
<xs:simpleType name='myRestrictedList'>
<xs:restriction base='myList'>
<xs:pattern value='123 (\d+\s)*456'/>
</xs:restriction>
</xs:simpleType>
<someElement xsi:type='myRestrictedList'>123 456</someElement>
<someElement xsi:type='myRestrictedList'>123 987 456</someElement>
<someElement xsi:type='myRestrictedList'>123 987 567 456</someElement>
The ·canonical mapping· of a
·list· datatype maps each value onto the
space-separated concatenation of the
·canonical
representations· of all the items in the value
(in order), using the ·canonical mapping· of the
·item type·.
2.4.1.3 Union datatypes
↓The ·value space·
and ·lexical space·
of a ·union· datatype are the union of the
·value spaces· and ·lexical spaces· of
its ·member types·.↓
↑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.
A prototypical example of a
·union· type is the
maxOccurs attribute on the
element element
in XML Schema itself: it is a union of nonNegativeInteger
and an enumeration with the single member, the string "unbounded", as shown below.
<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)
of ordinary
or
·primitive· ↓·atomic·
or ·list·↓
·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:] 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.
↑
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.
For example, given the definition below, the first instance of the <size> element
validates correctly as an
integer (§3.4.13), the second and third as
string (§3.3.1).
<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.
Note: A datatype which is
·atomic· in this specification
need not be an "atomic" datatype in any programming language used to
implement this specification. Likewise, a datatype which is a
·list· in this specification need not be a "list"
datatype in any programming language used to implement this specification.
Furthermore, a datatype which is a
·union· in this
specification need not be a "union" datatype in any programming
language used to implement this specification.
2.4.2 Special vs. Primitive vs.
Ordinary
Datatypes
Next, we distinguish ·special·,
·primitive·, and ·ordinary·
(or ·constructed·) datatypes.
For example, in this specification, float is a
·primitive· datatype based on
a well-defined mathematical concept
and
not
defined in terms of other datatypes, while
integer is ·constructed·
from the more general datatype decimal.
The datatypes defined
by this specification fall into
the categories
·special·,
·primitive·, and
·ordinary·. It
is felt that a judiciously chosen set of
·primitive· datatypes will serve a wide audience by
providing a set of convenient datatypes that
can be used as is, as well as providing a rich enough base from
which a
large variety of datatypes needed by schema designers can be
·constructed·.
Note: A datatype which is
·primitive· in this specification
need not be a "primitive"
datatype in any programming language used to
implement this specification. Likewise, a datatype which is
·constructed·
in this specification from
some other datatype need not be a "derived"
datatype in any programming language used to implement
this specification.
2.4.3 Definition, Derivation, Restriction, and Construction
Definition, derivation, restriction, and construction
are conceptually distinct, although in practice
they are frequently performed by the same mechanisms.
By 'definition' is meant the explicit
identification of the relevant properties of a datatype,
in particular its
·value space·,
·lexical space·, and
·lexical mapping·.
The properties of the ·special· and
·primitive· datatypes are defined by this
specification. A Simple Type Definition is present for each of these
datatypes in every valid schema; it serves as a representation of the
datatype, but by itself it does not capture all the relevant
information and does not suffice (without knowledge
of this specification) to define the datatype.
For all other datatypes, a Simple Type Definition does suffice.
The properties of an ·ordinary· datatype can be inferred
from the datatype's Simple Type Definition and the properties of
the ·base type·, ·item type·
if any, and ·member types· if any.
All ·ordinary· datatypes can be defined in this way.
By 'derivation' is meant the relation of
a datatype to its ·base type·, or to the
·base type· of its ·base type·,
and so on.
[Definition:] Every datatype
is associated with another datatype, its base type.
Base types can be ·special·,
·primitive·, or
·ordinary·.
[Definition:] A datatype
T is immediately derived from another datatype
X if and only if X is the
·base type· of T.
More generally,
[Definition:] A datatype R
is derived from another
datatype B if and only if one of the following is true:
- B is the ·base type·
of R.
- There is some datatype X
such that X is the ·base type·
of R, and X is derived from
B.
It is a consequence of these definitions that
every datatype other than anySimpleType is
derived from anySimpleType.
Since each datatype has exactly one ·base type·,
and every datatype is derived directly or
indirectly from anySimpleType, it follows that
the ·base type· relation arranges all
simple types into a tree structure, which is conventionally
referred to as the derivation hierarchy.
By 'restriction' is meant the definition
of a datatype whose ·value space· and ·lexical space· are
subsets of those of its ·base type·.
Formally,
[Definition:] A datatype R
is a restriction of another
datatype B when