This is a
The text of this draft is essentially that which appeared in the Last Call version of this specification published 17 February 2006. The WG has not approved any changes since that publication; new versions of the status-quo documents have been generated primarily for technical reasons internal to the editorial document-production system.
For those primarily interested in the changes since version 1.0,
the
The major changes since version 1.0 include:
Support for XML 1.1 has been added. It is now implementation
defined whether datatypes dependent on definitions in
A new primitive decimal type has been defined, which retains information about the precision of the value. This type is aligned with the floating-point decimal types which will be part of the next edition of IEEE 754.
In order to align this specification with those being prepared by
the XSL and XML Query Working Groups, a new datatype named
The conceptual model of the date- and time-related types has been defined more formally.
A more formal treatment of the fundamental facets of the primitive datatypes has been adopted.
More formal definitions of the lexical space of most types have
been provided, with detailed descriptions of the mappings from lexical
representation to value and from value to
Changes since the previous Working Draft include the following:
Explicit definitions are provided for the
The validation rule
The rules governing partial implementations of infinite datatypes have been clarified.
Various changes have been made in order to align the relevant
parts of this specification more closely with the corresponding
sections of
In order to correct an error in
version 1 of this specification and of
An error in the
prose descriptions of the lexical spaces of
The schema for schema documents found in
Comments on this document should be made in
W3C's public installation of Bugzilla, specifying "XML Schema" as the
product. Instructions can be found at
The end of the Last Call review period is 31 March 2006; comments received after that date will be considered if time allows, but no guarantees can be offered.
Although feedback based on any
aspect of this specification is welcome, there are certain aspects of
the design presented herein for which the Working Group is
particularly interested in feedback. These are designated
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced by the
This document was produced under the 5 February 2004 W3C Patent
Policy. The Working Group maintains a
The English version of this specification is the only normative
version. Information about translations of this document is available
at
Whether an SQL-implementation supports leap seconds, and the consequences of such support for date and interval arithmetic, is implementation-defined.Short and sweet.
XMLSchema-datatypes.
Wording accepted without change 2006-01-13.The Working Group has two main goals for this version of W3C XML Schema:
Significant improvements in simplicity of design and clarity
of exposition
Provision of support for versioning of XML languages defined using the XML Schema specification, including the XML transfer syntax for schemas itself.
These goals are slightly in tension with one another -- the following summarizes the Working Group's strategic guidelines for changes between versions 1.0 and 1.1:
Add support for versioning (acknowledging that this
Allow bug fixes (unless in specific cases we decide that the fix is too disruptive for a point release)
Allow editorial changes
Allow design cleanup to change behavior in edge cases
Allow relatively non-disruptive changes to type hierarchy (to better support current and forthcoming international standards and W3C recommendations)
Allow design cleanup to change component structure (changes to functionality restricted to edge cases)
Do not allow any significant changes in functionality
Do not allow any changes to XML transfer syntax except those required by version control hooks and bug fixes
The overall aim as regards compatibility is that
All schema documents conformant to version 1.0 of this specification should also conform to version 1.1, and should have the same validation behavior across 1.0 and 1.1 implementations (except possibly in edge cases and in the details of the resulting PSVI);
The vast majority of schema documents conformant to version 1.1 of this specification should also conform to version 1.0, leaving aside any incompatibilities arising from support for versioning, and when they are conformant to version 1.0 (or are made conformant by the removal of versioning information), should have the same validation behavior across 1.0 and 1.1 implementations (again except possibly in edge cases and in the details of the resulting PSVI);
The
The table below offers two typical examples of XML instances in which datatypes are implicit: the instance on the left represents a billing invoice, the instance on the right a memo or perhaps an email message in XML.
| Data oriented | Document oriented |
|---|---|
|
|
|
The invoice contains several dates and telephone numbers, the postal abbreviation for a state (which comes from an enumerated list of sanctioned values), and a ZIP code (which takes a definable regular form). The memo contains many of the same types of information: a date, telephone number, email address and an "importance" value (from an enumerated list, such as "low", "medium" or "high"). Applications which process invoices and memos need to raise exceptions if something that was supposed to be a date or telephone number does not conform to the rules for valid dates or telephone numbers.
In both cases, validity constraints exist on the content of the instances that are not expressible in XML DTDs. The limited datatyping facilities in XML have prevented validating XML processors from supplying the rigorous type checking required in these situations. The result has been that individual applications writers have had to implement type checking in an ad hoc manner. This specification addresses the need of both document authors and applications writers for a robust, extensible datatype system for XML which could be incorporated into XML processors. As discussed below, these datatypes could be used in other XML-related standards as well.
Other specifications on which this one depends
are listed in
This specification defines some datatypes which depend on
definitions in
Conforming implementations of this specification may provide either
the 1.1-based datatypes or the 1.0-based datatypes, or both. If both
are supported, the choice of which datatypes to use in a particular
assessment episode
When this specification is used to check the datatype validity of XML
input, implementations
The
provide for primitive data typing, including byte, date, integer, sequence, SQL and Java primitive datatypes, etc.;
define a type system that is adequate for import/export from database systems (e.g., relational, object, OLAP);
distinguish requirements relating to lexical data representation vs. those governing an underlying information set;
allow creation of user-defined datatypes, such as datatypes that are derived from existing datatypes and which may constrain certain of its properties (e.g., range, precision, length, format).
This portion of the XML Schema Language discusses datatypes that can
be used in an XML Schema. These datatypes can be specified for
element content that would be specified as
The terminology used to describe XML Schema Datatypes is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of a datatype processor:
A feature of this specification included solely to ensure that schemas
which use this feature remain compatible with
Conforming documents and processors are permitted to but need not behave as described.
(Of strings or names:) Two strings or names being compared must be
identical. Characters with multiple possible representations in
ISO/IEC 10646 (e.g. characters with both precomposed and
base+diacritic forms) match only if they have the same representation
in both strings. No case folding is performed. (Of strings and rules
in the grammar:) A string matches a grammatical production if
Conforming documents and processors are required to behave as
described; otherwise they are in
A violation of the rules of this specification; results are undefined.
Conforming software
This specification provides three different kinds of normative statements about schema components, their representations in XML and their contribution to the schema-validation of information items:
Constraints on the schema components themselves, i.e. conditions
components
Constraints on the representation of schema components in XML.
Some but not all of these are expressed in
Constraints expressed by schema components which information items
This section describes the conceptual framework behind the
The datatypes discussed in this specification are
Only those operations and relations needed for schema processing
are defined in this specification. Applications using these datatypes
are generally expected to implement appropriate additional functions
and/or relations to make the datatype generally useful. For
example, the description herein of the
A A A small collection of
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
Where
The
The value spaces of datatypes are abstractions,
and are defined in
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
The defined enumerated outright defined by restricting the defined as a combination of values from one or more already
defined
The relations of
The identity relation is always defined. Every value space
inherently has an identity relation. Two things are
This does not preclude implementing datatypes by using more than
one
In the identity relation defined herein, values from different
Each
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
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
For example, the
For another example, the
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
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
Each datatype has an order relation prescribed. This order may be
a
In this specification, this less-than order relation is denoted by
The weak order
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
While it is not an error to attempt to compare values from the
value spaces of two different primitive datatypes, they will always be
In addition to its
For example, "100" and "1.0E2" are two different literals from the
The literals in the
The number of literals for each value has been kept small; for many datatypes there is a one-to-one mapping between literals and values. This makes it easy to exchange the values between different systems. In many cases, conversion from locale-dependent representations will be required on both the originator and the recipient side, both for computer processing and for interaction with humans.
Textual, rather than binary, literals are used. This makes hand editing, debugging, and similar activities possible.
Where possible, literals correspond to those found in common programming languages and libraries.
While the datatypes defined in this specification have, for the most
part, a single lexical representation i.e. each value in the
datatype's
Should a derivation be made using a derivation mechanism that
removes
This could happen by means of a
Conversely, should a derivation remove values then their
There are currently no facets with such an impact. There may be in the future.
For example, '100' and '1.0E2' are two
different
While the datatypes defined in this specification generally have a
single
The facets of a datatype serve to distinguish those aspects of
one datatype which
Facets are of two types:
All
Constraining the
All
It is useful to categorize the datatypes defined in this
specification along various dimensions,
The first distinction to be made is that
between
First, we distinguish
For example, a single token which
Several type systems (such as the one described in
A
In the above example, the value of the
When a datatype is derived
For each of
For
The
The
A prototypical example of a
Any number (greater than