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.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.
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 (§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 restrictions by enumeration, and when checking
identity 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. It turns out that, for example, 0.1 and 0.10000000009 are effectively identical in
float but not in decimal. (Neither 0.1 nor 0.10000000009 are in
the float value space, but ·the lexical mapping·
of float maps both '0.1' and '0.10000000009' to
the same number (0.100000001490116119384765625) that is in the float value space.)
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, it has been carefully defined so as to be a congruence relation for most
other operations of interest to the datatype. (This means simply that 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.
For example, identity is by definition a congruence relation for all other operations
of interest.) Equality is always a congruence for the order relation.
On the other hand,
equality need not cover the entire value space of the
datatype (though it usually does).
The equality relation is used in conjunction with
order when making 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 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.2.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 pDecimal 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 alway 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 dichotomies
It is useful to categorize the datatypes defined in this specification
along various dimensions, forming a set of characterization dichotomies.
2.4.1 Atomic vs. list vs. union datatypes
The first distinction to be made is that between
·atomic·, ·list· and ·union·
datatypes.
For example, a single token which ·matches·
Nmtoken from
[XML] could be the value of an ·atomic·
datatype (NMTOKEN); while a sequence of such tokens
could be the value of a ·list· datatype
(NMTOKENS).
2.4.1.1 Atomic datatypes
An ·atomic· datatype
has a ·value space· consisting of a set of
"atomic" values which for purposes of this specification
are not further decomposable.
The ·lexical space· of
an ·atomic· datatype is a set of literals
whose internal structure is specific to the datatype in question.
There is one "special"
atomic type (anyAtomicType) and a number of
·primitive· atomic types, which have
anyAtomicType as their base type.
All other atomic types are derived by restriction either from
one of the primitive atomic types or from another ordinary atomic
type. No user-defined type may have anyAtomicType
as its base type.
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 ·derived·.
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 whose internal
structure is a space-separated
sequence of literals of the
·atomic· datatype of the items in the
·list·.
[Definition:]
The ·atomic· or ·union·
datatype that participates in the definition of a ·list· datatype
is known as the itemType of that ·list· datatype.
<simpleType name='sizes'>
<list itemType='decimal'/>
</simpleType>
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
A ·list· datatype can be ·derived·
from an ordinary ·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.
In such a case, regardless of the input, list items
will be separated at space boundaries.
<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· from a
·list· datatype, the following
·constraining facet·s apply:
For each of ·length·, ·maxLength·
and ·minLength·, the unit of 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 its ·itemType·. Hence, any
·pattern· specified when a new datatype is
·derived· from a ·list· datatype is matched against
each literal of the ·list· datatype and
not against the literals of the datatype that serves as its
·itemType·.
<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-lexical-representation for the
·list· datatype is defined as the lexical form in which
each item in the ·list· has the canonical lexical
representation of its ·itemType·.
2.4.1.3 Union datatypes
The ·value space· and ·lexical space·
of a ·union· datatype are the union of the
·value space·s and ·lexical space·s of
its ·memberTypes·.
·union· datatypes are always ·derived·.
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 1) of ordinary
·atomic· or ·list·
·datatype·s can participate in a ·union· type.
[Definition:]
The datatypes that participate in the
definition of a ·union· datatype are known as the
memberTypes of that ·union· datatype.
The order in which the ·memberTypes· are specified in the
definition (that is, 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
·memberTypes· 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.3.13), the second and third as
string (§3.2.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-lexical-representation for a
·union· datatype is defined as the lexical form in which
the values have the canonical lexical representation
of the appropriate ·memberTypes·.
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 Primitive vs. Constructed Datatypes
Next, we distinguish between ·primitive·,
·constructed·, and
·derived· datatypes.
- [Definition:] Primitive
datatypes are those that are not defined in terms of other datatypes;
they exist ab initio.
- [Definition:] Constructed
datatypes are those that are defined in terms of other datatypes.
For example, in this specification, float is a well-defined
mathematical
concept that cannot be defined in terms of other datatypes, while
a integer is a special case of the more general datatype
decimal.
[Definition:]
The definition of anySimpleType
is a special restriction of
anyType.
anySimpleType is considered to have an unconstrained lexical space and a
·value space· consisting of the union of the
·value space·s of all the
·primitive·
datatypes and the set of all lists of all members of the
·value space·s of all the
·primitive· datatypes.
The datatypes defined by this specification fall into both
the ·primitive· and ·derived·
categories. It is felt that a judiciously chosen set of
·primitive· datatypes will serve the widest
possible audience by providing a set of convenient datatypes that
can be used as is, as well as providing a rich enough base from
which the variety of datatypes needed by schema designers can be
·derived·.
In the example above, integer is ·derived·
from decimal.
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
·derived· in this specification need not be a
"derived" datatype in any programming language used to implement
this specification.
As described in more detail in XML Representation of Simple Type Definition Schema Components (§4.1.2),
each ·user-derived· datatype ·must·
be defined in terms of another datatype in one of three ways: 1) by assigning
·constraining facet·s which serve to restrict the
·value space· of the ·user-derived·
datatype to a subset of that of the ·base type·; 2) by creating
a ·list· datatype whose ·value space·
consists of finite-length sequences of values of its
·itemType·; or 3) by creating a ·union·
datatype whose ·value space· consists of the union of the
·value space·s of its ·memberTypes·.
2.4.3 Built-in vs. user-derived datatypes
Conceptually there is no difference between the
·built-in· ·derived· datatypes
included in this specification and the ·user-derived·
datatypes which will be created by individual schema designers.
The ·built-in· ·derived· datatypes
are those which are believed to be so common that if they were not
defined in this specification many schema designers would end up
"reinventing" them. Furthermore, including these
·derived· datatypes in this specification serves to
demonstrate the mechanics and utility of the datatype generation
facilities of this specification.
Note:
A datatype which is
·built-in· in this specification
need not be a "built-in" datatype in any programming language used
to implement this specification. Likewise, a datatype which is
·user-derived· in this specification need not
be a "user-derived" datatype in any programming language used to
implement this specification.