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.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 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 timezone Z; 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 an 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. 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 an 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 decimal 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.3 The Lexical Space and Lexical Mapping
Editorial Note: Some things in this section and elsewhere will need to be rewritten once we decide just how
to deal with context-dependent lexical mappings and lexical spaces.
[Definition:] The
lexical mapping for a datatype is a prescribed function whose domain is a prescribed set of character
strings (the ·lexical space·) and whose range is the
·value space· of that datatype.
[Definition:] The
lexical space of a datatype is the prescribed domain of
·the lexical mapping·
for that datatype.
[Definition:] The
members of the ·lexical space· are lexical
representations of the values to which they are mapped.
Should a derivation be made using a derivation mechanism that
removes ·lexical representations· from
the·lexical space· to the extent that one or more values cease
to have any ·lexical representation·, then those values are
dropped from the ·value space·.
Note: This could happen by means of a
pattern facet.
Conversely, should a derivation remove values then their
·lexical representations· are dropped
from the ·lexical space· unless there is a facet value whose
impact is defined to cause the otherwise-dropped ·lexical representation·
to be mapped to another value instead.
Note: There are currently no facets with such an impact. There may be
in the future.
For example, '100' and '1.0E2' are two different
·lexical
representations· from the float datatype
which both denote the same value. The datatype
system defined in this specification provides mechanisms for schema designers
to control the ·value space· and the corresponding set of acceptable
·lexical
representations· of those values for a datatype.
2.4 Facets
Issue (RQ-24-1i):RQ-24 (systematic approach to facets)This decision is not yet written up herein: The four informational facets, each of which have only one property,
will be lumped into one facet having four properties. This will represent a further technical change to the
facet structure, but will not result in any additional or lost information in a schema.
[Definition:] Facets are designated and named
values that either provide information about an aspect of the datatype (·information
facets·) or control some aspect of the datatype
(·constraining facets·). For example, each datatype has a
cardinality facet whose
value generally tells something about the finiteness of the datatype, and each datatype has
a whiteSpace facet whose value controls the "normalization" of the
raw data-character string in the XML document undergoes prior to being treated as a potential
member of the ·lexical space·.
Facets are of two kinds:
[Definition:] information facets provide the
application with some information about the datatype, and
[Definition:] constraining facet values may be set or changed
during derivation (subject to facet-specific controls)
and which control various aspects of the derived datatype. For example, cardinality
is an information facet and whiteSpace is a constraining facet. The various information
facets are described in Information Facets (§4.3) and constraining facets in
Constraining Facets (§4.4).
Note: In the 1.0 version of this specification, information facets were called
"fundamental facets". Information facets are not required for schema processing,
but some applications use them.
2.5 Datatype dichotomies
It is useful to categorize the datatypes defined in this specification
along various dimensions, forming a set of characterization dichotomies.
2.5.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 ·match·es
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.6.1.1 Atomic datatypes
·atomic· datatypes can be either
·primitive· or ·derived·. The
·value space· of an ·atomic· datatype
is a set of "atomic" values, which for the 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.
2.6.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 ·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.6.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 ·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.5.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.
