3.2 Primitive datatypes
The primitive datatypes defined by this specification
are described below. For each datatype, the
value space and lexical space
are defined, constraining facets which apply
to the datatype are listed and any datatypes derived
from this datatype are specified.
primitive datatypes can only be added by revisions
to this specification.
3.2.2 boolean
[Definition:] boolean has the
value space required to support the mathematical
concept of binary-valued logic: {true, false}.
3.2.2.1 Lexical Representation
An instance of a datatype that is defined as boolean
can have the following legal lexical values {true, false}.
3.2.3 float
[Definition:] float corresponds
to the IEEE single-precision 32-bit floating point type
[IEEE 754-1985]. The basic value space of
float consists of the values
m × 2^e, where m
is an integer whose absolute value is less than
2^24, and e is an integer
between -149 and 104, inclusive. In addition to the basic
value space described above, the
value space of float also contains the
following special values: positive and negative zero,
positive negative infinity and not-a-number.
The order-relation on float
is: x < y iff y - x is positive.
A literal in the lexical space representing a
decimal number d maps to the normalized value
in the value space of float that is
closest to d; if d is
exactly halfway between two such values then the even value is chosen.
This is the best approximation of d[Clinger, WD (1990)][Gay, DM (1990)], which is more
accurate than the mapping required by [IEEE 754-1985].
3.2.3.1 Lexical representation
float values have a lexical representation
consisting of a mantissa followed, optionally, by the character
"E" or "e", followed by an exponent. The exponent must
be an integer. The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and decimal. If the "E" or "e" and
the following exponent are omitted, an exponent value of 0 is assumed.
The special values positive and negative zero, positive
and negative infinity and not-a-number have 0,
-0, INF, -INF and
NaN, respectively.
For example, -1E4, 1267.43233E12, 12.78e-2, 12 and INF
are all legal literals for float.
3.2.3.2 Canonical representation
The canonical representation for float is defined by
prohibiting certain options from the
Lexical representation (§3.2.3.1). Specifically, the preceding optional "+" sign is prohibited from the
mantissa. The exponent must be indicated by "E" and number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point. Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.
3.2.4 double
[Definition:] The double
datatype corresponds to IEEE double-precision 64-bit floating point
type [IEEE 754-1985]. The basic value space
of double consists of the values
m × 2^e, where m
is an integer whose absolute value is less than
2^53, and e is an
integer between -1075 and 970, inclusive. In addition to the basic
value space described above, the
value space of double also contains
the following special values: positive and negative zero,
positive negative infinity and not-a-number.
The order-relation on double
is: x < y iff y - x is positive.
A literal in the lexical space representing a
decimal number d maps to the normalized value
in the value space of double that is
closest to d; if d is
exactly halfway between two such values then the even value is chosen.
This is the best approximation of d
([Clinger, WD (1990)], [Gay, DM (1990)]), which is more
accurate than the mapping required by [IEEE 754-1985].
3.2.4.1 Lexical representation
double values have a lexical representation
consisting of a mantissa followed, optionally, by the character "E" or
"e", followed by an exponent. The exponent must be
an integer. The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and decimal. If the "E" or "e"
and the following exponent are omitted, an exponent value of 0 is assumed.
The special values positive and negative zero, positive
and negative infinity and not-a-number have 0,
-0, INF, -INF and
NaN, respectively.
For example, -1E4, 1267.43233E12, 12.78e-2, 12 and INF
are all legal literals for double.
3.2.4.2 Canonical representation
The canonical representation for double is defined by
prohibiting certain options from the
Lexical representation (§3.2.4.1). Specifically, the preceding optional "+" sign is prohibited from the
mantissa. The exponent must be indicated by "E" and number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point. Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.
3.2.5 decimal
[Definition:] decimal
represents arbitrary precision decimal numbers.
The value space of decimal
is the set of the values i × 10^-n,
where i and n are integers
such that n >= 0.
The order-relation on decimal
is: x < y iff y - x is positive.
[Definition:]
The value space of types derived from decimal
with a value for precision of p
is the set of values i × 10^-n, where
n and i are integers such that
p >= n >= 0 and the number of significant decimal digits
in i is less than or equal to p.
[Definition:]
The value space of types derived from decimal
with a value for scale of s
is the set of values i × 10^-n, where
i and n are integers such
that 0 <= n <= s.
NOTE:
All minimally conforming processors must
support decimal numbers with a minimum of 18 decimal digits (i.e., with a
precision of 18). However,
minimally conforming processors may
set an application-defined limit on the maximum number of decimal digits
they are prepared to support, in which case that application-defined
maximum number must be clearly documented.
Ed. Note: Priority Feedback Request
As in all such cases, the minimum number of decimal digits that all
minimally conforming processors must
support is too small for some applications and, perhaps, too large for
others. We welcome further input from implementors whether the minimum
value of 18 is acceptable.
3.2.5.1 Lexical representation
decimal has a lexical representation
consisting of a finite-length sequence of decimal digits (#x30-#x39) separated
by a period as a decimal indicator, in accordance with the scale and
precision facets, with an optional leading sign. If the sign is
omitted, "+" is assumed. Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example: -1.23, 12678967.543233, +100000.00.
3.2.5.2 Canonical representation
The canonical representation for decimal is defined by
prohibiting certain options from the
Lexical representation (§3.2.5.1). Specifically, the preceding optional "+" sign is prohibited. Leading zeroes are prohibited. Trailing
zeroes to the right of the decimal point are also prohibited.
3.2.5.4 Derived datatypes
The following built-in
datatypes are derived from
decimal:
3.2.6 timeDuration
[Definition:] timeDuration represents a duration of time.
The value space of timeDuration is
a six-dimensional space where the coordinates
designate the Gregorian year, month, day, hour, minute, and second components defined in
§ 5.5.3.2 of [ISO 8601],
respectively. These components are ordered
in their significance by their order of appearance i.e. as year, month, day,
hour, minute, and second.
The order-relation on timeDuration is defined
as follows.
For timeDuration t and starting
timeInstant s, compute an
end timeInstant t[s] whose
components CCYY, MM, DD, etc. are computed by adding to those components of
s the corresponding components of t
and handling the carry-overs correctly. Then, the order-relation
of two timeDuration values x and
y is x > y iff x[s] > y[s]
for any starting instant s, x <
y iff x[s] < y[s] for any s and
x = y iff x[s] = y[s] for any s.
Note that the order-relation on timeDuration
holds for some s but not for all s.
In such cases the the order relation in said to be indeterminate. For example, while P1M25D > P50D and
P1M10D < P50 the order relation between P1M20D and P50D is indeterminate.
Ed. Note: Priority Feedback Request
The complexity of real world durations of time introduces difficulties into
any design that attempts to support them.
The XML Schema Working
Group acknowledges the undesirability of an order-relation
that specifies a partial (as opposed to a total) order; however, it has found
no other solution that garnered consensus. Therefore, the
XML Schema Working Group
welcomes feedback from implementors and schema authors on alternative designs.
Specifically, we are interested in knowing whether timeDuration
needs to be ordered at all and in hearing how other
implemented systems which provide a total order for durations of time have
defined that total order.
3.2.6.1 Lexical representation
The lexical representation for timeDuration is the
[ISO 8601] extended format PnYn
MnDTnH nMnS, where
nY represents the number of years, nM the
number of months, nD the number of days, 'T' is the
date/time separator, nH the number of hours,
nM the number of minutes and nS the
number of seconds. The number of seconds can include decimal digits
to arbitrary precision.
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but
allow an arbitrary integer. Similarly, the value of the Seconds component
allows an arbitrary decimal. Thus, the lexical representation of
timeDuration does not follow the alternative
format of § 5.5.3.2.1 of [ISO 8601].
An optional preceding minus sign ('-') is
allowed, to indicate a negative duration. If the sign is omitted a
positive duration is indicated. See also ISO 8601 Date and Time Formats (§D).
For example, to indicate a duration of 1 year, 2 months, 3 days, 10
hours, and 30 minutes, one would write: P1Y2M3DT10H30M.
One could also indicate a duration of minus 120 days as:
-P120D.
Reduced precision and truncated representations of this format are allowed
provided they conform to the following:
-
The lowest order items may be omitted. If omitted their value is
assumed to be zero.
-
The lowest order item may have a decimal fraction.
-
If the number of years, months, days, hours, minutes, or seconds in any
expression equals zero, the number and its corresponding designator may
be omitted. However, at least one number and its designator must be present.
-
The designator 'T' shall be absent if all of the time items are absent.
The designator 'P' must always be present.
For example, P1347Y, P1347M and P1Y2MT2H are all allowed;
P0Y1347M and P0Y1347M0D are allowed. P-1347M is not allowed although
-P1347M is allowed. P1Y2MT is not allowed.
3.2.7 recurringDuration
[Definition:] recurringDuration represents a specific period of time
that recurs with a specific frequency, starting from a specific point in time.
The value that appears in an instance document is
interpreted as the point in time when the recurrence begins.
The value space of recurringDuration is the
set of sets of timeDurations that recur with a specific
timeDuration starting from a specific timeInstant.
The order-relation on recurringDuration
is: x < y iff y - x is positive where x and y
are starting timeInstants. recurringDurations
which have different values for the duration and
period cannot be compared.
recurringDuration has two constraining facets
duration and period whose values
must be specified when the datatype is defined.
These facets specify the
length of the duration and after what duration it recurs. The lexical
format used to specify these facet values is the lexical format for
timeDuration. A value of 0 for the facet
period means that the duration does not recur i.e.
there is but a single occurrence. A value of 0 for the facet
duration means that the duration is, in fact, a
single instant of time.
recurringDuration is a conceptual datatype which serves as a
base type
from which the other date and time datatypes are derived.
It can also be
used as a base type for user-derived
datatypes. A user-derived datatype
can be derived from recurringDuration by
specifying values for
duration and period.
NOTE:
While recurringDuration is capable of serving as the
base type of datatypes used in many different
date and time related applications beyond those supplied by its use
as the base type of the
built-in datatypes derived
from it, recurringDuration is not intended as a general-purpose
solution to calendaring and scheduling applications.
Ed. Note: Priority Feedback Request
The XML Schema Working
Group is particularly interested in feedback from implementors and
schema authors as to how timeDuration, recurringDuration
and the other date and time related datatypes derived
from recurringDuration interoperate with other date and
time related systems.
| Constraint on Schemas: duration and period required for recurringDuration |
It is an error for recurringDuration
to be used directly in a schema. Only datatypes that are
derived from recurringDuration by
specifying a value for duration and
period can be used in a schema.
|
3.2.7.1 Lexical representation
A single lexical representation, which is a subset of the lexical
representations allowed by [ISO 8601], is allowed for
recurringDuration. This lexical representation is the
[ISO 8601] extended format CCYY-MM-DDThh:mm:ss.sss
where "CC" represents the century, "YY" the year, "MM" the month and
"DD" the day, preceded by an optional leading sign to indicate a
negative number. If the sign is omitted, "+" is assumed. The letter
"T" is the date/time separator and "hh", "mm", "ss.sss" represent hour,
minute and second respectively. Additional digits can be used to
increase the precision of fractional seconds if desired. To accommodate
year values greater than 9999 additional digits can be added to the
left of this representation. The year 0000 is prohibited.
This representation can be immediately followed by a "Z" to indicate
Coordinated Universal Time (UTC). To indicate the time zone, i.e. the
difference between the local time and Coordinated Universal Time,
the difference immediately follows the time and consists of a sign,
+ or -, followed by hh:mm. See also ISO 8601 Date and Time Formats (§D).
The derived datatype timeInstant uses the same lexical
representation. Other derived datatypes date,
time, timePeriod and
recurringDate use truncated versions of this lexical
representation.
3.2.7.2 Canonical representation
The canonical representation for recurringDuration is defined
by prohibiting certain options from the
Lexical representation (§3.2.7.1). Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".
3.2.7.4 Derived datatypes
The following built-in
datatypes are derived from
recurringDuration:
3.2.8 binary
[Definition:] binary represents
arbitrary binary data. The value space of
binary is the set of finite-length sequences of binary
octets.
| Constraint on Schemas: encoding required for binary |
It is an error for binary to be used
directly in a schema. Only datatypes that are derived
from binary by minimally specifying a value for
encoding can be used in a schema.
|
3.2.9 uriReference
[Definition:] uriReference represents a Uniform Resource Identifier (URI)
Reference as defined in Section 4 of [RFC 2396], as amended
by [RFC 2732].
A uriReference can be an absolute uriReference
or a relative uriReference, and may have
an optional fragment identifier.
NOTE:
URI References require certain ASCII characters and all
non-ASCII characters be hex encoded, sometimes called URI-escaping
(see Section 2 of [RFC 2396], as amended by Section
3 of [RFC 2732]). Therefore, schema authors need to
exercise caution in the use of uriReference. Specifically,
schema authors should avoid uriReference in cases where
literals should be allowed to directly contain characters that
[RFC 2396], as amended by [RFC 2732], require
to be hex encoded.
Ed. Note: Priority Feedback Request
There is ongoing discussion about how to
treat URI References that might contain non-ASCII characters.
It is extremely important that all W3C specifications
that deal
with such URI References (at least this specification, [Character Model], [XML 1.0 Recommendation (Second Edition)]
and [XPointer], probably others) be aligned; however, it is not clear
how best to achieve that alignment with this specification.
In addition to the current
design, where both the lexical space and
value space of uriReference
are considered to be hex encoded, there are at least 3 alternative
designs that could be considered: 1) have 2 types, the current
type and another type (not strictly speaking, a URI Reference)
where both the lexical space and
value space where allowed to contain non-ASCII
characters; 2) a single type whose lexical space
is allowed to contain non-ASCII characters, but whose
value space was the set of hex-encoded literals;
3) a single type whose lexical space was hex-encoded,
but whose value space was allowed to contain
non-ASCII characters (i.e., the set of hex-decoded literals).
The XML Schema Working
Group welcomes feedback from implementors and schema authors on
how to further harmonize the effected specifications; in particular,
we seek advice on which of the above alternatives (or some other
alternative not yet considered) is most desirable.
Changes resulting from such further harmonization might result in
additional changes to the XML Schema Language in cases where
uriReference in used (e.g.,
xsi:schemaLocation in [XML Schema Part 1: Structures]).
[Definition:]
An absolute uriReference refers to a resource
in a manner which is independent of the context in which the
uriReference occurs.
[Definition:]
A relative uriReference refers to a resource
by describing the difference within a hierarchy of resources between the
context in which the relative uriReference occurs and
the absolute uriReference of the resource.
3.2.9.1 Lexical representation
The lexical space of uriReference is
the set of strings that match the URI-reference
production in Section 4 of [RFC 2396].
3.3 Derived datatypes
This section gives conceptual definitions for all
built-in derived datatypes
defined by this specification. The XML Representation used to define
derived datatypes (whether
built-in or user-derived) is
given in section XML representation of datatype definitions (§5.1) and the complete
definitions of the built-in
derived datatypes are provided in Appendix
Schema for Datatype Definitions (normative) (§A).
3.3.1 CDATA
[Definition:] CDATA
represents white space normalized strings.
The value space of CDATA is the
set of strings that do not
contain the carriage-return (#xD), line-feed (#xA) nor tab (#x9) characters.
The lexical space of CDATA is the
set of strings that do not
contain the newline (#xD) nor tab (#x9) characters.
The base type of CDATA is string.
3.3.1.2 Derived datatypes
The following built-in
datatypes are derived from
CDATA:
3.3.2 token
[Definition:] token
represents tokenized strings.
The value space of token is the
set of strings that do not
contain the line-feed (#xA) nor tab (#x9) characters, that have no
leading or trailing spaces (#x20) and that have no internal sequences
of two or more spaces.
The lexical space of token is the
set of strings that do not
contain the line-feed (#xA) nor tab (#x9) characters, that have no
leading or trailing spaces (#x20) and that have no internal sequences
of two or more spaces.
The base type of token is CDATA.
3.3.2.2 Derived datatypes
The following built-in
datatypes are derived from
token: