XML Schema 1.1 Part 2: Datatypes -- Review Version

1 Introduction

Issue (RQ-21i):RQ-21 (regex/BNF for all primitive types)
Current plan is that all datatypes defined herein will have EBNF productions at least approximately defining their lexical space, and will include a nonnormative regex derived from the EBNF if a user wishes to copy it directly.

Issue (RQ-24-2i):RQ-24 (systematic facets: canonical representations for all datatypes)
It is not possible for all datatypes to have canonical representations of all values without violating the rules of derivation or adding special-purpose constraining facets which the WG does not deem appropriate. The WG has not yet decided how to deal with datatypes whose lexical and/or canonical mappings are context sensitive.

Issue (RQ-148i):RQ-148 (clarify use of "truncation)
The word will probably be removed.

Issue (RQ-120i):RQ-120 (consistent use of "derived)
"Derivations" other than "derivations by restriction" will be renamed "constructions".

Issue (RQ-24-4i):RQ-24 (systematic facets: assignment of datatype to nodes without components)

1.1 Introduction to Version 1.1

The Working Group has two main goals for this version of W3C XML Schema:

Significant improvements in simplicity of design and clarity of exposition without loss of backward or forward compatibility;
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 may be slightly disruptive to the XML transfer syntax at the margins)
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 behaviour 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 behaviour across 1.0 and 1.1 implementations (again except possibly in edge cases and in the details of the resulting PSVI);

The [XML] specification defines limited facilities for applying datatypes to document content in that documents may contain or refer to DTDs that assign types to elements and attributes. However, document authors, including authors of traditional documents and those transporting data in XML, often require a higher degree of type checking to ensure robustness in document understanding and data interchange.

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
<invoice> <orderDate>1999-01-21</orderDate> <shipDate>1999-01-25</shipDate> <billingAddress> <name>Ashok Malhotra</name> <street>123 Microsoft Ave.</street> <city>Hawthorne</city> <state>NY</state> <zip>10532-0000</zip> </billingAddress> <voice>555-1234</voice> <fax>555-4321</fax> </invoice>	<memo importance='high' date='1999-03-23'> <from>Paul V. Biron</from> <to>Ashok Malhotra</to> <subject>Latest draft</subject> <body> We need to discuss the latest draft <emph>immediately</emph>. Either email me at <email> mailto:paul.v.biron@kp.org</email> or call <phone>555-9876</phone> </body> </memo>

Data oriented

Document oriented

<invoice>
  <orderDate>1999-01-21</orderDate>
  <shipDate>1999-01-25</shipDate>
  <billingAddress>
   <name>Ashok Malhotra</name>
   <street>123 Microsoft Ave.</street>
   <city>Hawthorne</city>
   <state>NY</state>
   <zip>10532-0000</zip>
  </billingAddress>
  <voice>555-1234</voice>
  <fax>555-4321</fax>
</invoice>

<memo importance='high'
      date='1999-03-23'>
  <from>Paul V. Biron</from>
  <to>Ashok Malhotra</to>
  <subject>Latest draft</subject>
  <body>
    We need to discuss the latest
    draft <emph>immediately</emph>.
    Either email me at <email>
    mailto:paul.v.biron@kp.org</email>
    or call <phone>555-9876</phone>
  </body>
</memo>

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.

1.3 Requirements

The [XML Schema Requirements] document spells out concrete requirements to be fulfilled by this specification, which state that the XML Schema Language must:

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).

1.4 Scope

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 #PCDATA and attribute values of various types in a DTD. It is the intention of this specification that it be usable outside of the context of XML Schemas for a wide range of other XML-related activities such as [XSL] and [RDF Schema].

1.5 Terminology

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:

[Definition:] for compatibility

A feature of this specification included solely to ensure that schemas which use this feature remain compatible with [XML]

[Definition:] may

Conforming documents and processors are permitted to but need not behave as described.

[Definition:] match

(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 ↑and only if↑ it belongs to the language generated by that production.

[Definition:] must

Conforming documents and processors are required to behave as described; otherwise they are in ·error·.

[Definition:] error

A violation of the rules of this specification; results are undefined. Conforming software ·may· detect and report an error and ·may· recover from it.

1.6 Constraints and Contributions

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:

[Definition:] Constraint on Schemas

Constraints on the schema components themselves, i.e. conditions components ·must· satisfy to be components at all. Largely to be found in Datatype components (§4).

[Definition:] Schema Representation Constraint

Constraints on the representation of schema components in XML. Some but not all of these are expressed in Schema for Datatype Definitions (normative) (§A) and DTD for Datatype Definitions (non-normative) (§B).

[Definition:] Validation Rule

Constraints expressed by schema components which information items ·must· satisfy to be schema-valid. Largely to be found in Datatype components (§4).

2 ↓Type↓↑Datatype↑ System

This section describes the conceptual framework behind the ↑data↑type 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 ↓computer representations of↓↑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.↑

↑

Note: 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 float datatype does not define addition or multiplication, much less all of the operations defined for that datatype in [IEEE 754-1985] on which it is based.

↑

2.1 Datatype

↓

[Definition:] In this specification, a datatype is a 3-tuple, consisting of a) a set of distinct values, called its ·value space·, b) a set of lexical representations, called its ·lexical space·, and c) a set of ·facet·s that characterize properties of the ·value space·, individual values or lexical items.

↓

↑

[Definition:] In this specification, a datatype has three properties:

A ·value space·, which is a set of values.
A ·lexical space·, which is a set of character strings used to denote the values.
A small collection of functions, relations, and procedures associated with the datatype. Included are equality and order relations on the ·value space·, and a ·lexical mapping·, which is a function on the ·lexical space· onto the ·value space·.

↑

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.

2.2 Value space

        2.2.1 Identity
        2.2.2 Equality
        2.2.3 Order

↓

[Definition:] A value space is the set of values for a given datatype. Each value in the value space of a datatype is denoted by one or more literals in its ·lexical 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 ↓given ↓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·]

↓

·value space·s have certain properties. For example, they always have the property of ·cardinality·, some definition of equality and might be ·ordered·, by which individual values within the ·value space· can be compared to one another. The properties of ·value space·s that are recognized by this specification are defined in Fundamental facets (§2.5.1).

↓

