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
float and
double datatypes.
This
equality relation is used in
conjunction with identity when
making ·facet-based restrictions· by enumeration,
when checking identity constraints (in the context of
[XSD 1.1 Part 1: Structures])
and when checking value
constraints. It is used in
conjunction with order when making
·facet-based restrictions· involving order. The
equality relation used in the evaluation of XPath expressions
may differ. When
processing
XPath expressions as part of XML schema-validity
assessment or
otherwise testing membership in the ·value space·
of a datatype whose derivation involves ·assertions·,
equality (like all other relations) within those expressions is interpreted
using the rules of XPath ([XPath 2.0]).
All comparisons for
"sameness" prescribed by this specification
test for either
equality or identity,
not for identity alone.
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 time-zone offset information in the
·lexical representation· as the value was converted to
·UTC·;
now the time zone offset
is retained and two values representing the same "moment in
time" but with different remembered time zone offsets 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;
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
this
order relation for schema
processing. Of course, when
processing
XPath expressions as part of XML schema-validity
assessment or
otherwise testing membership in the ·value space·
of a datatype whose derivation involves ·assertions·,
order (like all other relations) within those expressions is interpreted
using the rules of XPath ([XPath 2.0]).
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.6))
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.
2.3 The Lexical Space and Lexical Mapping
[Definition:] The
lexical mapping for a datatype is a prescribed
relation
which maps from the ·lexical space· of the datatype
into its ·value space·.
[Definition:] The
lexical space of a datatype is
the prescribed set of strings
which
·the lexical
mapping· for that datatype
maps to values of that datatype.
[Definition:] The members of the ·lexical space· are
lexical representations of the values to which they are
mapped.
[Definition:] A sequence of zero or more
characters in the Universal Character Set (UCS) which may or may not
prove upon inspection to be a member of the ·lexical space· of a given
datatype and thus a ·lexical representation· of a given value in that datatype's
·value space·, is referred to as a literal. The
term is used indifferently both for character sequences which are
members of a particular ·lexical space· and for those which are
not.
If a derivation introduces a
·pre-lexical· facet value (a new value for
whiteSpace or an implementation-defined
·pre-lexical· facet), the corresponding
·pre-lexical· transformation of a character string,
if indeed it changed that string, could prevent that string from ever
having the ·lexical mapping· of the derived datatype
applied to it. Character strings that a
·pre-lexical· transformation blocks in this way
(i.e., they are not in the range of the ·pre-lexical·
facet's transformation) are always dropped from the derived datatype's
·lexical space·.
Note: One should be aware that in the context of XML
schema-validity
assessment,
there are
·pre-lexical· transformations of the
input character string
(controlled by the
whiteSpace facet and any implementation-defined
·pre-lexical·
facets)
which result in the intended
·literal·.
Systems other than
XML schema-validity
assessment
utilizing this specification may or may not implement these
transformations. If they do not, then input character strings
that would have been transformed into correct
·lexical representations·,
when taken "raw", may not be
correct
·lexical
representations·.
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·.
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 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.
[Definition:] An
atomic value is an elementary value, not
constructed from simpler values by any user-accessible
means defined by this specification.
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
·List· datatypes are always ·constructed· from some other type; they are never
·primitive·. The ·value space· of a ·list· datatype is
the set of finite-length sequences of
zero or more
·atomic·
values
where each ·atomic· value is drawn from the ·value space· of the lists's ·item type·
and has a ·lexical representation· containing no
whitespace.
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
·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
whitespace
(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>
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·. Similarly,
enumerated
values are compared to the entire ·list·, not to
individual list items,
and assertions apply to the entire ·list· too.
Lists are identical if and only if they have the
same length and their items are pairwise identical; they are
equal if and only if they have the same length and their items
are pairwise equal. And
a list of length one whose item is an atomic value V1 is
equal or identical
to an atomic value V2
if and only if V1 is
equal or identical
to V2.
<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
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·.
It will be observed that the ·lexical mapping· of a union, so
defined, is not necessarily a function: a given ·literal· may map to
one value or to several values of different ·primitive· datatypes, and
it may be indeterminate which value is to be preferred in a particular
context. When the datatypes defined here are used in the context of
[XSD 1.1 Part 1: Structures], the xsi:type attribute defined by that
specification in section xsi:type can be used to indicate
which value a ·literal· which is the content of an element should map
to. In other contexts, other rules (such as type coercion rules) may
be employed to determine which value is to be used.
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 (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.
The ·transitive membership·
of a ·union· must not contain the ·union· itself, nor
any datatype ·derived· or ·constructed· from the ·union·.
[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· of 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. As noted above,
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).
<xs:element name='size'>
<xs:simpleType>
<xs:union>
<xs:simpleType>
<xs:restriction base='integer'/>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base='string'/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:element>
<size>1</size>
<size>large</size>
<size xsi:type='xs: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.
2.4.2 Special vs. Primitive vs.
Ordinary
Datatypes
Next, we distinguish ·special·,
·primitive·, and ·ordinary·
(or ·constructed·) datatypes.
Each
datatype defined by or in accordance
with this specification falls
into exactly one of these
categories.
Note: As normatively specified elsewhere,
conforming processors
must support all the
primitive datatypes defined in this specification; it is
·implementation-defined· whether other primitive datatypes are
supported.
Processors
may, for example,
support the floating-point decimal datatype specified in
[Precision Decimal].
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.
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 the
standard
·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.
Note: The properties of any
·implementation-defined· ·primitive·
datatypes are given not here but in the documentation for
the implementation in question.
Alternatively, a primitive datatype
not specified in this document can be specified in a document
of its own not tied to a particular implementation;
[Precision Decimal] is an example of such a document.
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.
Every datatype
other than anySimpleType
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,
A datatype
R
is
derived from another
datatype
B if and only if one of the following is true:
There is some datatype
X
such that
X is the
·base type·
of
R, and
X is derived from
B.
A datatype must not be
·derived· from itself. That is, the
base type relation must be acyclic.
It is a consequence of the above
that every datatype other than anySimpleType is
·derived·
from anySimpleType.
Since each datatype has exactly one ·base type·,
and every datatype other
than anySimpleType
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,
A datatype R
is a restriction of another
datatype B when
Note that all three forms of datatype ·construction· produce
·restrictions· of the ·base type·:
·facet-based restriction· does so by means of
·constraining facets·,
while ·construction· by ·list· or ·union· does so because those
·constructions· take
anySimpleType as the ·base type·. It follows that all
datatypes are ·restrictions·
of anySimpleType.
This specification provides no means by which a datatype may be
defined so as to have a larger ·lexical space· or ·value space·
than its ·base type·.
By 'construction' is meant the creation of a
datatype by defining it in terms of another.
[Definition:] All
·ordinary· datatypes are defined in terms of, or
constructed from, other datatypes, either by
·restricting· the
·value space· or ·lexical space·
of a ·base type· using zero or more
·constraining facets·
or by specifying the new datatype as a ·list· of items of some
·item type·,
or by defining it as a ·union· of some specified
sequence of ·member types·.
These three forms of ·construction·
are often called "·facet-based restriction·",
"·construction·
by ·list·", and "·construction· by
·union·", respectively.
Datatypes so constructed may be understood fully (for
purposes of a type system) in terms of (a) the properties
of the datatype(s) from which they are constructed, and
(b) their Simple Type Definition. This distinguishes
·ordinary·
datatypes
from the ·special· and
·primitive· datatypes, which can be understood
only in the light of documentation (namely, their descriptions
elsewhere in this specification,
or, for ·implementation-defined· ·primitives·, in the appropriate
implementation-specific documentation).
All ·ordinary·
datatypes are ·constructed·, and all
·constructed· datatypes are
·ordinary·.
2.4.4 Built-in vs. User-Defined Datatypes
[Definition:]
User-defined datatypes are those
datatypes that are defined by individual schema designers.
The ·built-in· datatypes are intended to be
available automatically whenever this specification is implemented or
used, whether by itself or embedded in a host language. In the
language defined by [XSD 1.1 Part 1: Structures],
the ·built-in· datatypes are automatically
included in every valid schema. Other host languages should specify
that all of the datatypes decribed here as built-ins are automatically
available; they may specify that additional datatypes are also made
available automatically.
Note: ·Implementation-defined· datatypes, whether
·primitive· or
·ordinary·,
may sometimes
be included automatically in any schemas processed
by that implementation; nevertheless, they are not built in
to
every schema, and are thus not included
in the term 'built-in', as that term is
used in this specification.
The mechanism for making ·user-defined·
datatypes available for use is not defined in this specification; if
·user-defined· datatypes are to be available, some such mechanism
must be specified by the host language.
[Definition:] A
datatype which is not available for use is said to be
unknown.
Note: From the schema author's perspective, a reference to
a datatype which proves to be
·unknown· might reflect
any of the following causes, or others:
1
An error has been made in giving the name of the datatype.2
The datatype is a ·user-defined· datatype which has not been made
available using the means defined by the host language (e.g.
because the appropriate schema document has not been
consulted).4
The datatype is an ·implementation-defined· ·ordinary·
datatype which is made automatically available by some
implementations, but not by the implementation being
used.
From the point of view of the implementation, these cases
are likely to be indistinguishable.
Conceptually there is no difference between the ·ordinary·
·built-in·
datatypes included in this specification and the ·user-defined·
datatypes which will be created by individual schema designers.
The ·built-in· ·constructed· 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
·constructed· datatypes in this specification serves to
demonstrate the mechanics and utility of the datatype generation
facilities of this specification.