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.
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.
Note: This specification sometimes uses the shorter form "type"
where one might strictly speaking expect the longer form
"datatype" (e.g. in the phrases
"union type", "list type",
"base type", "item type", etc.
No systematic distinction is intended between
the forms of these phrase with "type" and
those with "datatype";
the two forms are used interchangeably.
The distinction between "datatype"
and "simple type definition", by contrast,
carries more information: the datatype is characterized by its
·value space·,
·lexical space·,
·lexical mapping·, etc., as
just described, independently of the specific facets or
other definitional mechanisms used in the simple type
definition to describe that particular
·value space·
or
·lexical space·. Different simple type definitions
with different selections of facets can describe the
same datatype.
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
·primitive· or ·ordinary·
datatype is
denoted by one or more character strings in its ·lexical space·,
according to ·the lexical
mapping·; ·special·
datatypes, by contrast, may include "ineffable"
values not mapped to by any lexical representation.
(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
and
equality
are required for each
value space. An
order relation is specified for some value spaces, but not
all.
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.
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 0.1 nor 0.10000000009 is in the value space, and
each literal is mapped to the
nearest value, namely 0.100000001490116119384765625), but map to
distinct values in decimal.
Given a list A and a list B, A and B
are the same list if they are the same sequence of atomic values.
The necessary and sufficient conditions for this identity are
that A and B have the same length and that the items of A
are pairwise identical to the items of B.
Note: It is a consequence of the rule just given for list identity
that there is only one empty list. An empty list declared as
having
·item type· decimal and an empty
list declared as having
·item type· string
are not only equal but identical.
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
is not equal to itself in the precisionDecimal,
float, and double datatypes.
The equality relation is used
when
making ·facet-based restrictions· by enumeration,
when checking identity constraints (in the context of
[XSD 1.1 Part 1: Structures]), when checking value
constraints, and
in conjunction with order when making
·facet-based restrictions· involving order.
All comparisons for
"sameness" prescribed by this specification
test for equality, not for identity.
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.
Two lists A and B are equal if and
only if they have the same length and their items are pairwise equal.
A list of length one containing a value V1 and an atomic value
V2 are equal if and only if V1 is equal to V2.
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
For some
datatypes, an order relation is prescribed
for use in checking
upper and lower bounds of the ·value space·. 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,
no order
is prescribed; each pair of values is either
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))
ensures
that this is true.
For
purposes of this specification, the value spaces of primitive datatypes are
disjoint, even in cases where the
abstractions they represent might be thought of as having
values in common. In the order
relations defined in this specification, values from
different value spaces are
·incomparable·. For example, the numbers two
and three are values in both the
decimal
datatype and the float datatype. In the order relation defined
here,
the two in the decimal datatype
is
not less than the three in the float datatype;
the two values are
incomparable. Other
applications making use of these
datatypes may choose to consider values such as these comparable.
Note: Comparison of values from different
·primitive· datatypes
can sometimes be an error and sometimes not, depending on context.
When made for purposes of checking an enumeration constraint,
such a comparison is not in itself an error, but since
no
two values from different
·primitive· ·value spaces· are
equal, any
comparison of
·incomparable· values will invariably be false.
Specifying an upper or lower bound which is of the wrong primitive
datatype (and therefore
·incomparable· with the values of the datatype
it is supposed to restrict) is, by contrast, always an error.
It is a consequence of the rules for
·facet-based restriction· that in conforming simple type definitions, the
values of upper and lower bounds, and enumerated values,
must be
drawn from the value space of the
·base type·, which necessarily means
from the same
·primitive· datatype.