↑

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 and only 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 ·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.

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

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·. [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 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.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 pDecimal 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 Lexical space

In addition to its ·value space·, each datatype also has a lexical space.

[Definition:] A lexical space is the set of valid literals for a datatype.

For example, "100" and "1.0E2" are two different literals from the ·lexical space· of float which both denote the same value. The type system defined in this specification provides a mechanism for schema designers to control the set of values and the corresponding set of acceptable literals of those values for a datatype.

Note: The literals in the ·lexical space·s defined in this specification have the following characteristics:

Interoperability:

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.

Basic readability:

Textual, rather than binary, literals are used. This makes hand editing, debugging, and similar activities possible.

Ease of parsing and serializing:

Where possible, literals correspond to those found in common programming languages and libraries.

2.3.1 Canonical Lexical Representation

While the datatypes defined in this specification have, for the most part, a single lexical representation i.e. each value in the datatype's ·value space· is denoted by a single literal in its ·lexical space·, this is not always the case. The example in the previous section showed two literals for the datatype float which denote the same value. Similarly, there ·may· be several literals for one of the date or time datatypes that denote the same value using different timezone indicators.

[Definition:] A canonical lexical representation is a set of literals from among the valid set of literals for a datatype such that there is a one-to-one mapping between literals in the canonical lexical representation and values in the ·value space·.

↓

↑

2.4 The Lexical Space and Lexical Mapping

[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.1 Canonical Mapping

Issue (RQ-129i):RQ-129 (remove dependency on canonical representations)
The dependencies are in Part 1; they will be resolved there. Text in this Part will reflect that canonical representation are provided for the benefit of other users, including other specifications that might want to reference these datatypes.

Issue (RQ-126i):RQ-126 (restricting away canonical representations)
Given the "pattern" constraining facet, restricting away canonical representations cannot be prohibited without undue processing expense. A warning will be inserted, and RQ-129 will insure that loss of canonical representations will not affect schema processing.

While the datatypes defined in this specification generally have a single ·lexical representation· for each value (i.e., each value in the datatype's ·value space· is denoted by a single ·representation· in its ·lexical space·), this is not always the case. The example in the previous section shows two ·lexical representations· from the float datatype which denote the same value.

[Definition:] The canonical mapping is a prescribed subset of the inverse of a ·lexical mapping· which is one-to-one and whose domain (where possible) is the entire range of the ·lexical mapping· (the ·value space·). Thus a ·canonical mapping· selects one ·lexical representation· for each value in the ·value space·.

[Definition:] The canonical representation of a value in the ·value space· of a datatype is the ·lexical representation· associated with that value by the datatype's ·canonical mapping·.

·Canonical mappings· are not available for datatypes whose ·lexical mappings· are context dependent (i.e., mappings for which the value of a ·lexical representation· depends on the context in which it occurs, or for which a character string may or may not be a valid ·lexical representation· similarly depending on its context)

Note: ·Canonical representations· are provided where feasible for the use of other appilications; they are not required for schema processing itself. A conforming schema processor implementation is not required to implement ·canonical mappings·.

↑

↓

2.5 Facets

Fundamental facets
2.5.2 Constraining or Non-fundamental facets

Issue (del-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:] A facet is a single defining aspect of a ·value space·. Generally speaking, each facet characterizes a ·value space· along independent axes or dimensions.

The facets of a datatype serve to distinguish those aspects of one datatype which differ from other datatypes. Rather than being defined solely in terms of a prose description the datatypes in this specification are defined in terms of the synthesis of facet values which together determine the ·value space· and properties of the datatype.

Facets are of two types: fundamental facets that define the datatype and non-fundamental or constraining facets that constrain the permitted values of a datatype.

2.5.1 Fundamental facets

[Definition:] A fundamental facet is an abstract property which serves to semantically characterize the values in a ·value space·.

All fundamental facets are fully described in Fundamental Facets (§4.3).

2.5.2 Constraining or Non-fundamental facets

[Definition:] A constraining facet is an optional property that can be applied to a datatype to constrain its ·value space·.

Constraining the ·value space· consequently constrains the ·lexical space·. Adding ·constraining facet·s to a ·base type· is described in Derivation by restriction (§4.1.2.1).

All constraining facets are fully described in Constraining Facets (§4.4).

↓

2.6 Datatype dichotomies

        2.6.1 Atomic vs. list vs. union datatypes
        2.6.2 Primitive vs. ↓derived datatypes↓↑Constructed Datatypes↑
        2.6.3 Built-in vs. user-derived datatypes

It is useful to categorize the datatypes defined in this specification along various dimensions, forming a set of characterization dichotomies.

2.6.1 Atomic vs. list vs. union datatypes

The first distinction to be made is that between ·atomic·, ·list· and ·union· datatypes.

[Definition:] Atomic datatypes are those having values which are regarded by this specification as being indivisible.↑ Atomic datatypes are anyAtomicType and all datatypes derived from it.↑
[Definition:] List datatypes are those having values each of which consists of a finite-length (possibly empty) sequence of values of an ·atomic· datatype.
[Definition:] Union datatypes are those whose ·value space·s and ·lexical space·s are the union of the ·value space·s and ·lexical space·s of one or more other datatypes.

For example, a single token which ·matches· 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. ↓ ↑An ·atomic· datatype has a ·value space· consisting of a set of "atomic" values which for 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. ↑There is one "special" atomic type (anyAtomicType) and a number of ·primitive· atomic types, which have anyAtomicType as their base type. All other atomic types are derived by restriction either from one of the primitive atomic types or from another ordinary atomic type. No user-defined type may have anyAtomicType as its base type.↑

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.

Example

<simpleType name='sizes'>
  <list itemType='decimal'/>
</simpleType>

<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>

A ·list· datatype can be ·derived· from an ↑ordinary ↑·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.

Example

<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>

In the above example, the value of the someElement element is not a ·list· of ·length· 3; rather, it is a ·list· of ·length· 18.

When a datatype is ·derived· from a ·list· datatype, the following ·constraining facet·s apply:

·length·
·maxLength·
·minLength·
·enumeration·
·pattern·
·whiteSpace·

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·.

Example

<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.

Example

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 ↑ordinary ↑·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.

Example

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.6.2 Primitive vs. ↓derived datatypes↓↑Constructed Datatypes↑

Next, we distinguish between ·primitive·↑, ·constructed·,↑ and ·derived· datatypes.

[Definition:] Primitive datatypes are those that are not defined in terms of other datatypes; they exist ab initio.
↓
[Definition:] Derived datatypes are those that are defined in terms of other datatypes.
↓
↑
[Definition:] Constructed datatypes are those that are defined in terms of other datatypes.
↑

For example, in this specification, float is a well-defined mathematical concept that cannot be defined in terms of other datatypes, while a integer is a special case of the more general datatype decimal.

↓

Issue (diff-RQ-141i):

RQ-141 (add abstract anyAtomicType) RQ-24 (systematic facets: status and value space of anySimpleType)

A new special datatype will be introduced as a child of anySimpleType and the base type of all primitive atomic datatypes.

Resolution:

None recorded.

↓

[Definition:] The ↓simple ur-type definition↓↑definition of anySimpleType↑ is a special restriction of ↓the ur-type definition whose name is anySimpleType in the XML Schema namespace↓↑anyType↑. ↓anySimpleType can be considered as the ·base type· of all ·primitive· datatypes.↓ anySimpleType is considered to have an unconstrained lexical space and a ·value space· consisting of the union of the ·value space·s of all the ·primitive· datatypes and the set of all lists of all members of the ·value space·s of all the ·primitive· datatypes.

The datatypes defined by this specification fall into both the ·primitive· and ·derived· categories. It is felt that a judiciously chosen set of ·primitive· datatypes will serve the widest possible audience by providing a set of convenient datatypes that can be used as is, as well as providing a rich enough base from which the variety of datatypes needed by schema designers can be ·derived·.

In the example above, integer is ·derived· from decimal.

Note: A datatype which is ·primitive· in this specification need not be a "primitive" datatype in any programming language used to implement this specification. Likewise, a datatype which is ·derived· in this specification need not be a "derived" datatype in any programming language used to implement this specification.

As described in more detail in XML Representation of Simple Type Definition Schema Components (§4.1.2), each ·user-derived· datatype ·must· be defined in terms of another datatype in one of three ways: 1) by assigning ·constraining facet·s which serve to restrict the ·value space· of the ·user-derived· datatype to a subset of that of the ·base type·; 2) by creating a ·list· datatype whose ·value space· consists of finite-length sequences of values of its ·itemType·; or 3) by creating a ·union· datatype whose ·value space· consists of the union of the ·value space·s of its ·memberTypes·.

2.6.2.1 Derived by restriction

[Definition:] A datatype is said to be ·derived· by restriction from another datatype when values for zero or more ·constraining facet·s are specified that serve to constrain its ·value space· and/or its ·lexical space· to a subset of those of its ·base type·.

[Definition:] Every datatype that is ·derived· by ·restriction· is defined in terms of an existing datatype, referred to as its base type. base types can be either ·primitive· or ·derived·.

2.6.2.2 Derived by list

A ·list· datatype can be ·derived· from another datatype (its ·itemType·) by creating a ·value space· that consists of a finite-length sequence of values of its ·itemType·.

2.6.2.3 Derived by union

One datatype can be ·derived· from one or more datatypes by ·union·ing their ·value space·s and, consequently, their ·lexical space·s.

2.6.3 Built-in vs. user-derived datatypes

[Definition:] Built-in datatypes are those which are defined in this specification, and can be either ·primitive· or ·derived·;
[Definition:] User-derived datatypes are those ·derived· datatypes that are defined by individual schema designers.

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.

3 Built-in datatypes

Each built-in datatype in this specification (both ·primitive· and ·derived·) can be uniquely addressed via a URI Reference constructed as follows:

the base URI is the URI of the XML Schema namespace
the fragment identifier is the name of the datatype

For example, to address the int datatype, the URI is:

http://www.w3.org/2001/XMLSchema#int

Additionally, each facet definition element can be uniquely addressed via a URI constructed as follows:

the base URI is the U

XML Schema 1.1 Part 2: Datatypes

W3C Working Draft 24 February 2005

Abstract

Status of this Document

Table of Contents

Appendices

1 Introduction

1.1 Introduction to Version 1.1

1.2 Purpose

1.3 Requirements

1.4 Scope

1.5 Terminology

1.6 Constraints and Contributions

2 ↓Type↓↑Datatype↑ System

2.1 Datatype

2.2 Value space

2.2.1 Identity

2.2.2 Equality

2.2.3 Order

2.3 Lexical space

2.3.1 Canonical Lexical Representation

2.4 The Lexical Space and Lexical Mapping

2.4.1 Canonical Mapping

2.5 Facets

2.5.1 Fundamental facets

2.5.2 Constraining or Non-fundamental facets

2.6 Datatype dichotomies

2.6.1 Atomic vs. list vs. union datatypes

2.6.1.1 Atomic datatypes

2.6.1.2 List datatypes

2.6.1.3 Union datatypes

2.6.2 Primitive vs. ↓derived datatypes↓↑Constructed Datatypes↑

2.6.2.1 Derived by restriction

2.6.2.2 Derived by list

2.6.2.3 Derived by union

2.6.3 Built-in vs. user-derived datatypes

3 Built-in datatypes