W3C

XML Schema 1.1 Part 2: Datatypes

W3C Working Draft 17 February 2006

This version:
http://www.w3.org/TR/2006/WD-xmlschema11-2-20060217/
Latest version:
http://www.w3.org/TR/xmlschema11-2/
Previous versions:
http://www.w3.org/TR/2006/WD-xmlschema11-2-20060116/ http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/ http://www.w3.org/TR/2004/WD-xmlschema11-2-20040716/
Editors:
David Peterson, invited expert (SGMLWorks!) <davep@iit.edu>
Paul V. Biron, Kaiser Permanente, for Health Level Seven <Paul.V.Biron@kp.org>
Ashok Malhotra, Oracle Corporation <ashokmalhotra@alum.mit.edu>
C. M. Sperberg-McQueen, World Wide Web Consortium <cmsmcq@w3.org>

This document is also available in these non-normative formats: XML, XHTML with changes since version 1.0 marked, XHTML with changes since previous Working Draft marked, Independent copy of the schema for schema documents, A schema for built-in datatypes only, in a separate namespace, Independent copy of the DTD for schema documents, and List of translations.


Abstract

XML Schema: Datatypes is part 2 of the specification of the XML Schema language. It defines facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML 1.0, provides a superset of the capabilities found in XML 1.0 document type definitions (DTDs) for specifying datatypes on elements and attributes.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Last Call Public Working Draft of XML Schema 1.1: Datatypes. It is here made available for review by W3C members and the public. It is intended to give an indication of the W3C XML Schema Working Group's intentions for this new version of the XML Schema language and our progress in achieving them. It attempts to be complete in indicating what will change from version 1.0, but does not specify in all cases how things will change. This version of this document was created on 17 February 2006.

For those primarily interested in the changes since version 1.0, the Changes since version 1.0 (§H) appendix, which summarizes both changes already made and also those in prospect, with links to the relevant sections of this draft, is the recommended starting point. An accompanying version of this document displays in color all changes to normative text since version 1.0; another shows changes since the previous Working Draft.

The major changes since version 1.0 include:

Changes since the previous Working Draft include the following:

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 http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) Each Bugzilla entry and email message should contain only one comment.

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 'priority feedback' aspects of the design, and identified as such in editorial notes at appropriate points in this draft.

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 W3C XML Schema Working Group as part of the W3C XML Activity. The goals of the XML Schema language version 1.1 are discussed in the Requirements for XML Schema 1.1 document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures made in connection with this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification must disclose the information in accordance with section 6 of the W3C Patent Policy.

The English version of this specification is the only normative version. Information about translations of this document is available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.

The presentation of this document has been augmented to identify changes from a previous version, controlled by dg-statusquo-color-200601.xml, which shows differences from the Working Draft of January 2006. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.


Table of Contents

1 Introduction
    1.1 Introduction to Version 1.1
    1.2 Purpose
    1.3 Dependencies on Other Specifications
    1.4 Requirements
    1.5 Scope
    1.6 Terminology
    1.7 Constraints and Contributions
2 Datatype System
    2.1 Datatype
    2.2 Value space
    2.3 The Lexical Space and Lexical Mapping
    2.4 Datatype Distinctions
3 Built-in Datatypes and Their Definitions
    3.1 Namespace considerations
    3.2 Special Built-in Datatypes
anySimpleType · anyAtomicType
    3.3 Primitive Datatypes
string · boolean · decimal · precisionDecimal · float · double · duration · dateTime · time · date · gYearMonth · gYear · gMonthDay · gDay · gMonth · hexBinary · base64Binary · anyURI · QName · NOTATION
    3.4 Other Built-in Datatypes
normalizedString · token · language · NMTOKEN · NMTOKENS · Name · NCName · ID · IDREF · IDREFS · ENTITY · ENTITIES · integer · nonPositiveInteger · negativeInteger · long · int · short · byte · nonNegativeInteger · unsignedLong · unsignedInt · unsignedShort · unsignedByte · positiveInteger · yearMonthDuration · dayTimeDuration
4 Datatype components
    4.1 Simple Type Definition
    4.2 Fundamental Facets
    4.3 Constraining Facets
5 Conformance
    5.1 Partial Implementation of Infinite Datatypes

Appendices

A Schema for Schema Documents (Datatypes) (normative)
B DTD for Datatype Definitions (non-normative)
C Illustrative XML representations for the built-in simple type definitions
    C.1 Illustrative XML representations for the built-in primitive type definitions
    C.2 Illustrative XML representations for the built-in ordinary type definitions
D Built-up Value Spaces
    D.1 Numerical Values
    D.2 Date/time Values
E Function Definitions
    E.1 Generic Number-related Functions
    E.2 Duration-related Definitions
    E.3 Date/time-related Definitions
    E.4 Lexical and Canonical Mappings for Other Datatypes
F Datatypes and Facets
    F.1 Fundamental Facets
G Regular Expressions
    G.1 Character Classes
H Changes since version 1.0
    H.1 Datatypes, and Facets and Related Rewrites
    H.2 Numerical Datatypes
    H.3 Date/time Datatypes
    H.4 Other changes
I Glossary (non-normative)
J References
    J.1 Normative
    J.2 Non-normative
K Acknowledgements (non-normative)

1 Introduction

next sub-section1.1 Introduction to Version 1.1

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

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:

  1. Add support for versioning (acknowledging that this may be slightly disruptive to the XML transfer syntax at the margins)
  2. Allow bug fixes (unless in specific cases we decide that the fix is too disruptive for a point release)
  3. Allow editorial changes
  4. Allow design cleanup to change behavior in edge cases
  5. Allow relatively non-disruptive changes to type hierarchy (to better support current and forthcoming international standards and W3C recommendations)
  6. Allow design cleanup to change component structure (changes to functionality restricted to edge cases)
  7. Do not allow any significant changes in functionality
  8. 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

previous sub-section next sub-section1.2 Purpose

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

previous sub-section next sub-section1.3 Dependencies on Other Specifications

Other specifications on which this one depends are listed in References (§J).

This specification defines some datatypes which depend on definitions in [XML] and [Namespaces in XML]; those definitions, and therefore the datatypes based on them, vary between version 1.0 ([XML 1.0], [Namespaces in XML 1.0]) and version 1.1 ([XML], [Namespaces in XML]) of those specifications. In any given use of this specification, the choice of the 1.0 or the 1.1 definition of those datatypes is implementation-defined.

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 should be under user control.

Note:  When this specification is used to check the datatype validity of XML input, implementations may provide the heuristic of using the 1.1 datatypes if the input is labeled as XML 1.1, and using the 1.0 datatypes if the input is labeled 1.0, but this heuristic should be subject to override by users, to support cases where users wish to accept XML 1.1 input but validate it using the 1.0 datatypes, or accept XML 1.0 input and validate it using the 1.1 datatypes.

previous sub-section next sub-section1.4 Requirements

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

  1. provide for primitive data typing, including byte, date, integer, sequence, SQL and Java primitive datatypes, etc.;
  2. define a type system that is adequate for import/export from database systems (e.g., relational, object, OLAP);
  3. distinguish requirements relating to lexical data representation vs. those governing an underlying information set;
  4. 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).

previous sub-section next sub-section1.5 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].

previous sub-section next sub-section1.6 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]
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 and only if it belongs to the language generated by that production.
Conforming documents and processors are required to behave as described; otherwise they are in ·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.

previous sub-section 1.7 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 Schema Documents (Datatypes) (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 Datatype System

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.

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. For some datatypes (e.g. language or anyURI) defined in part by reference to other specifications which impose constraints not part of the datatypes as defined here, applications may also wish to check that values conform to the requirements given in the current version of the relevant external specification.

next sub-section2.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:  Where ·canonical mappings· are defined in this specification, they are defined for ·primitive· datatypes. When a datatype is derived using facets which directly constrain the ·value space·, then for each value eliminated from the ·value space·, the corresponding lexical representations are dropped from the lexical space. The ·canonical mapping· for such a datatype is a subset of the ·canonical mapping· for its ·primitive· type and provides a ·canonical representation· for each value remaining in the ·value space·.

The ·pattern· facet, on the other hand, restricts the ·lexical space· directly. When more than one lexical representation is provided for a given value, the ·pattern· facet may remove the ·canonical representation· while permitting a different lexical representation; in this case, the value remains in the ·value space· but has no ·canonical representation·. This specification provides no recourse in such situations. Applications are free to deal with it as they see fit.

previous sub-section next sub-section2.2 Value space

        2.2.1 Identity
        2.2.2 Equality
        2.2.3 Order

[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 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, 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 ·facet-based restrictions· by enumeration, when checking identity constraints, and when checking value 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.  The ·literals· '0.1' and '0.10000000009' map to the same value in float (neither is in the value space, and each is mapped to the nearest value, namely 0.100000001490116119384765625), but map to distinct values in decimal.

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 <> NaN in the precisionDecimal, float, and double datatypes.

The equality relation is used in conjunction with order when making ·facet-based 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 ·facet-based 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.3.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 precisionDecimal 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 always 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 ).

previous sub-section next sub-section2.3 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.

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

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.3.1 Canonical Mapping

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 applications; they are not required for schema processing itself.  A conforming schema processor implementation is not required to implement ·canonical mappings·.

previous sub-section 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.

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.1 Atomic Datatypes

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· datatype (anyAtomicType), and a number of ·primitive· ·atomic· datatypes which have anyAtomicType as their ·base type·.  All other ·atomic· datatypes are derived either from one of the ·primitive· ·atomic· datatypes or from another ·ordinary· ·atomic· datatype.  No ·user-defined· datatype may have anyAtomicType as its ·base type·.

2.4.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 ·constructed· from some other type; they are never ·primitive·. 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· 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 ·member types··basic members· must be ·atomic·.

Example
<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 space (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.

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 by ·restricting· a ·list· datatype, the following ·constraining facets· apply:

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

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

The ·value space· and ·lexical space· of a ·union· datatype are the union of the ·value spaces· and ·lexical spaces· of its ·member types·.↓ 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·. 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.

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 0) of ordinary or ·primitive· ·atomic· or ·list· ·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.

[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· if 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.  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.4.13), the second and third as string (§3.3.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 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.

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.4.2 Special vs. Primitive vs. Ordinary Datatypes

Next, we distinguish ·special·, ·primitive·, and ·ordinary· (or ·constructed·) datatypes.

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.

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

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 ·constructed· in this specification from some other datatype need not be a "derived" datatype in any programming language used to implement this specification.
2.4.2.1 Facet-based Restriction

[Definition:]  A datatype is defined by facet-based restriction of another datatype (its ·base type·), when values for zero or more ·constraining facets· are specified that serve to constrain its ·value space· and/or its ·lexical space· to a subset of those of the ·base type·. The ·base type· of a ·facet-based restriction· must be a ·primitive· or ·ordinary· datatype.

2.4.2.2 Construction by List

A ·list· datatype can be ·constructed· from another datatype (its ·item type·) by creating a ·value space· that consists of a finite-length sequence of values of its ·item type·. Datatypes so ·constructed· have anySimpleType as their ·base type·. Note that since the ·value space· and ·lexical space· of any ·list· datatype are necessarily subsets of the ·value space· and ·lexical space· of anySimpleType, any datatype ·constructed· as a ·list· is a ·restriction· of its base type.

2.4.2.3 Construction by Union

One datatype can be ·constructed· from one or more datatypes by unioning their ·value spaces··lexical mappings· and, consequently, their ·value spaces· and ·lexical spaces·.  Datatypes so ·constructed· also have anySimpleType as their ·base type·. Note that since the ·value space· and ·lexical space· of any ·union· datatype are necessarily subsets of the ·value space· and ·lexical space· of anySimpleType, any datatype ·constructed· as a ·union· is a ·restriction· of its base type.

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

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.

[Definition:]  Every datatype 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, [Definition:]  A datatype R is derived from another datatype B if and only if one of the following is true:

It is a consequence of these definitions that every datatype other than anySimpleType is derived from anySimpleType.

Since each datatype has exactly one ·base type·, and every datatype 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, [Definition:]  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). All ·ordinary· datatypes are ·constructed·, and all ·constructed· datatypes are ·ordinary·.

2.4.4 Built-in vs. User-Defined Datatypes

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.

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-defined· in this specification need not be a user-defined datatype in any programming language used to implement this specification.

3 Built-in Datatypes and Their Definitions

Built-in Datatype Hierarchy diagramanyType anyType anySimpleType anySimpleType string string precisionDecimal precisionDecimal hexBinary hexBinary anyAtomicType anyAtomicType ENTITY ENTITY ENTITIES ENTITIES ID ID IDREFS IDREFS IDREF IDREF Name Name NCName NCName NMTOKEN NMTOKEN NMTOKENS NMTOKENS language language token token normalizedString normalizedString float float double double unsignedByte unsignedByte unsignedShort unsignedShort unsignedInt unsignedInt unsignedLong unsignedLong positiveInteger positiveInteger byte byte short short int int negativeInteger negativeInteger nonPositiveInteger nonPositiveInteger long long nonNegativeInteger nonNegativeInteger integer integer decimal decimal gMonth gMonth gDay gDay gMonthDay gMonthDay gYear gYear gYearMonth gYearMonth date date time time dateTime dateTime duration duration NOTATION NOTATION QName QName anyURI anyURI base64Binary base64Binary boolean boolean

Each built-in datatype in this specification can be uniquely addressed via a URI Reference constructed as follows:

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

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

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

  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of the facet

For example, to address the maxInclusive facet, the URI is:

Additionally, each facet usage in a built-in Simple Type Definition can be uniquely addressed via a URI constructed as follows:

  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of the Simple Type Definition, followed by a period ('.') followed by the name of the facet

For example, to address the usage of the maxInclusive facet in the definition of int, the URI is:

next sub-section3.1 Namespace considerations

The ·built-in· datatypes defined by this specification are designed to be used with the XML Schema definition language as well as other XML specifications. To facilitate usage within the XML Schema definition language, the ·built-in· datatypes in this specification have the namespace name:

  • http://www.w3.org/2001/XMLSchema

To facilitate usage in specifications other than the XML Schema definition language, such as those that do not want to know anything about aspects of the XML Schema definition language other than the datatypes, each non-·special· ·built-in· datatype is also defined in the namespace whose URI is:

  • http://www.w3.org/2001/XMLSchema-datatypes

This applies to all ·built-in· datatypes, whether ·special·, ·primitive·, or ·ordinary·.

Note: The use of the XMLSchema-datatypes namespace and the definitions therein are deprecated as of XML Schema 1.1.

Each ·user-defined· datatype is also associated with a unique namespace.  However, ·user-defined· datatypes do not come from the namespace defined by this specification; rather, they come from the namespace of the schema in which they are defined (see XML Representation of Schemas in [XML Schema Part 1: Structures]).

previous sub-section next sub-section3.2 Special Built-in Datatypes

The two datatypes at the root of the hierarchy of simple types are anySimpleType and anyAtomicType.

3.2.1 anySimpleType

[Definition:]   The definition of anySimpleType is a special ·restriction· of anyTypeanySimpleType has an unconstrained ·lexical space·, a ·value space· consisting of the union of the ·value spaces· of all the ·primitive· datatypes and the set of all lists of all members of the ·value spaces· of all the ·primitive· datatypes.

For further details of anySimpleType and its representation as a Simple Type Definition, see Built-in Simple Type Definitions (§4.1.6).

3.2.1.1 Value space

The ·value space· of anySimpleType is the union of the ·value spaces· of all the ·primitive· datatypes defined here, and of all sets of lists formed from the members of the ·primitive· datatypes.

3.2.1.2 Lexical mapping

The ·lexical space· of anySimpleType is the set of all finite-length sequences of characters (as defined in [XML]) that ·match· the Char production from [XML]. This is equivalent to the union of the ·lexical spaces· of all ·primitive· and all possible ·ordinary· datatypes.

It is implementation-defined whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

The ·lexical mapping· of anySimpleType is the union of the ·lexical mappings· of all ·primitive· datatypes and all list datatypes. It will be noted that this mapping is not 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 [XML Schema 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.

3.2.2 anyAtomicType

[Definition:]   anyAtomicType is a special ·restriction· of anySimpleType. The ·value· and ·lexical spaces· of anyAtomicType are the unions of the ·value· and ·lexical spaces· of all the ·primitive· datatypes, and anyAtomicType is their ·base type·.

For further details of anyAtomicType and its representation as a Simple Type Definition, see Built-in Simple Type Definitions (§4.1.6).

3.2.2.1 Value space

The ·value space· of anyAtomicType is the union of the ·value spaces· of all the ·primitive· datatypes defined here.

3.2.2.2 Lexical mapping

The ·lexical space· of anyAtomicType is the set of all finite-length sequences of characters (as defined in [XML]) that ·match· the Char production from [XML]. This is equivalent to the union of the ·lexical spaces· of all ·primitive· datatypes.

It is implementation-defined whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

The ·lexical mapping· of anyAtomicType is the union of the ·lexical mappings· of all ·primitive· datatypes. It will be noted that this mapping is not 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 [XML Schema 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.

previous sub-section next sub-section3.3 Primitive Datatypes

        3.3.1 string
        3.3.2 boolean
        3.3.3 decimal
        3.3.4 precisionDecimal
        3.3.5 float
        3.3.6 double
        3.3.7 duration
        3.3.8 dateTime
        3.3.9 time
        3.3.10 date
        3.3.11 gYearMonth
        3.3.12 gYear
        3.3.13 gMonthDay
        3.3.14 gDay
        3.3.15 gMonth
        3.3.16 hexBinary
        3.3.17 base64Binary
        3.3.18 anyURI
        3.3.19 QName
        3.3.20 NOTATION

The ·primitive· datatypes defined by this specification are described below.  For each datatype, the ·value space· is described; the ·lexical space· is defined using an extended Backus Naur Format grammar (and in most cases also a regular expression using the regular expression language of Regular Expressions (§G)); ·constraining facets· which apply to the datatype are listed; and any datatypes ·constructed· from this datatype are specified.

·Primitive· datatypes can only be added by revisions to this specification.

3.3.1 string

[Definition:]  The string datatype represents character strings in XML.

Note: Many human languages have writing systems that require child elements for control of aspects such as bidirectional formatting or ruby annotation (see [Ruby] and Section 8.2.4 Overriding the bidirectional algorithm: the BDO element of [HTML 4.01]).  Thus, string, as a simple type that can contain only characters but not child elements, is often not suitable for representing text. In such situations, a complex type that allows mixed content should be considered. For more information, see Section 5.5 Any Element, Any Attribute of [XML Schema Language: Part 0 Primer].
3.3.1.1 Value Space

The ·value space· of string is the set of finite-length sequences of characters (as defined in [XML]) that ·match· the Char production from [XML]. A character is an atomic unit of communication; it is not further specified except to note that every character has a corresponding Universal Character Set (UCS) code point, which is an integer.

It is implementation-defined whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

Equality for string is identity. No order is prescribed.

Note: As noted in ordered, the fact that this specification does not specify an order relation for ·string· does not preclude other applications from treating strings as being ordered.
3.3.1.2 Lexical Mapping

The ·lexical space· of string is the set of finite-length sequences of characters (as defined in [XML]) that ·match· the Char production from [XML].

Lexical Space
stringRep ::= Char*  /* (as defined in [XML]) */

It is implementation-defined whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

The ·lexical mapping· for string is ·stringLexicalMap·, and the ·canonical mapping· is ·stringCanonicalMap·; each is a subset of the identity function.

3.3.1.3 Facets

string has the following ·constraining facets·:

string has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from string may also specify values for the following ·constraining facets·:

string has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.2 boolean

[Definition:]  boolean represents the values of two-valued logic.

3.3.2.1 Value Space

boolean has the ·value space· of two-valued logic:  {true, false}.

3.3.2.3 Facets

boolean has the following ·constraining facets·:

boolean and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from boolean may also specify values for the following ·constraining facets·:

boolean has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = finite
  • numeric = false

3.3.3 decimal

[Definition:]  decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· of decimal is the set of numbers that can be obtained by dividing an integer by a non-negative power of ten, i.e., expressible as i / 10n where i and n are integers and n ≥ 0. Precision is not reflected in this value space; the number 2.0 is not distinct from the number 2.00. (The datatype precisionDecimal may be used for values in which precision is significant.) The order relation on decimal is the order relation on real numbers, restricted to this subset.

Note: All ·minimally conforming· processors ·must· support decimal numbers with a minimum of 16 decimal digits (i.e., of 18they must support all values which would be allowed by a Simple Type Definition which set totalDigits to 16).  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.
3.3.3.2 Canonical representation

The ·canonical representation· for decimal is defined by prohibiting certain options from the Lexical Mapping (§3.3.3.1).  Specifically, the preceding optional "+" sign is prohibited.  The decimal point is required.  Leading and trailing zeroes are prohibited subject to the following:  there must be at least one digit to the right and to the left of the decimal point which may be a zero.

The mapping from values to ·canonical representations· is given formally in ·decimalCanonicalMap·.

3.3.3.3 Facets

decimal has the following ·constraining facets·:

decimal and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from decimal may also specify values for the following ·constraining facets·:

decimal has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.3.4 precisionDecimal

[Definition:]  The precisionDecimal datatype represents the numeric value and (arithmetic) precision of decimal numbers which retain precision; it also includes special values for positive and negative infinity and "not a number", and it differentiates between "positive zero" and "negative zero".  The special values are introduced to make the datatype correspond closely to the floating-point decimal datatypes described by the forthcoming revision of IEEE/ANSI 754. This datatype is introduced to provide a variant of decimal that closely corresponds to the floating-point decimal datatypes described by the expected forthcoming revision of IEEE/ANSI 754. Precision of values is retained, and the special values (two zeroes, infinities, and not-a-number) are included.

Precision is sometimes given in absolute, sometimes in relative terms. [Definition:]  The arithmetic precision of a value is expressed in absolute quantitative terms, by indicating how many digits to the right of the decimal point are significant. "5" has an arithmetic precision of 0, and "5.01" an arithmetic precision of 2.

All ·minimally conforming· processors must support all precisionDecimal values in the ·value space· of the otherwise unconstrained derived datatype for which totalDigits is set to sixteen, maxScale to 369, and minScale to −398.

Note: See the conformance note in Partial Implementation of Infinite Datatypes (§5.1), which applies to this datatype.

Editorial Note: Priority Feedback Request

The conformance limits given in the text correspond to those of the decimal64 type defined in the current draft of IEEE 754R, which can be stored in a 64-bit field. The XML Schema Working Group recommends that implementors support limits corresponding to those of the decimal128 type. This entails supporting the values in the value space of the otherwise unconstrained datatype for which totalDigits is set to 34, maxScale to 6176, and minScale to −6111.

Editorial Note: Priority Feedback Request

The XML Schema Working Group requests feedback from implementors and users of XML Schema concerning the minimum and recommended implementation limits for precisionDecimal. If other limits, larger or smaller, would make this datatype more attractive to users or implementors, please let us know.
3.3.4.1 Value Space
a decimal number, positiveInfinity, negativeInfinity or notANumber
an integer or absent; absent if and only if ·numericalValue· is a constant.
positive, negative, or absent; must be positive if ·numericalValue· is positive or positiveInfinity, must be negative if ·numericalValue· is negative or negativeInfinity, must be absent if and only if ·numericalValue· is notANumber
Note: The ·sign· property is redundant except when ·numericalValue· is zero; in other cases, the ·sign· value is fully determined by the ·numericalValue· value.
Note: As explained below, the lexical representation of the precisionDecimal value object whose ·numericalValue· is notANumber is 'NaN'.  Accordingly, in English text we use 'NaN' to refer to that value.  Similarly we use 'INF' and '−INF' to refer to the two value objects whose ·numericalValue· is positiveInfinity and negativeInfinity.  These three value objects are also informally called "not-a-number", "positive infinity", and "negative infinity". The latter two together are called "the infinities".

Equality and order for precisionDecimal are defined as follows:

  • Two numerical precisionDecimal values are ordered (or equal) as their ·numericalValue· values are ordered (or equal).  (This means that two zeroes with different ·sign·s are equal; negative zeroes are not ordered less than positive zeroes.)
  • INF is equal only to itself, and is greater than −INF and all numerical precisionDecimal values.
  • −INF is equal only to itself, and is less than INF and all numerical precisionDecimal values.
  • NaN is incomparable with all values, including itself.

3.3.4.2 Lexical Mapping

precisionDecimal's lexical space is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the character strings 'INF', '+INF', '-INF', and 'NaN'.

The ·lexical mapping· for precisionDecimal is ·precisionDecimalLexicalMap·. The ·canonical mapping· is ·precisionDecimalCanonicalMap·.

3.3.4.3 Facets

precisionDecimal has the following ·constraining facets·:

precisionDecimal and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from precisionDecimal may also specify values for the following ·constraining facets·:

precisionDecimal has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.3.5 float

[Definition:]  The float datatype is the IEEE single-precision 32-bit floating point datatype [IEEE 754-1985] with the minor exception noted below.  Floating point numbers are certain subsets of the rational numbers, and are often used to approximate arbitrary real numbers.

3.3.5.1 Value Space

The ·value space· of float contains the non-zero numbers  m × 2e , where m is an integer whose absolute value is less than 224, and e is an integer between −149 and 104, inclusive.  In addition to these values, the ·value space· of float also contains the following special valuespositiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Note: As explained below, the ·lexical mapping· of the float value notANumber is 'NaN'.  Accordingly, in English text we generally use 'NaN' to refer to that value.  Similarly, we use 'INF' and '−INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '−0' to refer to positiveZero and negativeZero.

Equality and order for float are defined as follows:

  • Equality is identity, except that  0 = −0  (although they are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).

    0 and −0 are thus distinct for purposes of enumerations and identity constraints, but equal for purposes of minimum and maximum values.

  • For the basic values, the order relation on float is the order relation for rational numbers.  INF is greater than all other non-NaN values; −INF is less than all other non-NaN values.  NaN is ·incomparable· with any value in the ·value space· including itself.  0 and −0 are greater than all the negative numbers and less than all the positive numbers.

Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·.  In particular, when NaN is used as a facet value for a bounding facet, since no float values are ·comparable· with it, the result is a ·value space· that is empty.  If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived by an enumeration).
Note: The Schema 1.0 version of this datatype did not differentiate between 0 and −0 and NaN was equal to itself.  The changes were made to make the datatype more closely mirror [IEEE 754-1985].
3.3.5.2 Lexical Mapping

The ·lexical space· of float is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '-INF', and 'NaN'

The floatRep production is equivalent to this regular expression:

(-|+)?(([0-9]+(.[0-9]*)?)|(.[0-9]+))((e|E)(-|+)?[0-9]+)?|-?INF|NaN

The float datatype is designed to implement for schema processing the single-precision floating-point datatype of [IEEE 754-1985].  That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used.  Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, satisfies the requirements of [IEEE 754-1985], and correctly handles the special values (numericalSpecialRep ·literals·), satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·floatLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible—and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping.  The simple rounding algorithm used in ·floatLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

The ·canonical mapping· ·floatCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·.  Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-1985].

3.3.5.3 Facets

float has the following ·constraining facets·:

float and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from float may also specify values for the following ·constraining facets·:

float has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = true
  • cardinality = finite
  • numeric = true

3.3.6 double

[Definition:]  The double datatype is the IEEE double-precision 64-bit floating point datatype [IEEE 754-1985] with the minor exception noted below.  Floating point numbers are certain subsets of the rational numbers, and are often used to approximate arbitrary real numbers.

Note: The only significant differences between float and double are the three defining constants 53 (vs 24), −1074 (vs −149), and 971 (vs 104).
3.3.6.1 Value Space

The ·value space· of double contains the non-zero numbers  m × 2e , where m is an integer whose absolute value is less than 253, and e is an integer between −1074 and 971, inclusive.  In addition to these values, the ·value space· of double also contains the following special valuespositiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.

Note: As explained below, the ·lexical mapping· of the double value notANumber is 'NaN'.  Accordingly, in English text we generally use 'NaN' to refer to that value.  Similarly, we use 'INF' and '−INF' to refer to the two values positiveInfinity and negativeInfinity, and '0' and '−0' to refer to positiveZero and negativeZero.

Equality and order for double are defined as follows:

  • Equality is identity, except that  0 = −0  (although they are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).

    0 and −0 are thus distinct for purposes of enumerations and identity constraints, but equal for purposes of minimum and maximum values.

  • For the basic values, the order relation on double is the order relation for rational numbers.  INF is greater than all other non-NaN values; −INF is less than all other non-NaN values.  NaN is ·incomparable· with any value in the ·value space· including itself.  0 and −0 are greater than all the negative numbers and less than all the positive numbers.

Note: Any value ·incomparable· with the value used for the four bounding facets (·minInclusive·, ·maxInclusive·, ·minExclusive·, and ·maxExclusive·) will be excluded from the resulting restricted ·value space·.  In particular, when NaN is used as a facet value for a bounding facet, since no double values are ·comparable· with it, the result is a ·value space· that is empty.  If any other value is used for a bounding facet, NaN will be excluded from the resulting restricted ·value space·; to add NaN back in requires union with the NaN-only space (which may be derived by an enumeration).
Note: The Schema 1.0 version of this datatype did not differentiate between 0 and −0 and NaN was equal to itself.  The changes were made to make the datatype more closely mirror [IEEE 754-1985].
3.3.6.2 Lexical Mapping

The ·lexical space· of double is the set of all decimal numerals with or without a decimal point, numerals in scientific (exponential) notation, and the ·literals· 'INF', '-INF', and 'NaN'

The doubleRep production is equivalent to this regular expression:

(-|+)?(([0-9]+(.[0-9]*)?)|(.[0-9]+))((e|E)(-|+)?[0-9]+)?|-?INF|NaN

The double datatype is designed to implement for schema processing the double-precision floating-point datatype of [IEEE 754-1985].  That specification does not specify specific ·lexical representations·, but does prescribe requirements on any ·lexical mapping· used.  Any ·lexical mapping· that maps the ·lexical space· just described onto the ·value space·, satisfies the requirements of [IEEE 754-1985], and correctly handles the special values (numericalSpecialRep ·literals·), satisfies the conformance requirements of this specification.

Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·.

The ·lexical mapping· ·doubleLexicalMap· is provided as an example of a simple algorithm that yields a conformant mapping, and that provides the most accurate rounding possible—and is thus useful for insuring inter-implementation reproducibility and inter-implementation round-tripping.  The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [Clinger, WD (1990)].

Note: The Schema 1.0 version of this datatype did not permit rounding algorithms whose results differed from [Clinger, WD (1990)].

The ·canonical mapping· ·doubleCanonicalMap· is provided as an example of a mapping that does not produce unnecessarily long ·canonical representations·.  Other algorithms which do not yield identical results for mapping from float values to character strings are permitted by [IEEE 754-1985].

3.3.6.3 Facets

double has the following ·constraining facets·:

double and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from double may also specify values for the following ·constraining facets·:

double has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = true
  • cardinality = finite
  • numeric = true

3.3.7 duration

Note:

All
·minimally conforming· processors ·must· support year values with a minimum of 4 digits (i.e., YYYY) and a minimum fractional second precision of milliseconds or three decimal digits (i.e. s.sss). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of digits they are prepared to support in these two cases, in which case that application-defined maximum number ·must· be clearly documented.

[Definition:]  duration is a datatype that represents durations of time.  The concept of duration being captured is drawn from those of [ISO 8601], specifically durations without fixed endpoints.  For example, "15 days" (whose most common lexical representation in duration is "'P15D'") is a duration value; "15 days beginning 12 July 1995" and "15 days ending 12 July 1995" are not.  duration can provide addition and subtraction operations between duration values and between duration/dateTime value pairs, and can be the result of subtracting dateTime values.  However, only addition to dateTime is required for XML Schema processing and is defined in the function ·dateTimePlusDuration·.

3.3.7.1 Value Space

Duration values can be modelled as two-property tuples. Each value consists of an integer number of months and a decimal number of seconds. The ·seconds· value must not be negative if the ·months· value is positive and must not be positive if the ·months· is negative.

Properties of duration Values
a precisionDecimal value; must not be negative if ·months· is positive, and must not be positive if ·months· is negative.

duration is partially ordered.  Equality of duration is defined in terms of equality of dateTime; order for duration is defined in terms of the order of dateTime. Specifically, the equality or order of two duration values is determined by adding each duration in the pair to each of the following four dateTime values:

  • 1696-09-01T00:00:00Z
  • 1697-02-01T00:00:00Z
  • 1903-03-01T00:00:00Z
  • 1903-07-01T00:00:00Z

If all four resulting dateTime value pairs are ordered the same way (less than, equal, or greater than), then the original pair of duration values is ordered the same way; otherwise the original pair is ·incomparable·.

Note: These four values are chosen so as to maximize the possible differences in results that could occur, such as the difference when adding P1M and P30D:  1697-02-01T00:00:00Z + P1M < 1697-02-01T00:00:00Z + P30D , but 1903-03-01T00:00:00Z + P1M > 1903-03-01T00:00:00Z + P30D , so that  P1M <> P30D .  If two duration values are ordered the same way when added to each of these four dateTime values, they will retain the same order when added to any other dateTime values.  Therefore, two duration values are incomparable if and only if they can ever result in different orders when added to any dateTime value.

Under the definition just given, two duration values are equal if and only if they are identical.

Note: There are many ways to implement duration, some of which do not base the implementation on the two-component model.  This specification does not prescribe any particular implementation, as long as the visible results are isomorphic to those described herein.
Note: See the conformance notes in Partial Implementation of Infinite Datatypes (§5.1), which apply to this datatype.
3.3.7.2 Lexical Space

The ·lexical representations· of duration are more or less based on the pattern:

PnYnMnDTnHnMnS

More precisely, the ·lexical space· of duration is the set of character strings that satisfy durationLexicalRep as defined by the following productions:

Thus, a durationLexicalRep consists of one or more of a duYearFrag, duMonthFrag, duDayFrag, duHourFrag, duMinuteFrag, and/or duSecondFrag, in order, with letters 'P' and 'T' (and perhaps a '-') where appropriate.

The language accepted by the durationLexicalRep production is the set of strings which satisfy all of the following three regular expressions:

  • The expression '-?P([0-9]+Y)?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?((([0-9]+(.[0-9]*)?)|(.[0-9]+))S)?)?' matches only strings in which the fields occur in the proper order.
  • The expression '.*[YMDHS].*' matches only strings in which at least one field occurs.
  • The expression '.*[^T]' matches only strings in which 'T' is not the final character, so that if 'T' appears, something follows it. The first rule ensures that what follows 'T' will be an hour, minute, or second field.

The intersection of these three regular expressions is equivalent to the following (after removal of the white space inserted here for legibility):

-?P(((([0-9]+Y([0-9]+M)?)|
      (       ([0-9]+M) ) )(([0-9]+D(T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) ))?)|
                            (       (T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) )) ) )?)|
    (                      (([0-9]+D(T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) ))?)|
                            (       (T(([0-9]+H([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)|
                                       (       ([0-9]+M) ([0-9]+(\.[0-9]+)?S)?)|
                                       (                 ([0-9]+(\.[0-9]+)?S) ) )) ) ) ) )

The ·lexical mapping· for duration is ·durationMap·.

·The canonical mapping· for duration is ·durationCanonicalMap·.

3.3.7.3 Facets

duration has the following ·constraining facets·:

duration and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from duration may also specify values for the following ·constraining facets·:

duration has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.8 dateTime

dateTime represents instants of time, optionally marked with a particular timezone.  Values representing the same instant but having different timezones are equal but not identical.

3.3.8.1 Value Space

dateTime uses the date/timeSevenPropertyModel, with no properties except ·timezone· permitted to be absent. The ·timezone· property remains ·optional·.

Note: In version 1.0 of this specification, the ·year· property was not permitted to have the value zero. The year 1 BCE was represented by a ·year· value of −1, 2 BCE by −2, and so forth. In this version of this specification, two changes are made in order to agree with existing usage. First, ·year· is permitted to have the value zero. Second, the interpretation of ·year· values is changed accordingly: a ·year· value of zero represents 1 BCE, −1 represents 2 BCE, etc. This representation simplifies interval arithmetic and leap-year calculation for dates before the common era.

Note that 1 BCE, 5 BCE, and so on (years 0000, -0004, etc. in the lexical representation defined here) are leap years in the proleptic Gregorian calendar used for the date/time datatypes defined here. Version 1.0 of this specification was unclear about the treatment of leap years before the common era; caution should be used if existing schemas or data specify dates of 29 February for any years before the common era. With that possible exception, schemas and data valid under the old interpretation remain valid under the new.

Constraint: Day-of-month Values
The ·day· value must be no more than 30 if ·month· is one of 4, 6, 9, or 11; no more than 28 if ·month· is 2 and ·year· is not divisible 4, or is divisible by 100 but not by 400; and no more than 29 if ·month· is 2 and ·year· is divisible by 400, or by 4 but not by 100.
Note: See the conformance note in (§3.3.7)Partial Implementation of Infinite Datatypes (§5.1) which applies to the ·year· and ·second· values of this datatype.

Equality and order are as prescribed in The Seven-property Model (§D.2.1)dateTime values are ordered by their ·timeOnTimeline· value.

Note: Since the order of a dateTime value having a ·timezone· with another value whose ·timezone· is absent is determined by imputing timezones of both +14:00 and −14:00 to the untimezoned value, many such combinations will be ·incomparable· because the two imputed timezones yield different orders.

Although dateTime and other types related to dates and times have only a partial order, it is possible for datatypes derived from dateTime to have total orders, if they are restricted (e.g. using the pattern facet) to the subset of values with, or the subset of values without, timezones. Similar restrictions on other date- and time-related types will similarly produce totally ordered subtypes. Note, however, that such restrictions do not affect the value shown, for a given Simple Type Definition, in the ordered facet.

Note: Order and equality are essentially the same for dateTime in this version of this specification as they were in version 1.0.  However, since values now distinguish timezones, equal values with different ·timezone·s are not identical, and values with extreme ·timezone·s may no longer be equal to any value with a smaller ·timezone·.
3.3.8.2 Lexical Mappings

The lexical representations for dateTime are as follows:

Lexical Space
dateTimeLexicalRep ::= yearFrag '-monthFrag '-dayFrag 'T' ((hourFrag ':minuteFrag ':secondFrag) | endOfDayFrag) timezoneFrag?   Constraint:  Day-of-month Representations

Constraint: Day-of-month Representations
Within a dateTimeLexicalRep, a dayFrag must not begin with the digit '3' or be '29' unless the value to which it would map would satisfy the value constraint on ·day· values ("Constraint: Day-of-month Values") given above.

In such representations:

  • yearFrag is a numeral consisting of at least four decimal digits, optionally preceded by a minus sign; leading '0' digits are prohibited except to bring the digit count up to four.  It represents the ·year· value.
  • Subsequent '-', 'T', and ':', separate the various numerals.
  • monthFrag, dayFrag, hourFrag, and minuteFrag are numerals consisting of exactly two decimal digits.  They represent the ·month·, ·day·, ·hour·, and ·minute· values respectively.
  • dayFrag is a numeral consisting of exactly two decimal digits, or two decimal digits, a decimal point, and one or more trailing digits.  It represents the ·second· value.
  • Alternatively, endOfDayFrag combines the hourFrag, minuteFrag, minuteFrag, and their separators to represent midnight of the day, which is the first moment of the next day.
  • timezoneFrag, if present, specifies the timezone in which the moment occurs.  Timezones are a count of minutes (expressed in timezoneFrag as a count of hours and minutes) that are added or subtracted from UTC time to get the "local" time.  'Z' is an alternative representation of the timezone of UTC, which is, of course, zero minutes from UTC.

    For example, 2002-10-10T12:00:00−05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is equal to 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z.

The dateTimeLexicalRep production is equivalent to this regular expression once whitespace is removed.

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])\-(0[1-9])|(1[0-2])\-(0[1-9])([12][0-9])|(3[01])
 T(([01][0-9])|(2[0-3]):[0-5][0-9]:([0-5][0-9])(\.[0-9]+)?)|(24:00:00(\.0+)?)
   ([+\-](0[0-9])|(1[0-4]):[0-5][0-9])?

Note that neither the dateTimeLexicalRep production nor this regular expression alone enforce the constraint on dateTimeLexicalRep given above.

The ·lexical mapping· for dateTime is ·dateTimeLexicalMap·. The ·canonical mapping· is ·dateTimeCanonicalMap·.

3.3.8.3 Facets

dateTime has the following ·constraining facets·:

dateTime and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from dateTime may also specify values for the following ·constraining facets·:

dateTime has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.9 time

time represents instants of time that recur at the same point in each calendar day, or that occur in some arbitrary calendar day.

3.3.9.1 Value Space

time uses the date/timeSevenPropertyModel, with ·year·, ·month·, and ·day· required to be absent·timezone· remains ·optional·.

Note: See the conformance note in (§3.3.7)Partial Implementation of Infinite Datatypes (§5.1) which applies to the ·second· value of this datatype.

Equality and order are as prescribed in The Seven-property Model (§D.2.1)time values (points in time in an "arbitrary" day) are ordered taking into account their ·timezone·.

A calendar ( or "local time") day with an early timezone begins earlier than the same calendar day with a later timezone.  Since the timezones allowed spread over 28 hours, there are timezone pairs for which a given calendar day in the two timezones are totally disjoint—the earlier day ends before the same day starts in the later timezone.  The moments in time represented by a single calendar day are spread over a 52-hour interval, from the beginning of the day in the +14:00 timezone to the end of that day in the −14:00 timezone.

Note: Since the order of a time value having a ·timezone· with another value whose ·timezone· is absent is determined by imputing timezones of both +14:00 and −14:00 to the untimezoned value, many such combinations will be ·incomparable· because the two imputed timezones yield different orders.  However, for a given untimezoned value, there will always be timezoned values at one or both ends of the 52-hour interval that are ·comparable· (because the interval of ·incomparability· is only 24 hours wide).

Examples that show the difference from version 1.0 of this specification (see Lexical Mappings (§3.3.9.2) for the notations):

  • A day is a calendar (or "local time") day in each timezone.

    08:00:00+10:00 < 17:00:00+10:00  (just as 08:00:00Z has always been less than 17:00:00Z, but in version 1.0  08:00:00+10:00 > 17:00:00+10:00 )

  • A time value in a calendar day with an early timezone may precede every value in a later calendar day:

    00:00:00+01:00 is less than every value with ·timezone· Z

  • A calendar day with a very early timezone may be completely disjoint from a calendar day with a very late timezone:

    Each value with ·timezone· +13:00 is less than every value with ·timezone· −13:00

  • time values do not always convert to ·UTC· in the same way as in 1.0, since a time in a timezone may convert to a ·UTC· time on a different day (whereas time conversions in version 1.0 "wrapped around" by ignoring the day during conversion):

    22:00:00Z > 03:00:00+05:00 (since 1971-12-31T03:00:00+05 is 1979-12-30T22:00:00Z, not 1979-12-31T22:00:00Z); in the previous version of this specification  22:00:00Z = 03:00:00+05:00 )

3.3.9.2 Lexical Mappings

The lexical representations for time are "projections" of those of dateTime, as follows:

The timeLexicalRep production is equivalent to this regular expression, once whitespace is removed:

(((([01][0-9])|(2[0-3])):([0-5][0-9]):(([0-5][0-9])(\.[0-9]+)?))
  |(24:00:00(\.0+)?))
(Z|((+|-)(0[0-9]|1[0-4]):[0-5][0-9]))?

Note that neither the timeLexicalRep production nor this regular expression alone enforce the constraint on timeLexicalRep given above.

The ·lexical mapping· for time is ·timeLexicalMap·; the ·canonical mapping· is ·timeCanonicalMap·.

3.3.9.3 Facets

time has the following ·constraining facets·:

time and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from time may also specify values for the following ·constraining facets·:

time has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.10 date

[Definition:]   date represents top-open intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day (in each timezone), up to but not including the beginning moment of the next day).  For nontimezoned values, the top-open intervals disjointly cover the nontimezoned timeline, one per day.  For timezoned values, the intervals begin at every minute and therefore overlap.

3.3.10.1 Value Space

date uses the date/timeSevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional·.

Constraint: Day-of-month Values
The ·day· value must be no more than 30 if ·month· is one of 4, 6, 9, or 11, no more than 28 if ·month· is 2 and ·year· is not divisble 4, or is divisible by 100 but not by 400, and no more than 29 if ·month· is 2 and ·year· is divisible by 400, or by 4 but not by 100.
Note: See the conformance note in (§3.3.7)Partial Implementation of Infinite Datatypes (§5.1) which applies to the ·year· value of this datatype.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

Note: In version 1.0 of this specification, date values did not retain a timezone explicitly, but for timezones not too far from ·UTC· their timezone could be recovered based on their value's first moment on the timeline.  The date/timeSevenPropertyModel retains all timezones.

Examples that show the difference from version 1.0 (see Lexical Mappings (§3.3.10.2) for the notations):

  • A day is a calendar (or "local time") day in each timezone, including the timezones outside of +12:00 through -11:59 inclusive:

    2000-12-12+13:00 < 2000-12-12+11:00  (just as 2000-12-12+12:00 has always been less than 2000-12-12+11:00, but in version 1.0  2000-12-12+13:00 > 2000-12-12+11:00 , since 2000-12-12+13:00's "recoverable timezone" was −11:00)

  • Similarly:

    2000-12-12+13:00 = 2000-12-13−11:00  (whereas under 1.0, as just stated,  2000-12-12+13:00 = 2000-12-12−11:00)

3.3.10.2 Lexical Mappings

The lexical representations for date are "projections" of those of dateTime, as follows:

Lexical Space
dateLexicalRep ::= yearFrag '-monthFrag '-dayFrag timezoneFrag?   Constraint:  Day-of-month Representations

Constraint: Day-of-month Representations
Within a dateLexicalRep, a dayFrag must not begin with the digit '3' or be '29' unless the value to which it would map would satisfy the value constraint on ·day· values ("Constraint: Day-of-month Values") given above.

The dateLexicalRep production is equivalent to this regular expression:

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])\-(0[1-9])|(1[0-2])\-([0-2][0-9])|(3[01])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

Note that neither the dateLexicalRep production nor this regular expression alone enforce the constraint on dateLexicalRep given above.

The ·lexical mapping· for date is ·dateLexicalMap·. The ·canonical mapping· is ·dateCanonicalMap·.

3.3.11 gYearMonth

gYearMonth represents specific whole Gregorian months in specific Gregorian years.

3.3.11.1 Value Space

gYearMonth uses the date/timeSevenPropertyModel, with ·day·, ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional·.

Note: See the conformance note in (§3.3.7)Partial Implementation of Infinite Datatypes (§5.1) which applies to the ·year· value of this datatype.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

Note: In version 1.0 of this specification, gYearMonth values did not retain a timezone explicitly, but timezones not too far from ·UTC· could be recovered based on the gYearMonth value's first moment on the timeline.  The date/timeSevenPropertyModel simply retains all timezones.

An example that shows the difference from version 1.0 (see Lexical Mappings (§3.3.11.2) for the notations):

  • A day is a calendar (or "local time") day in each timezone, including the timezones outside of +12:00 through −11:59 inclusive:

    2000-12+13:00 < 2000-12+11:00  (just as 2000-12+12:00 has always been less than 2000−12+11:00, but in version 1.0  2000-12+13:00 > 2000-12+11:00 , since 2000−12+13:00's "recoverable timezone" was −11:00)

3.3.11.2 Lexical Mappings

The lexical representations for gYearMonth are "projections" of those of dateTime, as follows:

The gYearMonthLexicalRep is equivalent to this regular expression:

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])\-(0[1-9])|(1[0-2])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

The ·lexical mapping· for gYearMonth is ·gYearMonthLexicalMap·. The ·canonical mapping· is ·gYearMonthCanonicalMap·.

3.3.11.3 Facets

gYearMonth has the following ·constraining facets·:

gYearMonth and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from gYearMonth may also specify values for the following ·constraining facets·:

gYearMonth has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.12 gYear

gYear represents Gregorian calendar years.

3.3.12.1 Value Space

gYear uses the date/timeSevenPropertyModel, with ·month·, ·day·, ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional·.

Note: See the conformance note in (§3.3.7)Partial Implementation of Infinite Datatypes (§5.1) which applies to the ·year· value of this datatype.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

Note: In version 1.0 of this specification, gYear values did not retain a timezone explicitly, but timezones not too far from ·UTC· could be recovered based on the gYear value's first moment on the timeline.  The date/timeSevenPropertyModel simply retains all timezones.

An example that shows the difference from version 1.0 (see Lexical Mappings (§3.3.12.2) for the notations):

  • A day is a calendar (or "local time") day in each timezone, including the timezones outside of +12:00 through −11:59 inclusive:

    2000+13:00 < 2000+11:00  (just as 2000+12:00 has always been less than 2000+11:00, but in version 1.0  2000+13:00 > 2000+11:00 , since 2000+13:00's "recoverable timezone" was −11:00)

3.3.12.2 Lexical Mappings

The lexical representations for gYear are "projections" of those of dateTime, as follows:

The gYearLexicalRep is equivalent to this regular expression:

\-?([1-9][0-9][0-9][0-9]+)|(0[0-9][0-9][0-9])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

The ·lexical mapping· for gYear is ·gYearLexicalMap·. The ·canonical mapping· is ·gYearCanonicalMap·.

3.3.12.3 Facets

gYear has the following ·constraining facets·:

gYear and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from gYear may also specify values for the following ·constraining facets·:

gYear has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.13 gMonthDay

gMonthDay represents whole calendar days that recur at the same point in each calendar year, or that occur in some arbitrary calendar year.

This datatype can be used, for example, to record birthdays; an instance of the datatype could be used to say that someone's birthday occurs on the 14th of September every year.

Note:  Because day/month combinations in one calendar only rarely correspond to day/month combinations in other calendars, values of this type do not, in general, have any straightforward or intuitive representation in terms of most other calendars. This type should therefore be used with caution in contexts where conversion to other calendars is desired.
3.3.13.1 Value Space

gMonthDay uses the date/timeSevenPropertyModel, with ·year·, ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional·.

Constraint: Day-of-month Values
The ·day· value must be no more than 30 if ·month· is one of 4, 6, 9, or 11, and no more than 29 if ·month· is 2.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

Note: In version 1.0 of this specification, gMonthDay values did not retain a timezone explicitly, but for timezones not too far from ·UTC· their timezone could be recovered based on their value's first moment on the timeline.  The date/timeSevenPropertyModel retains all timezones.

An example that shows the difference from version 1.0 (see Lexical Mappings (§3.3.13.2) for the notations):

  • A day is a calendar (or "local time") day in each timezone, including the timezones outside of +12:00 through −11:59 inclusive:

    --12-12+13:00 < --12-12+11:00  (just as --12-12+12:00 has always been less than --12-12+11:00, but in version 1.0  --12-12+13:00 > --12-12+11:00 , since --12-12+13:00's "recoverable timezone" was −11:00)

3.3.13.2 Lexical Mappings

The lexical representations for gMonthDay are "projections" of those of dateTime, as follows:

Lexical Space
gMonthDayLexicalRep ::= '--monthFrag '-dayFrag timezoneFrag?   Constraint:  Day-of-month Representations

Constraint: Day-of-month Representations
Within a gMonthDayLexicalRep, a dayFrag must not begin with the digit '3' or be '29' unless the value to which it would map would satisfy the value constraint on ·day· values ("Constraint: Day-of-month Values") given above.

The gMonthDayLexicalRep is equivalent to this regular expression:

\-\-(0[1-9])|(1[0-2])\-([0-2][0-9])|(3[01])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

Note that neither the gMonthDayLexicalRep production nor this regular expression alone enforce the constraint on gMonthDayLexicalRep given above.

The ·lexical mapping· for gMonthDay is ·gMonthDayLexicalMap·. The ·canonical mapping· is ·gMonthDayCanonicalMap·.

3.3.13.3 Facets

gMonthDay has the following ·constraining facets·:

gMonthDay and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from gMonthDay may also specify values for the following ·constraining facets·:

gMonthDay has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.14 gDay

[Definition:]  gDay represents whole days within an arbitrary month—days that recur at the same point in each (Gregorian) month. This datatype is used to represent a specific day of the month. To indicate, for example, that an employee gets a paycheck on the 15th of each month.  (Obviously, days beyond 28 cannot occur in all months; they are nonetheless permitted, up to 31.)

Note: Because days in one calendar only rarely correspond to days in other calendars, gday values do not, in general, have any straightforward or intuitive representation in terms of most non-Gregorian calendars. gday should therefore be used with caution in contexts where conversion to other calendars is desired.
3.3.14.1 Value Space

gDay uses the date/timeSevenPropertyModel, with ·year·, ·month·, ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional· and ·day· must be between 1 and 31 inclusive.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).  Since gDay values (days) are ordered by their first moments, it is possible for apparent anomalies to appear in the order when ·timezone· values differ by at least 24 hours.  (It is possible for ·timezone· values to differ by up to 28 hours.)

Examples that may appear anomalous (see Lexical Mappings (§3.3.14.2) for the notations):

  • ---15 < ---16 , but  ---15−13:00 > ---16+13:00
  • ---15−11:00 = ---16+13:00
  • ---15−13:00 <> ---16 , because  ---15−13:00 > ---16+14:00  and ---15−13:00 < 16−14:00

Note:  Timezones do not cause wrap-around at the end of the month:  the last day of a given month in timezone −13:00 may start after the first day of the next month in timezone +13:00, as measured on the global timeline, but nonetheless  ---01+13:00 < ---31−13:00 .
3.3.14.2 Lexical Mappings

The lexical representations for gDay are "projections" of those of dateTime, as follows:

The gDayLexicalRep is equivalent to this regular expression:

\-\-\-([0-2][0-9]|3[01])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

The ·lexical mapping· for gDay is ·gDayLexicalMap·. The ·canonical mapping· is ·gDayCanonicalMap·.

3.3.14.3 Facets

gDay has the following ·constraining facets·:

gDay and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from gDay may also specify values for the following ·constraining facets·:

gDay has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.15 gMonth

gMonth represents whole (Gregorian) months within an arbitrary year—months that recur at the same point in each year.  It might be used, for example, to say what month annual Thanksgiving celebrations fall in different countries (--11 in the United States, --10 in Canada, and possibly other months in other countries).

3.3.15.1 Value Space

gMonth uses the date/timeSevenPropertyModel, with ·year·, ·day·, ·hour·, ·minute·, and ·second· required to be absent·timezone· remains ·optional·.

Equality and order are as prescribed in The Seven-property Model (§D.2.1).

Note: In version 1.0 of this specification, gMonth values did not retain a timezone explicitly, but for timezones not too far from ·UTC· their timezone could be recovered based on their value's first moment on the timeline.  The date/timeSevenPropertyModel retains all timezones.

An example that shows the difference from version 1.0 (see Lexical Mappings (§3.3.15.2) for the notations):

  • A month is a calendar (or "local time") month in each timezone, including the timezones outside of +12:00 through −11:59 inclusive:

    --12+13:00 < --12+11:00  (just as --12+12:00 has always been less than --12+11:00, but in version 1.0  --12+13:00 > --12+11:00 , since --12+13:00's "recoverable timezone" was −11:00)

3.3.15.2 Lexical Mappings

The lexical representations for gMonth are "projections" of those of dateTime, as follows:

The gMonthLexicalRep is equivalent to this regular expression:

\-\-(0[1-9])|(1[0-2])((+|\-)(0[0-9]|1[0-4]):[0-5][0-9])?

The ·lexical mapping· for gMonth is ·gMonthLexicalMap·. The ·canonical mapping· is ·gMonthCanonicalMap·.

3.3.15.3 Facets

gMonth has the following ·constraining facets·:

gMonth and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from gMonth may also specify values for the following ·constraining facets·:

gMonth has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.16 hexBinary

[Definition:]   hexBinary represents arbitrary hex-encoded binary data.

The ·value space· of hexBinary is the set of finite-length sequences of binary octets.

3.3.16.2 Lexical Representation

hexBinary has a ·lexical representation· where each binary octet is encoded as a character tuple, consisting of two hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example, '0FB7' is a hex encoding for the 16-bit integer 4023 (whose binary representation is 111110110111).

More formally, the ·lexical space· of hexBinary is the set of literals matching the hexBinary production.

The set recognized by hexBinary is the same as that recognized by the regular expression '([0-9a-fA-F]{2})*'.

3.3.16.3 Canonical Representation

The ·canonical representation· for hexBinary is defined by prohibiting certain options from the Lexical Representation (§3.3.16.2).  Specifically, the lower case hexadecimal digits ([a-f]) are not allowed.

3.3.16.4 Facets

hexBinary has the following ·constraining facets·:

hexBinary and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from hexBinary may also specify values for the following ·constraining facets·:

hexBinary has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.17 base64Binary

[Definition:]   base64Binary represents arbitrary Base64-encoded arbitrary binary data.  The ·value space· of base64Binary is the set of finite-length sequences of binary octets. For base64Binary data the entire binary stream is encoded using the Base64 Encoding defined in [RFC 3548], which is derived from the encoding described in [RFC 2045].

3.3.17.1 Value Space

The ·value space· of base64Binary is the set of finite-length sequences of binary octets.

3.3.17.2 Lexical Representation

The lexical forms·lexical representations·↑ of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC 3548], i.e., a-z, A-Z, 0-9, the plus sign (+), the forward slash (/) and the equal sign (=), together with the characters defined in [XML] as white spacethe space character (#x20). No other characters are allowed.

For compatibility with older mail gateways, [RFC 2045] suggests that bBase64 data should have lines limited to at most 76 characters in length.  This line-length limitation is not required by [RFC 3548] and is not mandated in the lexical forms·lexical representations· of base64Binary data. It must not be enforced by XML Schema processors.

The ·lexical space· of base64Binary is given by the following grammar (the notation is that used in [XML]); legal lexical forms must matchthe set of literals which ·match· the Base64Binary production.

Base64Binary  ::=  ((B64S B64S B64S B64S)*
                     ((B64S B64S B64S B64) |
                      (B64S B64S B16S '=') |
                      (B64S B04S '=' #x20? '=')))?

B64S         ::= B64 #x20?

B16S         ::= B16 #x20?

B04S         ::= B04 #x20?


B04         ::=  [AQgw]
B16         ::=  [AEIMQUYcgkosw048]
B64         ::=  [A-Za-z0-9+/]

Lexical space of base64Binary
B64quad ::= (B64 B64 B64 B64) /* B64quad represents three octets of binary data. */
B64finalquad ::= (B64 B64 B64 B64char) /* B64finalquad represents three octets of binary data without trailing space. */
Padded16 ::= B64 B64 B16 '=' /* Padded16 represents a two-octet at the end of the data. */
Padded8 ::= B64 B04 '=' #x20? '=' /* Padded8 represents a single octet at the end of the data. */

Note that this grammar requires the number of non-whitespace characters in the lexical form·lexical representation·↑ to be a multiple of four, and for equals signs to appear only at the end of the lexical form·lexical representation·; stringsliterals which do not meet these constraints are not legal lexical forms·lexical representations· of base64Binary because they cannot successfully be decoded by bBase64 decoders.

Note: The above definition of the ·lexical space· is more restrictive than that given in [RFC 2045] as regards whitespace — and less restrictive than [RFC 3548]. This is not an issue in practice.  Any string compatible with either RFC can occur in an element or attribute validated by this type, because the ·whiteSpace· facet of this type is fixed to collapse, which means that all leading and trailing whitespace will be stripped, and all internal whitespace collapsed to single space characters, before the above grammar is enforced. The possibility of ignoring whitespace in bBase64 data is foreseen in clause 2.3 of [RFC 3548], but for the reasons given there this specification does not allow implementations to ignore non-whitespace characters which are not in the Base64 Alphabet.

The canonical lexical form·lexical representation· of a base64Binary data value is the bBase64 encoding of the value which matches the Canonical-base64Binary production in the following grammar:

Canonical-base64Binary  ::=  (B64 B64 B64 B64)*
                               ((B64 B64 B16 '=') | (B64 B04 '=='))?

That is, the ·canonical representation· of a base64Binary value is the ·lexical representation· which maps to that value and contains no whitespace. The ·canonical mapping· for base64Binary is thus the encoding algorithm for Base64 data given in [RFC 2045] and [RFC 3548], with the proviso that no characters except those in the Base64 Alphabet are to be written out.

Note: For some values the ·canonical formrepresentation· defined above does not conform to [RFC 2045], which requires breaking with linefeeds at appropriate intervals. It does conform with [RFC 3548].

The length of a base64Binary value is the number of octets it contains. This may be calculated from the lexical form·lexical representation· by removing whitespace and padding characters and performing the calculation shown in the pseudo-code below:

lex2    := killwhitespace(lexform)    -- remove whitespace characters
lex3    := strip_equals(lex2)         -- strip padding characters at end
length  := floor (length(lex3) * 3 / 4)         -- calculate length

Note on encoding: [RFC 2045] and [RFC 3548] explicitly reference US-ASCII encoding.  However, decoding of base64Binary data in an XML entity is to be performed on the Unicode characters obtained after character encoding processing as specified by [XML].

3.3.17.3 Facets

base64Binary has the following ·constraining facets·:

base64Binary and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from base64Binary may also specify values for the following ·constraining facets·:

base64Binary has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.18 anyURI

[Definition:]   anyURI represents an Internationalized Resource Identifier Reference (IRI).  An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be an IRI Reference).  This type should be used when the value fulfills the role of an IRI, as defined in [RFC 3987] or its successor(s) in the IETF Standards Track.

Note: IRIs may be used to locate resources or simply to identify them. In the case where they are used to locate resources using a URI, applications should use the mapping from anyURI values to URIs given by the URI reference escaping procedure defined in Section 3.1 Mapping of IRIs to URIs of [RFC 3987] or its successor(s) in the IETF Standards Track.  This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 3986] and its successor(s).
3.3.18.1 Lexical mapping

The ·lexical space· of anyURI is finite-length character sequences.

Note: For an anyURI value to be usable in practice as an IRI, the result of applying to it the algorithm defined in Section 3.1 of [RFC 3987] should be a string which is a legal URI according to [RFC 3986]. (This is true at the time this document is published; if in the future [RFC 3987] and [RFC 3986] are replaced by other specifications in the IETF Standards Track, the relevant constraints will be those imposed by those successor specifications.)

Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragment identifiers. Because it is impractical for processors to check that a value is a context-appropriate URI reference, neither the syntactic constraints defined by the definitions of individual schemes nor the generic syntactic constraints defined by [RFC 3987] and [RFC 3986] and their successors are part of this datatype as defined here. Applications which depend on anyURI values being legal according to the rules of the relevant specifications should make arrangements to check values against the appropriate definitions of IRI, URI, and specific schemes.

Note:  Spaces are, in principle, allowed in the ·lexical space· of anyURI, however, their use is highly discouraged (unless they are encoded by '%20').

The ·lexical mapping· for anyURI is the identity mapping.

Note: The definitions of URI in the current IETF specifications define certain URIs as equivalent to each other. Those equivalences are not part of this datatype as defined here: if two "equivalent" URIs or IRIs are different character sequences, they map to different values in this datatype.
3.3.18.2 Facets

anyURI has the following ·constraining facets·:

anyURI and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from anyURI may also specify values for the following ·constraining facets·:

anyURI has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.3.19 QName

[Definition:]   QName represents XML qualified names. The ·value space· of QName is the set of tuples {namespace name, local part}, where namespace name is an anyURI and local part is an NCName. The ·lexical space· of QName is the set of strings that ·match· the QName production of [Namespaces in XML].

It is implementation-defined whether an implementation of this specification supports the QName production from [Namespaces in XML], or that from [Namespaces in XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

Note:  The mapping between ·literals· in the ·lexical space· and values in the ·value space· of QName requires a namespace declaration to be in scope for the context in which QName is used.

Because the lexical representations available for any value of type QName vary with context, no ·canonical representation· is defined for QName in this specification.

3.3.19.1 Facets

QName has the following ·constraining facets·:

QName and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from QName may also specify values for the following ·constraining facets·:

QName has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

The use of ·length·, ·minLength· and ·maxLength· on QName or datatypes derived from QName is deprecated.  Future versions of this specification may remove these facets for this datatype.

3.3.20 NOTATION

[Definition:]  NOTATION represents the NOTATION attribute type from [XML]. The ·value space· of NOTATION is the set of QNames of notations declared in the current schema. The ·lexical space· of NOTATION is the set of all names of notations declared in the current schema (in the form of QNames).

Schema Component Constraint: enumeration facet value required for NOTATION
It is an ·error· for NOTATION to be used directly in a schema.  Only datatypes that are derived from NOTATION by specifying a value for ·enumeration· can be used in a schema.

For compatibility (see Terminology (§1.6)) NOTATION should be used only on attributes and should only be used in schemas with no target namespace.

Note: Because the lexical representations available for any given value of NOTATION vary with context, this specification defines no ·canonical representation· for NOTATION values.

3.3.20.1 Facets

NOTATION has the following ·constraining facets·:

NOTATION and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

Datatypes derived by restriction from NOTATION may also specify values for the following ·constraining facets·:

NOTATION has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

The use of ·length·, ·minLength· and ·maxLength· on NOTATION or datatypes derived from NOTATION is deprecated.  Future versions of this specification may remove these facets for this datatype.

previous sub-section 3.4 Other Built-in Datatypes

        3.4.1 normalizedString
        3.4.2 token
        3.4.3 language
        3.4.4 NMTOKEN
        3.4.5 NMTOKENS
        3.4.6 Name
        3.4.7 NCName
        3.4.8 ID
        3.4.9 IDREF
        3.4.10 IDREFS
        3.4.11 ENTITY
        3.4.12 ENTITIES
        3.4.13 integer
        3.4.14 nonPositiveInteger
        3.4.15 negativeInteger
        3.4.16 long
        3.4.17 int
        3.4.18 short
        3.4.19 byte
        3.4.20 nonNegativeInteger
        3.4.21 unsignedLong
        3.4.22 unsignedInt
        3.4.23 unsignedShort
        3.4.24 unsignedByte
        3.4.25 positiveInteger
        3.4.26 yearMonthDuration
        3.4.27 dayTimeDuration

This section gives conceptual definitions for all ·built-in· ·ordinary· datatypes defined by this specification. The XML representation used to define datatypes (whether ·built-in· or ·user-defined·) is given in XML Representation of Simple Type Definition Schema Components (§4.1.2) and the complete definitions of the ·built-in· ·ordinary· datatypes are provided in the appendix Schema for Schema Documents (Datatypes) (normative) (§A).

3.4.1 normalizedString

[Definition:]   normalizedString represents white space normalized strings. The ·value space· of normalizedString is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. The ·lexical space· of normalizedString is the set of strings that do not contain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. The ·base type· of normalizedString is string.

3.4.1.1 Facets

normalizedString has the following ·constraining facets·:

normalizedString has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from normalizedString may also specify values for the following ·constraining facets·:

normalizedString has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.2 token

[Definition:]   token represents tokenized strings. The ·value space· of token is the set of strings that do not contain the carriage return (#xD), 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 carriage return (#xD), 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 normalizedString.

3.4.2.1 Facets

token has the following ·constraining facets·:

token has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from token may also specify values for the following ·constraining facets·:

token has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.3 language

[Definition:]   language represents formal natural language identifiers, as defined by [RFC 3066]or its successor(s) in the IETF Standards Track. The ·value space· and ·lexical space· of language are the set of all strings that conform to the pattern

[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*

, This is the set of strings accepted by the grammar given in [RFC 3066]. The ·base type· of language is token.

Note: The regular expression above provides the only normative constraint on the lexical and value spaces of this type. The additional constraints imposed on language identifiers by [RFC 3066] and its successor(s), and in particular their requirement that language codes be registered with IANA or ISO if not given in ISO 639, are not part of this datatype as defined here.
Note: [RFC 3066] specifies that language codes "are to be treated as case insensitive; there exist conventions for capitalization of some of them, but these should not be taken to carry meaning. For instance, [ISO 3166] recommends that country codes are capitalized (MN Mongolia), while [ISO 639] recommends that language codes are written in lower case (mn Mongolian)." Since the language datatype is derived from string, it inherits from string a one-to-one mapping from lexical representations to values. The literals 'MN' and 'mn' therefore correspond to distinct values and have distinct canonical forms. Users of this specification should be aware of this fact, the consequence of which is that the case-insensitive treatment of language values prescribed by [RFC 3066] does not follow from the definition of this datatype given here; applications which require case-sensitivity should make appropriate adjustments.
3.4.3.1 Facets

language has the following ·constraining facets·:

language has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from language may also specify values for the following ·constraining facets·:

language has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.4 NMTOKEN

[Definition:]   NMTOKEN represents the NMTOKEN attribute type from [XML]. The ·value space· of NMTOKEN is the set of tokens that ·match· the Nmtoken production in [XML]. The ·lexical space· of NMTOKEN is the set of strings that ·match· the Nmtoken production in [XML].  The ·base type· of NMTOKEN is token.

It is implementation-defined whether an implementation of this specification supports the NMTOKEN production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

For compatibility (see Terminology (§1.6)) NMTOKEN should be used only on attributes.

3.4.4.1 Facets

NMTOKEN has the following ·constraining facets·:

NMTOKEN has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from NMTOKEN may also specify values for the following ·constraining facets·:

NMTOKEN has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.5 NMTOKENS

[Definition:]   NMTOKENS represents the NMTOKENS attribute type from [XML]. The ·value space· of NMTOKENS is the set of finite, non-zero-length sequences of ·NMTOKEN·s.  The ·lexical space· of NMTOKENS is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of NMTOKEN.  The ·item type· of NMTOKENS is .

For compatibility (see Terminology (§1.6)) NMTOKENS should be used only on attributes.

3.4.5.1 Facets

NMTOKENS has the following ·constraining facets·:

NMTOKENS has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from NMTOKENS may also specify values for the following ·constraining facets·:

NMTOKENS has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.6 Name

[Definition:]   Name represents XML Names. The ·value space· of Name is the set of all strings which ·match· the Name production of [XML].  The ·lexical space· of Name is the set of all strings which ·match· the Name production of [XML]. The ·base type· of Name is token.

It is implementation-defined whether an implementation of this specification supports the Name production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

3.4.6.1 Facets

Name has the following ·constraining facets·:

Name has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from Name may also specify values for the following ·constraining facets·:

Name has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.7 NCName

[Definition:]   NCName represents XML "non-colonized" Names.  The ·value space· of NCName is the set of all strings which ·match· the NCName production of [Namespaces in XML].  The ·lexical space· of NCName is the set of all strings which ·match· the NCName production of [Namespaces in XML].  The ·base type· of NCName is Name.

It is implementation-defined whether an implementation of this specification supports the NCName production from [Namespaces in XML], or that from [Namespaces in XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

3.4.7.1 Facets

NCName has the following ·constraining facets·:

NCName has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from NCName may also specify values for the following ·constraining facets·:

NCName has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.8 ID

[Definition:]   ID represents the ID attribute type from [XML].  The ·value space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML].  The ·lexical space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ID is NCName.

Note: It is implementation-defined whether an implementation of this specification supports the NCName production from [Namespaces in XML], or that from [Namespaces in XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

For compatibility (see Terminology (§1.6)) ID should be used only on attributes.

Note: Uniqueness of items validated as ID is not part of this datatype as defined here. When this specification is used in conjunction with [XML Schema Part 1: Structures], uniqueness is enforced at a different level, not as part of datatype validity; see Validation Rule: Validation Root Valid (ID/IDREF) in [XML Schema Part 1: Structures].
3.4.8.1 Facets

ID has the following ·constraining facets·:

ID has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from ID may also specify values for the following ·constraining facets·:

ID has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.9 IDREF

[Definition:]   IDREF represents the IDREF attribute type from [XML].  The ·value space· of IDREF is the set of all strings that ·match· the NCName production in [Namespaces in XML].  The ·lexical space· of IDREF is the set of strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of IDREF is NCName.

Note: 
It is implementation-defined whether an implementation of this specification supports the NCName production from [Namespaces in XML], or that from [Namespaces in XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

For compatibility (see Terminology (§1.6)) this datatype should be used only on attributes.

Note: Existence of referents for items validated as IDREF is not part of this datatype as defined here. When this specification is used in conjunction with [XML Schema Part 1: Structures], referential integrity is enforced at a different level, not as part of datatype validity; see Validation Rule: Validation Root Valid (ID/IDREF) in [XML Schema Part 1: Structures].
3.4.9.1 Facets

IDREF has the following ·constraining facets·:

IDREF has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from IDREF may also specify values for the following ·constraining facets·:

IDREF has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.10 IDREFS

[Definition:]   IDREFS represents the IDREFS attribute type from [XML].  The ·value space· of IDREFS is the set of finite, non-zero-length sequences of IDREFs. The ·lexical space· of IDREFS is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of IDREF. The ·item type· of IDREFS is .

For compatibility (see Terminology (§1.6)) IDREFS should be used only on attributes.

Note: Existence of referents for items validated as IDREFS is not part of this datatype as defined here. When this specification is used in conjunction with [XML Schema Part 1: Structures], referential integrity is enforced at a different level, not as part of datatype validity; see Validation Rule: Validation Root Valid (ID/IDREF) in [XML Schema Part 1: Structures].
3.4.10.1 Facets

IDREFS has the following ·constraining facets·:

IDREFS has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from IDREFS may also specify values for the following ·constraining facets·:

IDREFS has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.11 ENTITY

[Definition:]   ENTITY represents the ENTITY attribute type from [XML].  The ·value space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML] and have been declared as an unparsed entity in a document type definition. The ·lexical space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ENTITY is NCName.

Note: 
It is implementation-defined whether an implementation of this specification supports the NCName production from [Namespaces in XML], or that from [Namespaces in XML 1.0], or both. See Dependencies on Other Specifications (§1.3).
Note:  The ·value space· of ENTITY is scoped to a specific instance document.

For compatibility (see Terminology (§1.6)) ENTITY should be used only on attributes.

3.4.11.1 Facets

ENTITY has the following ·constraining facets·:

ENTITY has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from ENTITY may also specify values for the following ·constraining facets·:

ENTITY has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.12 ENTITIES

[Definition:]   ENTITIES represents the ENTITIES attribute type from [XML]. The ·value space· of ENTITIES is the set of finite, non-zero-length sequences of ·ENTITY·s that have been declared as unparsed entities in a document type definition. The ·lexical space· of ENTITIES is the set of space-separated lists of tokens, of which each token is in the ·lexical space· of ENTITY. The ·item type· of ENTITIES is .

Note:  The ·value space· of ENTITIES is scoped to a specific instance document.

For compatibility (see Terminology (§1.6)) ENTITIES should be used only on attributes.

3.4.12.1 Facets

ENTITIES has the following ·constraining facets·:

ENTITIES has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from ENTITIES may also specify values for the following ·constraining facets·:

ENTITIES has the following values for its ·fundamental facets·:

  • ordered = false
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.13 integer

[Definition:]   integer is derived from decimal by fixing the value of ·fractionDigits· to be 0 and disallowing the trailing decimal point. This results in the standard mathematical concept of the integer numbers. The ·value space· of integer is the infinite set {...,-2,-1,0,1,2,...}.  The ·base type· of integer is decimal.

3.4.13.2 Canonical representation

The ·canonical representation· for integer is defined by prohibiting certain options from the Lexical representation (§3.4.13.1).  Specifically, the preceding optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.13.3 Facets

integer has the following ·constraining facets·:

integer and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

integer has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from integer may also specify values for the following ·constraining facets·:

integer has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.4.14 nonPositiveInteger

[Definition:]   nonPositiveInteger is derived from integer by setting the value of ·maxInclusive· to be 0.  This results in the standard mathematical concept of the non-positive integers. The ·value space· of nonPositiveInteger is the infinite set {...,-2,-1,0}.  The ·base type· of nonPositiveInteger is integer.

3.4.14.2 Canonical representation

The ·canonical representation· for nonPositiveInteger is defined by prohibiting certain options from the Lexical representation (§3.4.14.1). In the canonical form for zero, the sign must be omitted.  Leading zeroes are prohibited.

3.4.14.3 Facets

nonPositiveInteger has the following ·constraining facets·:

nonPositiveInteger and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

nonPositiveInteger has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from nonPositiveInteger may also specify values for the following ·constraining facets·:

nonPositiveInteger has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.4.15 negativeInteger

[Definition:]   negativeInteger is derived from nonPositiveInteger by setting the value of ·maxInclusive· to be -1.  This results in the standard mathematical concept of the negative integers.  The ·value space· of negativeInteger is the infinite set {...,-2,-1}.  The ·base type· of negativeInteger is nonPositiveInteger.

3.4.15.2 Canonical representation

The ·canonical representation· for negativeInteger is defined by prohibiting certain options from the Lexical representation (§3.4.15.1).  Specifically, leading zeroes are prohibited.

3.4.15.3 Facets

negativeInteger has the following ·constraining facets·:

negativeInteger and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

negativeInteger has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from negativeInteger may also specify values for the following ·constraining facets·:

negativeInteger has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.4.16 long

[Definition:]   long is derived from integer by setting the value of ·maxInclusive· to be 9223372036854775807 and ·minInclusive· to be -9223372036854775808. The ·base type· of long is integer.

3.4.16.2 Canonical representation

The ·canonical representation· for long is defined by prohibiting certain options from the Lexical representation (§3.4.16.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.16.3 Facets

long has the following ·constraining facets·:

long and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

long has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from long may also specify values for the following ·constraining facets·:

long has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.17 int

[Definition:]   int is derived from long by setting the value of ·maxInclusive· to be 2147483647 and ·minInclusive· to be -2147483648.  The ·base type· of int is long.

3.4.17.2 Canonical representation

The ·canonical representation· for int is defined by prohibiting certain options from the Lexical representation (§3.4.17.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.17.3 Facets

int has the following ·constraining facets·:

int and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

int has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from int may also specify values for the following ·constraining facets·:

int has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.18 short

[Definition:]   short is derived from int by setting the value of ·maxInclusive· to be 32767 and ·minInclusive· to be -32768.  The ·base type· of short is int.

3.4.18.2 Canonical representation

The ·canonical representation· for short is defined by prohibiting certain options from the Lexical representation (§3.4.18.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.18.3 Facets

short has the following ·constraining facets·:

short and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

short has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from short may also specify values for the following ·constraining facets·:

short has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.19 byte

[Definition:]   byte is derived from short by setting the value of ·maxInclusive· to be 127 and ·minInclusive· to be -128. The ·base type· of byte is short.

3.4.19.2 Canonical representation

The ·canonical representation· for byte is defined by prohibiting certain options from the Lexical representation (§3.4.19.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.19.3 Facets

byte has the following ·constraining facets·:

byte and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

byte has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from byte may also specify values for the following ·constraining facets·:

byte has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.20 nonNegativeInteger

[Definition:]   nonNegativeInteger is derived from integer by setting the value of ·minInclusive· to be 0.  This results in the standard mathematical concept of the non-negative integers. The ·value space· of nonNegativeInteger is the infinite set {0,1,2,...}.  The ·base type· of nonNegativeInteger is integer.

3.4.20.2 Canonical representation

The ·canonical representation· for nonNegativeInteger is defined by prohibiting certain options from the Lexical representation (§3.4.20.1).  Specifically, the the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.20.3 Facets

nonNegativeInteger has the following ·constraining facets·:

nonNegativeInteger and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

nonNegativeInteger has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from nonNegativeInteger may also specify values for the following ·constraining facets·:

nonNegativeInteger has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.4.21 unsignedLong

[Definition:]   unsignedLong is derived from nonNegativeInteger by setting the value of ·maxInclusive· to be 18446744073709551615. The ·base type· of unsignedLong is nonNegativeInteger.

3.4.21.2 Canonical representation

The ·canonical representation· for unsignedLong is defined by prohibiting certain options from the Lexical representation (§3.4.21.1).  Specifically, leading zeroes are prohibited.

3.4.21.3 Facets

unsignedLong has the following ·constraining facets·:

unsignedLong and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

unsignedLong has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from unsignedLong may also specify values for the following ·constraining facets·:

unsignedLong has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.22 unsignedInt

[Definition:]   unsignedInt is derived from unsignedLong by setting the value of ·maxInclusive· to be 4294967295.  The ·base type· of unsignedInt is unsignedLong.

3.4.22.2 Canonical representation

The ·canonical representation· for unsignedInt is defined by prohibiting certain options from the Lexical representation (§3.4.22.1).  Specifically, leading zeroes are prohibited.

3.4.22.3 Facets

unsignedInt has the following ·constraining facets·:

unsignedInt and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

unsignedInt has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from unsignedInt may also specify values for the following ·constraining facets·:

unsignedInt has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.23 unsignedShort

[Definition:]   unsignedShort is derived from unsignedInt by setting the value of ·maxInclusive· to be 65535.  The ·base type· of unsignedShort is unsignedInt.

3.4.23.2 Canonical representation

The ·canonical representation· for unsignedShort is defined by prohibiting certain options from the Lexical representation (§3.4.23.1).  Specifically, the leading zeroes are prohibited.

3.4.23.3 Facets

unsignedShort has the following ·constraining facets·:

unsignedShort and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

unsignedShort has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from unsignedShort may also specify values for the following ·constraining facets·:

unsignedShort has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.24 unsignedByte

[Definition:]   unsignedByte is derived from unsignedShort by setting the value of ·maxInclusive· to be 255. The ·base type· of unsignedByte is unsignedShort.

3.4.24.2 Canonical representation

The ·canonical representation· for unsignedByte is defined by prohibiting certain options from the Lexical representation (§3.4.24.1).  Specifically, leading zeroes are prohibited.

3.4.24.3 Facets

unsignedByte has the following ·constraining facets·:

unsignedByte and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

unsignedByte has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from unsignedByte may also specify values for the following ·constraining facets·:

unsignedByte has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = true
  • cardinality = finite
  • numeric = true

3.4.25 positiveInteger

[Definition:]   positiveInteger is derived from nonNegativeInteger by setting the value of ·minInclusive· to be 1. This results in the standard mathematical concept of the positive integer numbers. The ·value space· of positiveInteger is the infinite set {1,2,...}.  The ·base type· of positiveInteger is nonNegativeInteger.

3.4.25.2 Canonical representation

The ·canonical representation· for positiveInteger is defined by prohibiting certain options from the Lexical representation (§3.4.25.1).  Specifically, the optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.25.3 Facets

positiveInteger has the following ·constraining facets·:

positiveInteger and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

positiveInteger has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from positiveInteger may also specify values for the following ·constraining facets·:

positiveInteger has the following values for its ·fundamental facets·:

  • ordered = total
  • bounded = false
  • cardinality = countably infinite
  • numeric = true

3.4.26 yearMonthDuration

[Definition:]   yearMonthDuration is a datatype derived from duration by restricting its ·lexical representations· to instances of yearMonthDurationLexicalRep.  The ·value space· of yearMonthDuration is therefore that of duration restricted to those whose ·seconds· property is 0.  This results in a duration datatype which is totally ordered.

Note: The always-zero ·seconds· is formally retained in order that yearMonthDuration's (abstract) value space truly be a subset of that of duration  An obvious implementation optimization is to ignore the zero and implement yearMonthDuration values simply as integer values.
3.4.26.1 The yearMonthDuration Lexical Mapping

The lexical space is reduced from that of duration by disallowing duDayFrag and duTimeFrag fragments in the ·lexical representations·.

The lexical space of yearMonthDuration consists of strings which match the regular expression '-?P((([0-9]+Y)([0-9]+M)?)|([0-9]+M))' or the expression '-?P[0-9]+(Y([0-9]+M)?|M)', but the formal definition of yearMonthDuration uses a simpler regular expression in its ·pattern· facet: '[^DT]*'. This pattern matches only strings of characters which contain no 'D' and no 'T', thus restricting the ·lexical space· of duration to strings with no day, hour, minute, or seconds fields.

The ·canonical mapping· is that of duration restricted in its range to the ·lexical space· (which reduces its domain to omit any values not in the yearMonthDuration value space).

Note: The yearMonthDuration value whose ·months· and ·seconds· are both zero has no ·canonical representation· in this datatype since its ·canonical representation· in duration ('PT0S') is not in the ·lexical space· of yearMonthDuration.
3.4.26.2 Facets

yearMonthDuration has the following ·constraining facets·:

yearMonthDuration and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

yearMonthDuration has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from yearMonthDuration may also specify values for the following ·constraining facets·:

yearMonthDuration has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

3.4.27 dayTimeDuration

[Definition:]   dayTimeDuration is a datatype derived from duration by restricting its ·lexical representations· to instances of dayTimeDurationLexicalRep. The ·value space· of dayTimeDuration is therefore that of duration restricted to those whose ·months· property is 0.  This results in a duration datatype which is totally ordered.

3.4.27.1 The dayTimeDuration Lexical Space

The lexical space is reduced from that of duration by disallowing duYearFrag and duMonthFrag fragments in the ·lexical representations·.

The lexical space of dayTimeDuration consists of strings in the ·lexical space· of duration which match the regular expression '[^YM]*[DT].*'; this pattern eliminates all durations with year or month fields, leaving only those with day, hour, minutes, and/or seconds fields.

The ·canonical mapping· is that of duration restricted in its range to the ·lexical space· (which reduces its domain to omit any values not in the yearMonthDuration value space).

3.4.27.2 Facets

dayTimeDuration has the following ·constraining facets·:

dayTimeDuration and all datatypes derived from it by restriction have the following ·constraining facets· with fixed values; these facets must not be changed from the values shown:

dayTimeDuration has the following ·constraining facets· with the values shown; these facets may be further restricted in the derivation of new types:

Datatypes derived by restriction from dayTimeDuration may also specify values for the following ·constraining facets·:

dayTimeDuration has the following values for its ·fundamental facets·:

  • ordered = partial
  • bounded = false
  • cardinality = countably infinite
  • numeric = false

4 Datatype components

The preceding sections of this specification have described datatypes in a way largely independent of their use in the particular context of schema-aware processing as defined in [XML Schema Part 1: Structures].

This section presents the mechanisms necessary to integrate datatypes into the context of [XML Schema Part 1: Structures], mostly in terms of the Schema Component abstraction introduced there. The account of datatypes given in this specification is also intended to be useful in other contexts. Any specification or other formal system intending to use datatypes as defined above, particularly if definition of new datatypes via facet-based restriction is envisaged, will need to provide analogous mechanisms for some, but not necessarily all, of what follows below. For example, the {target namespace} and {final} properties are required because of particular aspects of [XML Schema Part 1: Structures] which are not in principle necessary for the use of datatypes as defined here.

The following sections provide full details on the properties and significance of each kind of schema component involved in datatype definitions. For each property, the kinds of values it is allowed to have is specified.  Any property not identified as optional is required to be present; optional properties which are not present have absent as their value. Any property identified as a having a set, subset or ·list· value may have an empty value unless this is explicitly ruled out: this is not the same as absent. Any property value identified as a superset or a subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.

For more information on the notion of schema components, see Schema Component Details of [XML Schema Part 1: Structures].

[Definition:]  A component may be referred to as the owner of its properties, and of the values of those properties.

next sub-section4.1 Simple Type Definition

Simple Type Definitions provide for:

  • In the case of ·primitive· datatypes, identifying a datatype with its definition in this specification.
  • In the case of ·constructed· datatypes, defining the datatype in terms of other datatypes.
  • Attaching a QName to the datatype.

4.1.1 The Simple Type Definition Schema Component

The Simple Type Definition schema component has the following properties:

Simple type definitions are identified by their {name} and {target namespace}.  Except for anonymous Simple Type Definitions (those with no {name}), Simple Type Definitions must be uniquely identified within a schema. Within a valid schema, each Simple Type Definition uniquely determines one datatype. The ·value space·, ·lexical space·, ·lexical mapping·, etc., of a Simple Type Definition are the ·value space·, ·lexical space·, etc., of the datatype uniquely determined (or "defined") by that Simple Type Definition.

If {variety} is ·atomic· then the ·value space· of the datatype defined will be a subset of the ·value space· of {base type definition} (which is a subset of the ·value space· of {primitive type definition}). If {variety} is ·list· then the ·value space· of the datatype defined will be the set of finite-length sequences of values from the ·value space· of {item type definition}. If {variety} is ·union· then the ·value space· of the datatype defined will be a subset (possibly an improper subset) of the union of the ·value spaces· of each Simple Type Definition in {member type definitions}.

If {variety} is ·atomic· then the {variety} of {base type definition} must be ·atomic·, unless the {base type definition} is anySimpleType. If {variety} is ·list· then the {variety} of {item type definition} must be either ·atomic· or ·union·, and if {item type definition} is ·union· then all its ·basic members· must be ·atomic·. If {variety} is ·union· then {member type definitions} must be a list of Simple Type Definitions.

The {facets} property determines the ·value space· and ·lexical space· of the datatype being defined by imposing constraints which must be satisfied by values and ·lexical representations·.

The {fundamental facets} property provides some basic information about the datatype being defined: its cardinality, whether an ordering is defined for it by this specification, whether it has upper and lower bounds, and whether it is numeric.

If {final} is the empty set then the type can be used in deriving other types; the explicit values restriction, list and union prevent further derivations of Simple Type Definitions by ·facet-based restriction·, ·list· and ·union· respectively; the explicit value extension prevents any derivation of Complex Type Definitions by extension.

The {context} property is only relevant for anonymous type definitions, for which its value is the component in which this type definition appears as the value of a property, e.g. {item type definition} or {base type definition}.

4.1.2 XML Representation of Simple Type Definition Schema Components

The XML representation for a Simple Type Definition schema component is a <simpleType> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: simpleType Element Information Item

<simpleType
  final = (#all | List of (list | union | restriction | extension))
  id = ID
  name = NCName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (restriction | list | union))
</simpleType>

<restriction
  base = QName
  id = ID
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, (simpleType?, (minExclusive | minInclusive | maxExclusive | maxInclusive | totalDigits | fractionDigits | maxScale | minScale | length | minLength | maxLength | enumeration | whiteSpace | pattern)*))
</restriction>

<list
  id = ID
  itemType = QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType?)
</list>

<union
  id = ID
  memberTypes = List of QName
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?, simpleType*)
</union>

Simple Type Definition Schema Component
Property
Representation
 
The actual value of the name [attribute], if present on the <simpleType> element, otherwise absent
 
The actual value of the targetNamespace [attribute] of the parent schema element information item, if present, otherwise absent.
 
The appropriate case among the following:
1 If the <restriction> alternative is chosen, then the type definition resolved to by the actual value of the base [attribute] of <restriction>, if present, otherwise the type definition corresponding to the <simpleType> among the [children] of <restriction>.
2 If the <list> or <union> alternative is chosen, then ·anySimpleType·.
 
A subset of {restriction, extension, list, union}, determined as follows. [Definition:]  Let FS be the actual value of the final [attribute], if present, otherwise the actual value of the finalDefault [attribute] of the ancestor schema element, if present, otherwise the empty string. Then the property value is the appropriate case among the following:
1 If ·FS· is the empty string, then the empty set;
2 If ·FS· is '#all', then {restriction, extension, list, union};
3 otherwise Consider ·FS· as a space-separated list, and include restriction if 'restriction' is in that list, and similarly for extension, list and union.
 
The appropriate case among the following:
1 If the name [attribute] is present, then absent
2 otherwise the appropriate case among the following:
2.1 If the parent element information item is <attribute>, then the corresponding Attribute Declaration
2.2 If the parent element information item is <element>, then the corresponding Element Declaration
2.3 If the parent element information item is <list> or <union>, then the Simple Type Definition corresponding to the grandparent <simpleType> element information item
2.4 otherwise (the parent element information item is <restriction>), the appropriate case among the following:
2.4.1 If the grandparent element information item is <simpleType>, then the Simple Type Definition corresponding to the grandparent
2.4.2 otherwise (the grandparent element information item is <simpleContent>), the Simple Type Definition which is the {content type} of the Complex Type Definition corresponding to the great-grandparent <complexType> element information item.
 
If the <list> alternative is chosen, then list, otherwise if the <union> alternative is chosen, then union, otherwise (the <restriction> alternative is chosen) the {variety} of the {base type definition}.
 
The appropriate case among the following:
1 If the <restriction> alternative is chosen, then a set of Constraining Facet components constituting a restriction of the {facets} of the {base type definition} with respect to a set of Constraining Facet components corresponding to the appropriate element information items among the [children] of <restriction> (i.e. those which specify facets, if any), as defined in Schema Component Constraint: Simple Type Restriction (Facets) .
2 If the <list> alternative is chosen, then a set with one member, a whiteSpace facet with {value} = collapse and {fixed} = true.
3 otherwise the empty set
 
A sequence of Annotation components corresponding to
1 the <annotation> element information item in the [children], if present;
2 If the <restriction> alternative is chosen, then the <annotation> element information item in the [children] of the <restriction>, if present;
3 If the <list> alternative is chosen, then the <annotation> element information item in the [children] of the <list>, if present;
4 If the <union> alternative is chosen, then the <annotation> element information item in the [children] of the <union>, if present.
[Definition:]  The ancestors of a type definition are its {base type definition} and the ·ancestors· of its {base type definition}. (The ancestors of a Simple Type Definition T in the type hierarchy are themselves type definitions; they are distinct from the XML elements which may be ancestors, in the XML document hierarchy, of the <simpleType> element which declares T.)
If the {variety} is atomic, the following additional property mapping also applies:
Property
Representation
 
If the corresponding Simple Type Definition is ·special· or ·primitive·, then as specified in Built-in Simple Type Definitions (§4.1.6), otherwise, amongFrom among the ·ancestors· of this Simple Type Definition, that Simple Type Definition which corresponds to a ·primitive· datatype.
Example
An electronic commerce schema might define a datatype called 'SKU' (the barcode number that appears on products) from the ·built-in· datatype string by supplying a value for the ·pattern· facet.
<simpleType name='SKU'>
    <restriction base='string'>
      <pattern value='\d{3}-[A-Z]{2}'/>
    </restriction>
</simpleType>
In this case, 'SKU' is the name of the new ·user-defined· datatype, string is its ·base type· and ·pattern· is the facet.
If the {variety} is list, the following additional property mappings also apply:
List Simple Type Definition Schema Component
Property
Representation
 
The appropriate case among the following:
1 If the {base type definition} is ·anySimpleType·, then the Simple Type Definition (a) resolved to by the actual value of the itemType [attribute] of <list>, or (b) corresponding to the <simpleType> among the [children] of <list>, whichever is present.
Note: AIn this case, a <list> element will invariably be present; it will invariably have either an itemType [attribute] or a <simpleType> [child], but not both.
2 otherwise (that is, the {base type definition} is not ·anySimpleType·), the {item type definition} of the {base type definition}.
Note: In this case, a <restriction> element will invariably be present.
Example
A system might want to store lists of floating point values.
<simpleType name='listOfFloat'>
  <list itemType='float'/>
</simpleType>
In this case, listOfFloat is the name of the new ·user-defined· datatype, float is its ·item type· and ·list· is the derivation method.
If the {variety} is union, the following additional property mappings also apply:
Property
Representation
 
The appropriate case among the following:
1 If the {base type definition} is ·anySimpleType·, then [Definition:]  define the explicit members as a sequence of the Simple Type Definitions (a) resolved to by the items in the actual value of the memberTypes [attribute] of <union>, if any and (b), corresponding to the <simpleType>s among the [children] of <union>, if any, in order. the sequence of (a) the Simple Type Definitions (a) resolved to by the items in the actual value of the memberTypes [attribute] of <union>, if any, and (b) those corresponding to the <simpleType>s among the [children] of <union>, if any, in order. The actual value is then formed by replacing any union Simple Type Definitions in the ·explicit members· with the members of their {member type definitions}, in order.
Note: AIn this case, a <union> element will invariably be present; it will invariably have either a memberTypes [attribute] or one or more <simpleType> [children], or both.
2 otherwise (that is, the {base type definition} is not ·anySimpleType·), the {member type definitions} of the {base type definition}.
Note: In this case, a <restriction> element will invariably be present.

Editorial Note: Priority Feedback Request

Note that the rule just given allows ·unions· to be members of other ·unions·. This is a change from version 1.0 of this specification, which prohibited ·unions· in {member type definitions} and replaced any reference to a ·union· M, in the XML declaration of a second ·union· U, with the members of M. This had the unintended consequence that that if M had facets they were lost, and U erroneously accepted values not accepted by M. In order to correct this error, this version of this specification allows ·unions· in {member type definitions} and removes the wording which replaced references to ·unions· with their members.

The XML Schema Working Group solicits input from implementors and users of this specification as to whether this change is an acceptable way of repairing the problem in version 1.0 of this specification, or whether it would be preferable to allow ·unions· as members of other ·unions· only if they have an empty {facets} property. If such a change would make this specification more (or less) attractive to users or implementors, please let us know.
Example
As an example, taken from a typical display oriented text markup language, one might want to express font sizes as an integer between 8 and 72, or with one of the tokens "small", "medium" or "large".  The ·union· Simple Type Definition below would accomplish that.
<xsd:attribute name="size">
  <xsd:simpleType>
    <xsd:union>
      <xsd:simpleType>
        <xsd:restriction base="xsd:positiveInteger">
          <xsd:minInclusive value="8"/>
          <xsd:maxInclusive value="72"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:simpleType>
        <xsd:restriction base="xsd:NMTOKEN">
          <xsd:enumeration value="small"/>
          <xsd:enumeration value="medium"/>
          <xsd:enumeration value="large"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:union>
  </xsd:simpleType>
</xsd:attribute>
<p>
<font size='large'>A header</font>
</p>
<p>
<font size='12'>this is a test</font>
</p>

A datatype can be ·constructed· from a ·primitive· datatype or an ·ordinary· datatype by one of three means: by ·facet-based restriction·, by ·list· or by ·union·.

4.1.4 Simple Type Definition Validation Rules

Validation Rule: Facet Valid
A value in a ·value space· is facet-valid with respect to a ·constraining facet· component if and only if:
1 the value is facet-valid with respect to the particular ·constraining facet· as specified below.
Validation Rule: Datatype Valid
A string is datatype-valid with respect to a datatype definition if and only if:
1 it ·matches· a ·literal· in the ·lexical space· of the datatype, determined as follows:
1.1 if ·pattern· is a member of {facets}, then the string must be pattern valid (§4.3.4.4);
1.2 if ·pattern· is not a member of {facets}, then
1.2.2 if {variety} is ·list· then the string must be a sequence of space-separated tokens, each of which ·match·es a ·literal· in the ·lexical space· of {item type definition}
1.2.3 if {variety} is ·union· then the string must ·match· a ·literal· in the ·lexical space· of at least one member of {member type definitions}
2 the value denoted by the ·literal· ·matched· in the previous step is a member of the ·value space· of the datatype, as determined by it being Facet Valid (§4.1.4) with respect to each member of {facets} (except for ·pattern·).
A ·literal· is datatype-valid with respect to a Simple Type Definition if and only if it is a member of the ·lexical space· of the corresponding datatype.
Note:  Since every value in the ·value space· is denoted by some ·literal·, and every ·literal· in the ·lexical space· maps to some value, the requirement that the ·literal· be in the ·lexical space· entails the requirement that the value it maps to should fulfill all of the constraints imposed by the {facets} of the datatype. If the datatype is a ·list·, the Datatype Valid constraint also entails that each whitespace-delimited token in the list be datatype-valid against the ·item type· of the list. If the datatype is a ·union·, the Datatype Valid constraint entails that the ·literal· be datatype-valid against at least one of the ·member types·.

That is, the constraints on Simple Type Definitions and on datatype derivation defined in this specification have as a consequence that a ·literal· L is datatype-valid with respect to a Simple Type Definition T if and only if either T corresponds to a ·special· datatype or all of the following are true:

1 If there is a pattern in {facets}, then L is pattern valid (§4.3.4.4) with respect to the pattern.
2 The appropriate case among the following is true:
2.1 If the {variety} of T is ·atomic·, then L is in the ·lexical space· of the {primitive type definition} of T, as defined in the appropriate section of this specification. Let V be the member of the ·value space· of the {primitive type definition} of T mapped to by L, as defined in the appropriate section of this specification.
2.2 If the {variety} of T is ·list·, then each space-delimited substring of L is Datatype Valid with respect to the {item type definition} of T. Let V be the sequence consisting of the values identified by Datatype Valid for each of those substrings, in order.
2.3 If the {variety} of T is ·union·, then L is Datatype Valid with respect to at least one member of the {member type definitions} of T. Let B be the ·active basic member· of T for L. Let V be the value identified by Datatype Valid for L with respect to B.
3 V, as determined by the appropriate sub-clause of clause 2 above, is Facet Valid (§4.1.4) with respect to each member of the {facets} of T which is not a pattern or a whiteSpace facet.

Note that whiteSpace facets do not take part in checking Datatype Valid. In cases where this specification is used in conjunction with schema-validation of XML documents, whiteSpace facets are used to normalize infoset values before the normalized results are checked for datatype validity. In the case of unions the whiteSpace facet to use is the one associated with B in clause 2.3 above.

4.1.5 Constraints on Simple Type Definition Schema Components

Schema Component Constraint: applicable facets
The ·constraining facets· which are allowed to be members of {facets} depend on the {variety} and {primitive type definition} of the type, as follows:

If {variety} is absent, then no facets are applicable. (This is true for anySimpleType.)

If {variety} is list, then the applicable facets are length, minLength, maxLength, pattern, enumeration, and whiteSpace.

If {variety} is union, then the applicable facets are pattern and enumeration.

If {variety} is atomic, and {primitive type definition} is absent then no facets are applicable. (This is true for anyAtomicType.)

In all other cases ({variety} is atomic and {primitive type definition} is not absent), then the applicable facets are shown in the table below.

{primitive type definition}applicable {facets}
stringlength, minLength, maxLength, pattern, enumeration, whiteSpace
booleanpattern, whiteSpace
floatpattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
doublepattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
decimaltotalDigits, fractionDigits, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
precisionDecimaltotalDigits, maxScale, minScale, pattern, whiteSpace, enumeration, maxInclusive, maxExclusive, minInclusive, minExclusive
durationpattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
dateTimepattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
timepattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
datepattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
gYearMonthpattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
gYearpattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
gMonthDaypattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
gDaypattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
gMonthpattern, enumeration, whiteSpace, maxInclusive, maxExclusive, minInclusive, minExclusive
hexBinarylength, minLength, maxLength, pattern, enumeration, whiteSpace
base64Binarylength, minLength, maxLength, pattern, enumeration, whiteSpace
anyURIlength, minLength, maxLength, pattern, enumeration, whiteSpace
QNamelength, minLength, maxLength, pattern, enumeration, whiteSpace
NOTATIONlength, minLength, maxLength, pattern, enumeration, whiteSpace

4.1.6 Built-in Simple Type Definitions

The Simple Type Definition of anySimpleType is present in every schema.  It has the following properties:

Property
Value
 
'anySimpleType'
 
'http://www.w3.org/2001/XMLSchema'
 
The empty set
 
absent
 
 
The empty set
 
The empty set
 
absent
 
absent
 
absent
 
absent
 
The empty sequence

The definition of anySimpleType is the root of the Simple Type Definition hierarchy; as such it mediates between the other simple type definitions, which all eventually trace back to it via their {base type definition} properties, and the definition of anyType, which is its {base type definition}.

The Simple Type Definition of anyAtomicType is present in every schema.  It has the following properties:

Property
Value
 
'anyAtomicType'
 
'http://www.w3.org/2001/XMLSchema'
 
The empty set
 
absent
 
 
The empty set
 
The empty set
 
atomic
 
absent
 
absent
 
absent
 
The empty sequence

Simple type definitions for all the built-in primitive datatypes, namely string, boolean, float, double, decimal, precisionDecimal, dateTime, duration, time, date, gMonth, gMonthDay, gDay, gYear, gYearMonth, hexBinary, base64Binary, anyURI are present by definition in every schema.  All have a very similar structure, with only the {name}, the {base type definition} (which is self-referential), the {fundamental facets} and in one case the {facets} varying from one to the next:

Property
Value
 
[as appropriate]
 
'http://www.w3.org/2001/XMLSchema'
 
 
The empty set
 
atomic
 
 
{a whiteSpace facet with {value} = collapse and {fixed} = true in all cases except string, which has {value} = preserve and {fixed} = false}
 
[as appropriate]
 
absent
 
absent
 
absent
 
The empty sequence

Similarly, Simple Type Definitions for all the built-in ·ordinary· datatypes are present by definition in every schema, with properties as specified in Other Built-in Datatypes (§3.4) and as represented in XML in Schema for Schema Documents (Datatypes) (normative) (§A)Illustrative XML representations for the built-in ordinary type definitions (§C.2).

Property
Value
 
[as appropriate]
 
'http://www.w3.org/2001/XMLSchema'
 
[as specified in the appropriate sub-section of Other Built-in Datatypes (§3.4)]
 
The empty set
 
[atomic or list, as specified in the appropriate sub-section of Other Built-in Datatypes (§3.4)]
 
[if {variety} is atomic, then the {primitive type definition} of the {base type definition}, otherwise absent]
 
[as specified in the appropriate sub-section of Other Built-in Datatypes (§3.4)]
 
[as specified in the appropriate sub-section of Other Built-in Datatypes (§3.4)]
 
absent
 
if {variety} is atomic, then absent, otherwise as specified in the appropriate sub-section of Other Built-in Datatypes (§3.4)]
 
absent
 
As shown in the XML representations of the ordinary built-in datatypes in Illustrative XML representations for the built-in ordinary type definitions (§C.2)

previous sub-section next sub-section4.2 Fundamental Facets

        4.2.1 ordered
        4.2.2 bounded
        4.2.3 cardinality
        4.2.4 numeric

[Definition:]  Each fundamental facet is a schema component that provides a limited piece of information about some aspect of each datatype.  For example, cardinality is a ·fundamental facet·.  Most ·fundamental facets· are given a value fixed with each primitive datatype's definition, and this value is not changed by subsequent ·derivations· (even when it would perhaps be reasonable to expect an application to give a more accurate value based on the constraining facets used to define the ·derivation·).  The cardinality and bounded facets are exceptions to this rule; their values may change as a result of certain ·derivations·.

Note: Schema components are identified by kind.  "Fundamental" is not a kind of component.  Each kind of ·fundamental facet· ("ordered", "bounded", etc.) is a separate kind of schema component.

The term [Definition:]  Fundamental Facet refers to any of the components defined in this section.

A ·fundamental facet· can occur only in the {fundamental facets} of a Simple Type Definition, and this is the only place where ·fundamental facet· components occur.    Each kind of ·fundamental facet· component occurs (once) in each Simple Type Definition's {fundamental facets} set.

Note: The value of any ·fundamental facet· component can always be calculated from other properties of its ·owner·.  Fundamental facets are not required for schema processing, but some applications use them.

4.2.1 ordered

Some datatypes have a nontrivial order relation associated with their value spaces (see Order (§2.2.3)).  (There is always a trivial partial ordering wherein every value pair that is not equal is incomparable, which could be associated with any value space.)  The ordered facet value is a "near-boolean": one of false, partial, and total, as prescribed in Fundamental Facets (§F.1) for ·primitive· datatypes; all ·ordinary· datatypes inherit this value without change.  The value for a ·list· is always false and the value for a ·union· is computed as described below.

A false value means no order is prescribed; a total value assures that the prescribed order is a total order; a partial value means that the prescribed order is a partial order, but not (for the primitive type in question) a total order. Derivation of new datatypes from datatypes with partial orders may impose constraints which make the effective ordering either a trivial order or a non-trivial total order, but the value of the ordered facet is not changed to reflect this.

[Definition:]  A ·value space·, and hence a datatype, is said to be ordered if this specification prescribes a non-trivial order for that ·value space·.

Note: Some of the "real-world" datatypes which are the basis for those defined herein are ordered in some applications, even though no order is prescribed for schema-processing purposes.  For example, boolean is sometimes ordered, and string and ·list· datatypes ·constructed· from ordered ·atomic· datatypes are sometimes given "lexical" orderings.  They are not ordered for schema-processing purposes.
4.2.1.1 The ordered Schema Component

{value} depends on the ·owner's· {variety}, {facets}, and {member type definitions}.

The appropriate case among the following must be true:
1 If the ·owner's· {variety} is atomic, then the appropriate case among the following must be true:
1.1 If the ·owner· is ·primitive·, then {value} is as specified in the table in Fundamental Facets (§F.1).
2 If the ·owner's· {variety} is list, then {value} is false.
3 otherwise the ·owner's· {variety} is union; the appropriate case among the following must be true:
3.1 If every member of the ·owner's· {member type definitions} ·basic member· of the ·owner· has {variety} atomic and has the same {primitive type definition}, then {value} is the same as the ordered component's {value} in that primitive type definition's {fundamental facets}.
3.2 If each member of the ·owner's· {member type definitions} has an ordered component in its {fundamental facets} whose {value} is false, then {value} is false.
3.3 otherwise {value} is partial.

4.2.2 bounded

Some ordered datatypes have the property that there is one value greater than or equal to every other value, and another that is less than or equal to every other value.  (In the case of ·ordinary· datatypes, these two values are not necessarily in the value space of the derived datatype, but they must be in the value space of the primitive datatype from which they have been derived.) The bounded facet value is boolean and is generally true for such bounded datatypes.  However, it will remain false when the mechanism for imposing such a bound is difficult to detect, as, for example, when the boundedness occurs because of derivation using a pattern component.

4.2.2.1 The bounded Schema Component

{value} depends on the ·owner's· {variety}, {facets} and {member type definitions}.

When the ·owner· is ·primitive·, {value} is as specified in the table in Fundamental Facets (§F.1).  Otherwise, when the ·owner's· {variety} is atomic, if one of minInclusive or minExclusive and one of maxInclusive or maxExclusive are members of the ·owner's· {facets} set, then {value} is true; otherwise {value} is false.

When the ·owner's· {variety} is list, {value} is false.

When the ·owner's· {variety} is union, if {value} is true for every member of the ·owner's· {member type definitions} set and all of these share a common ancestorall of the ·owner's· ·basic members· have the same {primitive type definition}, then {value} is true; otherwise {value} is false.

4.2.3 cardinality

Every value space has a specific number of members.  This number can be characterized as finite or infinite.  (Currently there are no datatypes with infinite value spaces larger than countable.)  The cardinality facet value is either finite or countably infinite and is generally finite for datatypes with finite value spaces.  However, it will remain countably infinite when the mechanism for causing finiteness is difficult to detect, as, for example, when finiteness occurs because of a derivation using a pattern component.

4.2.3.1 The cardinality Schema Component

{value} depends on the ·owner's· {variety}, {facets}, and {member type definitions}.

When the ·owner· is ·primitive·, {value} is as specified in the table in Fundamental Facets (§F.1).  Otherwise, when the ·owner's· {variety} is atomic, {value} is countably infinite unless any of the following conditions are true, in which case {value} is finite:

  1. the ·owner's· {base type definition}'s cardinality {value} is finite,
  2. at least one of length, maxLength, or totalDigits is a member of the ·owner's· {facets} set,
  3. all of the following are true:
    1. one of minInclusive or minExclusive is a member of the ·owner's· {facets} set
    2. one of maxInclusive or maxExclusive is a member of the ·owner's· {facets} set
    3. either of the following are true:
      1. fractionDigits is a member of the ·owner's· {facets} set
      2. {primitive type definition} is one of date, gYearMonth, gYear, gMonthDay, gDay or gMonth

When the ·owner's· {variety} is list, if length or both minLength and maxLength are members of the ·owner's· {facets} set and the ·owner's· {item type definition}'s cardinality {value} is finite then {value} is finite; otherwise {value} is countably infinite.

When the ·owner's· {variety} is union, if cardinality's {value} is finite for every member of the ·owner's· {member type definitions} set then {value} is finite, otherwise {value} is countably infinite.

previous sub-section 4.3 Constraining Facets

        4.3.1 length
        4.3.2 minLength
        4.3.3 maxLength
        4.3.4 pattern
        4.3.5 enumeration
        4.3.6 whiteSpace
        4.3.7 maxInclusive
        4.3.8 maxExclusive
        4.3.9 minExclusive
        4.3.10 minInclusive
        4.3.11 totalDigits
        4.3.12 fractionDigits
        4.3.13 maxScale
        4.3.14 minScale

[Definition:]  constraining facets are schema components whose values may be set or changed during ·derivation· (subject to facet-specific controls) to control various aspects of the derived datatype.  For example, whiteSpace is a ·constraining facet··Constraining Facets· are given a value as part of the ·derivation· when an ·ordinary· datatype is defined by ·restricting· a ·primitive· or ·ordinary· datatype; a few ·constraining facets· have default values that are also provided for ·primitive· datatypes.

Note: Schema components are identified by kind.  "Constraining" is not a kind of component.  Each kind of ·constraining facet· ("whiteSpace", "length", etc.) is a separate kind of schema component.

The term [Definition:]  Constraining Facet refers to any of the components defined in this section.

4.3.1 length

[Definition:]   length is the number of units of length, where units of length varies depending on the type that is being derived from. The value of length ·must· be a nonNegativeInteger.

For string and datatypes derived from string, length is measured in units of characters as defined in [XML]. For anyURI, length is measured in units of characters (as for string). For hexBinary and base64Binary and datatypes derived from them, length is measured in octets (8 bits) of binary data. For datatypes ·constructed· by ·list·, length is measured in number of list items.

Note:  For string and datatypes derived from string, length will not always coincide with "string length" as perceived by some users or with the number of storage units in some digital representation. Therefore, care should be taken when specifying a value for length and in attempting to infer storage requirements from a given value for length.

·length· provides for:

Example
The following is the definition of a ·user-defined· datatype to represent product codes which must be exactly 8 characters in length.  By fixing the value of the length facet we ensure that types derived from productCode can change or set the values of other facets, such as pattern, but cannot change the length.
<simpleType name='productCode'>
   <restriction base='string'>
     <length value='8' fixed='true'/>
   </restriction>
</simpleType>
4.3.1.2 XML Representation of length Schema Components

The XML representation for a length schema component is a <length> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: length Element Information Item

<length
  fixed = boolean : false
  id = ID
  value = nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</length>

length Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.1.3 length Validation Rules
Validation Rule: Length Valid
A value in a ·value space· is facet-valid with respect to ·length· if and only if:
1 if the {variety} is ·atomic· then
1.1 if {primitive type definition} is string or anyURI, then the length of the value, as measured in characters ·must· be equal to {value};
1.2 if {primitive type definition} is hexBinary or base64Binary, then the length of the value, as measured in octets of the binary data, ·must· be equal to {value};
1.3 if {primitive type definition} is QName or NOTATION, then any {value} is facet-valid.
2 if the {variety} is ·list·, then the length of the value, as measured in list items, ·must· be equal to {value}

The use of ·length· on QName, NOTATION, and datatypes derived from them is deprecated.  Future versions of this specification may remove this facet for these datatypes.

4.3.1.4 Constraints on length Schema Components
Schema Component Constraint: length and minLength or maxLength
If length is a member of {facets} then
1 It is an error for minLength to be a member of {facets} unless
1.1 the {value} of minLength <= the {value} of length and
1.2 there is type definition from which this one is derived by one or more ·restriction· steps in which minLength has the same {value} and length is not specified.
2 It is an error for maxLength to be a member of {facets} unless
2.1 the {value} of length <= the {value} of maxLength and
2.2 there is type definition from which this one is derived by one or more restriction steps in which maxLength has the same {value} and length is not specified.

4.3.2 minLength

[Definition:]   minLength is the minimum number of units of length, where units of length varies depending on the type that is being derived from. The value of minLength  ·must· be a nonNegativeInteger.

For string and datatypes derived from string, minLength is measured in units of characters as defined in [XML]. For hexBinary and base64Binary and datatypes derived from them, minLength is measured in octets (8 bits) of binary data. For datatypes ·constructed· by ·list·, minLength is measured in number of list items.

Note:  For string and datatypes derived from string, minLength will not always coincide with "string length" as perceived by some users or with the number of storage units in some digital representation. Therefore, care should be taken when specifying a value for minLength and in attempting to infer storage requirements from a given value for minLength.

·minLength· provides for:

Example
The following is the definition of a ·user-defined· datatype which requires strings to have at least one character (i.e., the empty string is not in the ·value space· of this datatype).
<simpleType name='non-empty-string'>
  <restriction base='string'>
    <minLength value='1'/>
  </restriction>
</simpleType>
4.3.2.2 XML Representation of minLength Schema Component

The XML representation for a minLength schema component is a <minLength> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: minLength Element Information Item

<minLength
  fixed = boolean : false
  id = ID
  value = nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</minLength>

minLength Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.2.3 minLength Validation Rules
Validation Rule: minLength Valid
A value in a ·value space· is facet-valid with respect to ·minLength·, determined as follows:
1 if the {variety} is ·atomic· then
1.1 if {primitive type definition} is string or anyURI, then the length of the value, as measured in characters ·must· be greater than or equal to {value};
1.2 if {primitive type definition} is hexBinary or base64Binary, then the length of the value, as measured in octets of the binary data, ·must· be greater than or equal to {value};
1.3 if {primitive type definition} is QName or NOTATION, then any {value} is facet-valid.
2 if the {variety} is ·list·, then the length of the value, as measured in list items, ·must· be greater than or equal to {value}

The use of ·minLength· on QName, NOTATION, and datatypes derived from them is deprecated.  Future versions of this specification may remove this facet for these datatypes.

4.3.3 maxLength

[Definition:]   maxLength is the maximum number of units of length, where units of length varies depending on the type that is being derived from. The value of maxLength  ·must· be a nonNegativeInteger.

For string and datatypes derived from string, maxLength is measured in units of characters as defined in [XML]. For hexBinary and base64Binary and datatypes derived from them, maxLength is measured in octets (8 bits) of binary data. For datatypes ·constructed· by ·list·, maxLength is measured in number of list items.

Note:  For string and datatypes derived from string, maxLength will not always coincide with "string length" as perceived by some users or with the number of storage units in some digital representation. Therefore, care should be taken when specifying a value for maxLength and in attempting to infer storage requirements from a given value for maxLength.

·maxLength· provides for:

Example
The following is the definition of a ·user-defined· datatype which might be used to accept form input with an upper limit to the number of characters that are acceptable.
<simpleType name='form-input'>
  <restriction base='string'>
    <maxLength value='50'/>
  </restriction>
</simpleType>
4.3.3.2 XML Representation of maxLength Schema Components

The XML representation for a maxLength schema component is a <maxLength> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: maxLength Element Information Item

<maxLength
  fixed = boolean : false
  id = ID
  value = nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</maxLength>

maxLength Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.3.3 maxLength Validation Rules
Validation Rule: maxLength Valid
A value in a ·value space· is facet-valid with respect to ·maxLength·, determined as follows:
1 if the {variety} is ·atomic· then
1.1 if {primitive type definition} is string or anyURI, then the length of the value, as measured in characters ·must· be less than or equal to {value};
1.2 if {primitive type definition} is hexBinary or base64Binary, then the length of the value, as measured in octets of the binary data, ·must· be less than or equal to {value};
1.3 if {primitive type definition} is QName or NOTATION, then any {value} is facet-valid.
2 if the {variety} is ·list·, then the length of the value, as measured in list items, ·must· be less than or equal to {value}

The use of ·maxLength· on QName, NOTATION, and datatypes derived from them is deprecated.  Future versions of this specification may remove this facet for these datatypes.

4.3.4 pattern

[Definition:]   pattern is a constraint on the ·value space· of a datatype which is achieved by constraining the ·lexical space· to ·literals· which match each member of a set of patterns.  The value of pattern  must be a set of ·regular expressions·.

·pattern· provides for:

Example
The following is the definition of a ·user-defined· datatype which is a better representation of postal codes in the United States, by limiting strings to those which are matched by a specific ·regular expression·.
<simpleType name='better-us-zipcode'>
  <restriction base='string'>
    <pattern value='[0-9]{5}(-[0-9]{4})?'/>
  </restriction>
</simpleType>
4.3.4.2 XML Representation of pattern Schema Components

The XML representation for a pattern schema component is a <pattern> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: pattern Element Information Item

<pattern
  id = ID
  value = string
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</pattern>

pattern Schema Component
Property
Representation
 
[Definition:]  Let R be a regular expression given by the appropriate case among the following:
1 If there is only one <pattern> among the [children] of a <restriction>, then the actual value of its value [attribute]
2 otherwise the concatenation of the actual values of all the <pattern> [children]'s value [attributes], in order, separated by '|', so forming a single regular expression with multiple ·branches·.
The value is then given by the appropriate case among the following:
1 If the {base type definition} of the ·owner· has a pattern facet among its {facets}, then the union of that pattern facet's {value} and {·R·}
2 otherwise just {·R·}
 
A (possibly empty) sequence of Annotation components, one for each <annotation> among the [children] of the <pattern>s among the [children] of a <restriction>, in order.
Note: The {value} property will only have more than one member when ·facet-based restriction· involves a pattern facet at more than one step in a type derivation. During validation, lexical forms will be checked against every member of the resulting {value}, effectively creating a conjunction of patterns.

In summary, ·pattern· facets specified on the same step in a type derivation are ORed together, while ·pattern· facets specified on different steps of a type derivation are ANDed together.

Thus, to impose two ·pattern· constraints simultaneously, schema authors may either write a single ·pattern· which expresses the intersection of the two ·pattern·s they wish to impose, or define each ·pattern· on a separate type derivation step.

4.3.4.4 pattern Validation Rules
Validation Rule: pattern valid
A ·literal· in a ·lexical space· is facet-valid with respect to ·pattern· if and only if for each ·regular expression· in its {value}, the ·literal· is among the set of character sequences denoted by the ·regular expression·.
Note:  As noted in Datatype (§2.1), certain uses of the ·pattern· facet may eliminate from the lexical space the canonical forms of some values in the value space; this can be inconvenient for applications which write out the canonical form of a value and rely on being able to read it in again as a legal lexical form. This specification provides no recourse in such situations; applications are free to deal with it as they see fit. Caution is advised.

4.3.5 enumeration

[Definition:]   enumeration constrains the ·value space· to a specified set of values.

enumeration does not impose an order relation on the ·value space· it creates; the value of the ·ordered· property of the derived datatype remains that of the datatype from which it is derived.

·enumeration· provides for:

Example
The following example is a Simple Type Definition for a ·user-defined· datatype which limits the values of dates to the three US holidays enumerated. This Simple Type Definition would appear in a schema authored by an "end-user" and shows how to define a datatype by enumerating the values in its ·value space·.  The enumerated values must be type-valid ·literals· for the ·base type·.
<simpleType name='holidays'>
    <annotation>
        <documentation>some US holidays</documentation>
    </annotation>
    <restriction base='gMonthDay'>
      <enumeration value='--01-01'>
        <annotation>
            <documentation>New Year's day</documentation>
        </annotation>
      </enumeration>
      <enumeration value='--07-04'>
        <annotation>
            <documentation>4th of July</documentation>
        </annotation>
      </enumeration>
      <enumeration value='--12-25'>
        <annotation>
            <documentation>Christmas</documentation>
        </annotation>
      </enumeration>
    </restriction>
</simpleType>
4.3.5.2 XML Representation of enumeration Schema Components

The XML representation for an enumeration schema component is an <enumeration> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: enumeration Element Information Item

<enumeration
  id = ID
  value = anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</enumeration>

enumeration Schema Component
Property
Representation
 
The appropriate case among the following:
1 If there is only one <enumeration> among the [children] of a <restriction>, then a set with one member, the actual value of its value [attribute].
2 otherwise a set of the actual values of all the <enumeration> [children]'s value [attributes].
 
A (possibly empty) sequence of Annotation components, one for each <annotation> among the [children] of the <enumeration>s among the [children] of a <restriction>, in order.
4.3.5.4 enumeration Validation Rules
Validation Rule: enumeration valid
A value in a ·value space· is facet-valid with respect to ·enumeration· if and only if the value is one of the values specified in {value}.

4.3.6 whiteSpace

[Definition:]   whiteSpace constrains the ·value space· of types derived from string such that the various behaviors specified in Attribute Value Normalization in [XML] are realized.  The value of whiteSpace must be one of {preserve, replace, collapse}.

preserve
No normalization is done, the value is not changed (this is the behavior required by [XML] for element content)
replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are replaced with #x20 (space)
collapse
After the processing implied by replace, contiguous sequences of #x20's are collapsed to a single #x20, and leading and trailing #x20's are removed.
Note:  The notation #xA used here (and elsewhere in this specification) represents the Universal Character Set (UCS) code point hexadecimal A (line feed), which is denoted by U+000A.  This notation is to be distinguished from &#xA;, which is the XML character reference to that same UCS code point.

whiteSpace is applicable to all ·atomic· and ·list· datatypes.  For all ·atomic· datatypes other than string (and types derived by ·facet-based restriction· from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type derived by ·facet-based restriction· from string the value of whiteSpace can be any of the three legal values.  For all datatypes ·constructed· by ·list· the value of whiteSpace is collapse and cannot be changed by a schema author.  For all datatypes ·constructed· by ·union·  whiteSpace does not apply directly; however, the normalization behavior of ·union· types is controlled by the value of whiteSpace on that one of the ·member types··basic members· against which the ·union· is successfully validated.

Note:  For more information on whiteSpace, see the discussion on white space normalization in Schema Component Details in [XML Schema Part 1: Structures].

·whiteSpace· provides for:

  • Constraining a ·value space· according to the white space normalization rules.
Example
The following example is the Simple Type Definition for the ·built-in· token datatype.
<simpleType name='token'>
    <restriction base='normalizedString'>
      <whiteSpace value='collapse'/>
    </restriction>
</simpleType>
Note: The values "replace" and "collapse" may appear to provide a convenient way to "unwrap" text (i.e. undo the effects of pretty-printing and word-wrapping). In some cases, especially highly constrained data consisting of lists of artificial tokens such as part numbers or other identifiers, this appearance is correct. For natural-language data, however, the whitespace processing prescribed for these values is not only unreliable but will systematically remove the information needed to perform unwrapping correctly. For Asian scripts, for example, a correct unwrapping process will replace line boundaries not with blanks but with zero-width separators or nothing. In consequence, it is normally unwise to use these values for natural-language data, or for any data other than lists of highly constrained tokens.
4.3.6.2 XML Representation of whiteSpace Schema Components

The XML representation for a whiteSpace schema component is a <whiteSpace> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: whiteSpace Element Information Item

<whiteSpace
  fixed = boolean : false
  id = ID
  value = (collapse | preserve | replace)
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</whiteSpace>

whiteSpace Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.6.4 Constraints on whiteSpace Schema Components
Schema Component Constraint: whiteSpace valid restriction
It is an ·error· if whiteSpace is among the members of {facets} of {base type definition} and any of the following conditions is true:
1 {value} is replace or preserve and the {value} of the parent whiteSpace is collapse
2 {value} is preserve and the {value} of the parent whiteSpace is replace

4.3.7 maxInclusive

[Definition:]   maxInclusive is the inclusive upper bound of the ·value space· for a datatype with the ·ordered· property.  The value of maxInclusive ·must· be equal to some value in the ·value space· of the ·base type·.

·maxInclusive· provides for:

  • Constraining a ·value space· to values with a specific inclusive upper bound.
Example
The following is the definition of a ·user-defined· datatype which limits values to integers less than or equal to 100, using ·maxInclusive·.
<simpleType name='one-hundred-or-less'>
  <restriction base='integer'>
    <maxInclusive value='100'/>
  </restriction>
</simpleType>
4.3.7.2 XML Representation of maxInclusive Schema Components

The XML representation for a maxInclusive schema component is a <maxInclusive> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: maxInclusive Element Information Item

<maxInclusive
  fixed = boolean : false
  id = ID
  value = anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</maxInclusive>

{value} ·must· be equal to some value in the ·value space· of {base type definition}.
maxInclusive Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.7.3 maxInclusive Validation Rules
Validation Rule: maxInclusive Valid
A value in an ·ordered· ·value space· is facet-valid with respect to ·maxInclusive·, determined as follows:
1 if the {value} property of the numeric component in {fundamental facets} is true, then the value ·must· be numerically less than or equal to {value};
2 if the {value} property of the numeric component in {fundamental facets} is false (i.e., {base type definition} is one of the date and time related datatypes), then the value ·must· be chronologically less than or equal to {value};
4.3.7.4 Constraints on maxInclusive Schema Components
Schema Component Constraint: minInclusive <= maxInclusive
It is an ·error· for the value specified for ·minInclusive· to be greater than the value specified for ·maxInclusive· for the same datatype.
Schema Component Constraint: maxInclusive valid restriction
It is an ·error· if any of the following conditions is true:
1 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater than the {value} of that maxInclusive.
2 maxExclusive is among the members of {facets} of {base type definition} and {value} is greater than or equal to the {value} of that maxExclusive.
3 minInclusive is among the members of {facets} of {base type definition} and {value} is less than the {value} of that minInclusive.
4 minExclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of that minExclusive.

4.3.8 maxExclusive

[Definition:]   maxExclusive is the exclusive upper bound of the ·value space· for a datatype with the ·ordered· property.  The value of maxExclusive  ·must· be equal to some value in the ·value space· of the ·base type· or be equal to {value} in {base type definition}.

·maxExclusive· provides for:

  • Constraining a ·value space· to values with a specific exclusive upper bound.
Example
The following is the definition of a ·user-defined· datatype which limits values to integers less than or equal to 100, using ·maxExclusive·.
<simpleType name='less-than-one-hundred-and-one'>
  <restriction base='integer'>
    <maxExclusive value='101'/>
  </restriction>
</simpleType>
Note that the ·value space· of this datatype is identical to the previous one (named 'one-hundred-or-less').
4.3.8.2 XML Representation of maxExclusive Schema Components

The XML representation for a maxExclusive schema component is a <maxExclusive> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: maxExclusive Element Information Item

<maxExclusive
  fixed = boolean : false
  id = ID
  value = anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</maxExclusive>

{value} ·must· be equal to some value in the ·value space· of {base type definition}.
maxExclusive Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.8.3 maxExclusive Validation Rules
Validation Rule: maxExclusive Valid
A value in an ·ordered· ·value space· is facet-valid with respect to ·maxExclusive·, determined as follows:
1 if the {value} property of the numeric component in {fundamental facets} is true, then the value ·must· be numerically less than {value};
2 if the {value} property of the numeric component in {fundamental facets} is false (i.e., {base type definition} is one of the date and time related datatypes), then the value ·must· be chronologically less than {value};
4.3.8.4 Constraints on maxExclusive Schema Components
Schema Component Constraint: minExclusive <= maxExclusive
It is an ·error· for the value specified for ·minExclusive· to be greater than the value specified for ·maxExclusive· for the same datatype.
Schema Component Constraint: maxExclusive valid restriction
It is an ·error· if any of the following conditions is true:
1 maxExclusive is among the members of {facets} of {base type definition} and {value} is greater than the {value} of that maxExclusive.
2 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater than the {value} of that maxInclusive.
3 minInclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of that minInclusive.
4 minExclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of that minExclusive.

4.3.9 minExclusive

[Definition:]   minExclusive is the exclusive lower bound of the ·value space· for a datatype with the ·ordered· property. The value of minExclusive ·must· be equal to some value in the ·value space· of the ·base type· or be equal to {value} in {base type definition}.

·minExclusive· provides for:

  • Constraining a ·value space· to values with a specific exclusive lower bound.
Example
The following is the definition of a ·user-defined· datatype which limits values to integers greater than or equal to 100, using ·minExclusive·.
<simpleType name='more-than-ninety-nine'>
  <restriction base='integer'>
    <minExclusive value='99'/>
  </restriction>
</simpleType>
Note that the ·value space· of this datatype is identical to the following one (named 'one-hundred-or-more').
4.3.9.2 XML Representation of minExclusive Schema Components

The XML representation for a minExclusive schema component is a <minExclusive> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: minExclusive Element Information Item

<minExclusive
  fixed = boolean : false
  id = ID
  value = anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</minExclusive>

{value} ·must· be equal to some value in the ·value space· of {base type definition}.
minExclusive Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.9.3 minExclusive Validation Rules
Validation Rule: minExclusive Valid
A value in an ·ordered· ·value space· is facet-valid with respect to ·minExclusive· if and only if:
1 if the {value} property of the numeric component in {fundamental facets} is true, then the value ·must· be numerically greater than {value};
2 if the {value} property of the numeric component in {fundamental facets} is false (i.e., {base type definition} is one of the date and time related datatypes), then the value ·must· be chronologically greater than {value};
4.3.9.4 Constraints on minExclusive Schema Components
Schema Component Constraint: minInclusive and minExclusive
It is an ·error· for both ·minInclusive· and ·minExclusive· to be specified for the same datatypein the same derivation step of a Simple Type Definition.
Schema Component Constraint: minExclusive < maxInclusive
It is an ·error· for the value specified for ·minExclusive· to be greater than or equal to the value specified for ·maxInclusive· for the same datatype.
Schema Component Constraint: minExclusive valid restriction
It is an ·error· if any of the following conditions is true:
1 minExclusive is among the members of {facets} of {base type definition} and {value} is less than the {value} of that minExclusive.
2 minInclusive is among the members of {facets} of {base type definition} and {value} is less than the {value} of that minInclusive.
3 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater than or equal to the {value} of that maxInclusive.
4 maxExclusive is among the members of {facets} of {base type definition} and {value} is greater than or equal to the {value} of that maxExclusive.

4.3.10 minInclusive

[Definition:]   minInclusive is the inclusive lower bound of the ·value space· for a datatype with the ·ordered· property.  The value of minInclusive  ·must· be equal to some value in the ·value space· of the ·base type·.

·minInclusive· provides for:

  • Constraining a ·value space· to values with a specific inclusive lower bound.
Example
The following is the definition of a ·user-defined· datatype which limits values to integers greater than or equal to 100, using ·minInclusive·.
<simpleType name='one-hundred-or-more'>
  <restriction base='integer'>
    <minInclusive value='100'/>
  </restriction>
</simpleType>
4.3.10.2 XML Representation of minInclusive Schema Components

The XML representation for a minInclusive schema component is a <minInclusive> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: minInclusive Element Information Item

<minInclusive
  fixed = boolean : false
  id = ID
  value = anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</minInclusive>

{value} ·must· be equal to some value in the ·value space· of {base type definition}.
minInclusive Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.10.3 minInclusive Validation Rules
Validation Rule: minInclusive Valid
A value in an ·ordered· ·value space· is facet-valid with respect to ·minInclusive· if and only if:
1 if the {value} property of the numeric component in {fundamental facets} is true, then the value ·must· be numerically greater than or equal to {value};
2 if the {value} property of the numeric component in {fundamental facets} is false (i.e., {base type definition} is one of the date and time related datatypes), then the value ·must· be chronologically greater than or equal to {value};
4.3.10.4 Constraints on minInclusive Schema Components
Schema Component Constraint: minInclusive < maxExclusive
It is an ·error· for the value specified for ·minInclusive· to be greater than or equal to the value specified for ·maxExclusive· for the same datatype.
Schema Component Constraint: minInclusive valid restriction
It is an ·error· if any of the following conditions is true:
1 minInclusive is among the members of {facets} of {base type definition} and {value} is less than the {value} of that minInclusive.
2 maxInclusive is among the members of {facets} of {base type definition} and {value} is greater the {value} of that maxInclusive.
3 minExclusive is among the members of {facets} of {base type definition} and {value} is less than or equal to the {value} of that minExclusive.
4 maxExclusive is among the members of {facets} of {base type definition} and {value} is greater than or equal to the {value} of that maxExclusive.

4.3.11 totalDigits

[Definition:]   totalDigits restricts the magnitude and ·arithmetic precision· of values in the ·value spaces· of precisionDecimal and decimal and datatypes derived from them. The effect must be described separately for the two primitive types.

For decimal, if the {value} of totalDigits is t, the effect is to require that values be equal to i / 10n, for some integers i and n, with | i | < 10t and 0 ≤ n ≤ t. This has as a consequence that the values are expressible using at most t digits in decimal notation.

For precisionDecimal, values with ·numericalValue· of nV and ·arithmeticPrecision· of aP, if the {value} of totalDigits is t, the effect is to require that (aP + 1 + log10(| nV |) ·div· 1) ≤ t, for values other than zero, NaN, and the infinities. This means in effect that values are expressible in scientific notation using at most t digits for the coefficient.

The {value} of totalDigits must be a positiveInteger.

The term 'totalDigits' is chosen to reflect the fact that it restricts the ·value space· to those values that can be represented lexically using at most totalDigits digits in decimal notation, or at most totalDigits digits for the coefficient, in scientific notation.  Note that it does not restrict the ·lexical space· directly; a lexical representation that adds non-significant leading or trailing zero digits is still permitted. It also has no effect on the values NaN, INF, and -INF.

4.3.11.2 XML Representation of totalDigits Schema Components

The XML representation for a totalDigits schema component is a <totalDigits> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: totalDigits Element Information Item

<totalDigits
  fixed = boolean : false
  id = ID
  value = positiveInteger
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</totalDigits>

totalDigits Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.11.3 totalDigits Validation Rules
Validation Rule: totalDigits Valid
A value v is facet-valid with respect to a totalDigits facet with a {value} of t if and only if one of the following is true:
1 v is a precisionDecimal value with ·numericalValue· of positiveInfinity, negativeInfinity, notANumber, or zero.
2 v is a precisionDecimal value with ·numericalValue· of nV and ·arithmeticPrecision· of aP, and is not NaN, INF, -INF, or zero, and (aP + 1 + log10(| nV |) ·div· 1) ≤ t.
3 v is a decimal value equal to i / 10n, for some integers i and n, with | i | < 10t and 0 ≤ n ≤ t.

4.3.12 fractionDigits

[Definition:]   fractionDigits places an upper limit on the ·arithmetic precision· of decimal values: if the {value} of fractionDigits = f, then the value space is restricted to values equal to i / 10n for some integers i and n and 0 ≤ nf. The value of fractionDigits ·must· be a nonNegativeInteger

The term fractionDigits is chosen to reflect the fact that it restricts the ·value space· to those values that can be represented lexically in decimal notation using at most fractionDigits to the right of the decimal point. Note that it does not restrict the ·lexical space· directly; a lexical representation that adds non-significant leading or trailing zero digits is still permitted.

Example
The following is the definition of a ·user-defined· datatype which could be used to represent the magnitude of a person's body temperature on the Celsius scale. This definition would appear in a schema authored by an "end-user" and shows how to define a datatype by specifying facet values which constrain the range of the ·base type·.
<simpleType name='celsiusBodyTemp'>
  <restriction base='decimal'>
    <totalDigits value='4'/>
    <fractionDigits value='1'/>
    <minInclusive value='36.4'/>
    <maxInclusive value='40.5'/>
  </restriction>
</simpleType>
4.3.12.2 XML Representation of fractionDigits Schema Components

The XML representation for a fractionDigits schema component is a <fractionDigits> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: fractionDigits Element Information Item

<fractionDigits
  fixed = boolean : false
  id = ID
  value = nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</fractionDigits>

fractionDigits Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.

4.3.13 maxScale

[Definition:]   maxScale places an upper limit on the ·arithmetic precision· of precisionDecimal values: if the {value} of maxScale = m, then only values with ·arithmeticPrecision·m are retained in the ·value space·. As a consequence, every value in the value space will have ·numericalValue· equal to i / 10n for some integers i and n, with nm. The {value} of maxScale must be an integer. If it is negative, the numeric values of the datatype are restricted to multiples of 10 (or 100, or …).

The term 'maxScale' is chosen to reflect the fact that it restricts the ·value space· to those values that can be represented lexically in scientific notation using an integer coefficient and a scale (or negative exponent) no greater than maxScale. (It has nothing to do with the use of the term 'scale' to denote the radix or base of a notation.) Note that maxScale does not restrict the ·lexical space· directly; a lexical representation that adds non-significant leading or trailing zero digits, or that uses a lower exponent with a non-integer coefficient is still permitted.

Example
The following is the definition of a user-defined datatype which could be used to represent a floating-point decimal datatype which allows seven decimal digits for the coefficient and exponents between −95 and 96. Note that the scale is −1 times the exponent.
<simpleType name='decimal32'>
  <restriction base='precisionDecimal'>
    <totalDigits value='7'/>
    <maxScale value='95'/>
    <minScale value='-96'/>
  </restriction>
</simpleType>
4.3.13.2 XML Representation of maxScale Schema Components

The XML representation for a maxScale schema component is a <maxScale> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: maxScale Element Information Item

<maxScale
  fixed = boolean : false
  id = ID
  value = integer
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</maxScale>

maxScale Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.13.3 maxScale Validation Rules
Validation Rule: maxScale Valid
A precisionDecimal value v is facet-valid with respect to maxScale if and only if one of the following is true:
1 v has ·arithmeticPrecision· less than or equal to the {value} of maxScale.
2 The ·arithmeticPrecision· of v is absent.

4.3.14 minScale

[Definition:]   minScale places a lower limit on the ·arithmetic precision· of precisionDecimal values. If the {value} of minScale is m, then the value space is restricted to values with ·arithmeticPrecision·m. As a consequence, every value in the value space will have ·numericalValue· equal to i / 10n for some integers i and n, with nm.

The term minScale is chosen to reflect the fact that it restricts the ·value space· to those values that can be represented lexically in exponential form using an integer coefficient and a scale (negative exponent) at least as large as minScale. Note that it does not restrict the ·lexical space· directly; a lexical representation that adds additional leading zero digits, or that uses a larger exponent (and a correspondingly smaller coefficient) is still permitted.

Example
The following is the definition of a user-defined datatype which could be used to represent amounts in a decimal currency; it corresponds to a SQL column definition of DECIMAL(8,2). The effect is to allow values between -999,999.99 and 999,999.99, with a fixed interval of 0.01 between values.
<simpleType name='price'>
  <restriction base='precisionDecimal'>
    <totalDigits value='8'/>
    <minScale value='2'/>
    <maxScale value='2'/>
  </restriction>
</simpleType>
4.3.14.2 XML Representation of minScale Schema Components

The XML representation for a minScale schema component is a <minScale> element information item. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary: minScale Element Information Item

<minScale
  fixed = boolean : false
  id = ID
  value = integer
  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</minScale>

minScale Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
The annotations corresponding to all the <annotation> element information items in the [children], if any.
4.3.14.3 minScale Validation Rules
Validation Rule: minScale Valid
A precisionDecimal value v is facet-valid with respect to minScale if and only if one of the following is true:
1 v has ·arithmeticPrecision· greater than or equal to the {value} of minScale.
2 The ·arithmeticPrecision· of v is absent.

5 Conformance

This specification describes two levels of conformance for datatype processors.  The first is required of all processors.  Support for the other will depend on the application environments for which the processor is intended.

[Definition:]   Minimally conforming processors ·must· completely and correctly implement the ·Constraint on Schemas· and ·Validation Rule·.

[Definition:]  Processors which accept schemas in the form of XML documents as described in XML Representation of Simple Type Definition Schema Components (§4.1.2) (and other relevant portions of Datatype components (§4)) are additionally said to provide conformance to the XML Representation of Schemas, and ·must·, when processing schema documents, completely and correctly implement all ·Schema Representation Constraint·s in this specification, and ·must· adhere exactly to the specifications in XML Representation of Simple Type Definition Schema Components (§4.1.2) (and other relevant portions of Datatype components (§4)) for mapping the contents of such documents to schema components for use in validation.

Note: By separating the conformance requirements relating to the concrete syntax of XML schema documents, this specification admits processors which validate using schemas stored in optimized binary representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code such as C or Java.  Such processors can be said to be ·minimally conforming· but not necessarily in ·conformance to the XML Representation of Schemas·.

5.1 Partial Implementation of Infinite Datatypes

Some ·primitive· datatypes defined in this specification have infinite ·value spaces·; no finite implementation can completely handle all their possible values. For some such datatypes, minimum implementation limits are specified below. For other infinite types such as string, hexBinary, and base64Binary, no minimum implementation limits are specified.

When this specification is used in the context of other languages (as it is, for example, by [XML Schema Part 1: Structures]), the host language may specify other minimum implementation limits.

When presented with a literal or value exceeding the capacity of its partial implementation of a datatype, a minimally conforming implementation of this specification will sometimes be unable to determine with certainty whether the value is datatype-valid or not. Sometimes it will be unable to represent the value correctly through its interface to any downsteam application.

When either of these is so, a conforming processor must indicate to the user and/or downstream application that it cannot process the input data with assured correctness (much as it would indicate if it ran out of memory). When the datatype validity of a value or literal is uncertain because it exceeds the capacity of a partial implementation, the literal or value must not be treated as invalid, and the unsupported value must not be quietly changed to a supported value.

This specification does not constrain the method used to indicate that a literal or value in the input data has exceeded the capacity of the implementation, or the form such indications take.

·Minimally conforming· processors which set an application- or implementation-defined limit on the size of the values supported must clearly document that limit.

These are the partial-implementation ·minimal conformance· requirements:

  • All ·minimally conforming· processors must support decimal values whose absolute value is less than 1016 (i.e., those expressible with sixteen total digits).
  • All ·minimally conforming· processors must support nonnegative ·year· values less than 10000 (i.e., those expressible with four digits).
  • All ·minimally conforming· processors must support ·second· values to milliseconds (i.e. those expressible with three fraction digits).
  • All ·minimally conforming· processors must support fractional-second duration values to milliseconds (i.e. those expressible with three fraction digits).
  • All ·minimally conforming· processors must support duration values with from -2,000,000,000 to 2,000,000,000 months and from -2,000,000 to 2,000,000 seconds.
  • All ·minimally conforming· processors must support all precisionDecimal values in the ·value space· of the otherwise unconstrained derived datatype for which totalDigits is set to sixteen, maxScale to 369, and minScale to −398.
    Note: The conformance limits given in the text correspond to those of the decimal64 type defined in the current draft of IEEE 754R, which can be stored in a 64-bit field. The XML Schema Working Group recommends that implementors support limits corresponding to those of the decimal128 type. This entails supporting the values in the value space of the otherwise unconstrained datatype for which totalDigits is set to 34, maxScale to 6176, and minScale to −6111.

    Editorial Note: Priority Feedback Request

    The XML Schema Working Group requests feedback from implementors and users of XML Schema concerning the minimum and recommended implementation limits for precisionDecimal. If other limits, larger or smaller, would make this datatype more attractive to users or implementors, please let us know.

A Schema for Schema Documents (Datatypes) (normative)

The XML representation of the datatypes-relevant part of the schema for schema documents is presented here as a normative part of the specification, and as an illustrative example of how the XML Schema language can define itself using its own constructs.

Like any other XML document, schema documents may carry XML and document type declarations. An XML declaration and a document type declaration are provided here for convenience. Since this schema document describes the XML Schema language, the targetNamespace attribute on the schema element refers to the XML Schema namespace itself.

Schema for Schema Documents (Datatypes)
<?xml version='1.0'?>
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [

<!--
     keep this schema XML1.0 DTD valid
  -->
        <!ENTITY % schemaAttrs 'xmlns:hfp CDATA #IMPLIED'>

        <!ELEMENT hfp:hasFacet EMPTY>
        <!ATTLIST hfp:hasFacet
                name NMTOKEN #REQUIRED>

        <!ELEMENT hfp:hasProperty EMPTY>
        <!ATTLIST hfp:hasProperty
                name NMTOKEN #REQUIRED
                value CDATA #REQUIRED>
<!--
        Make sure that processors that do not read the external
        subset will know about the various IDs we declare
  -->
        <!ATTLIST xs:simpleType id ID #IMPLIED>
        <!ATTLIST xs:maxExclusive id ID #IMPLIED>
        <!ATTLIST xs:minExclusive id ID #IMPLIED>
        <!ATTLIST xs:maxInclusive id ID #IMPLIED>
        <!ATTLIST xs:minInclusive id ID #IMPLIED>
        <!ATTLIST xs:totalDigits id ID #IMPLIED>
        <!ATTLIST xs:fractionDigits id ID #IMPLIED>

        <!ATTLIST xs:maxScale id ID #IMPLIED>
        <!ATTLIST xs:minScale id ID #IMPLIED>
        <!ATTLIST xs:length id ID #IMPLIED>
        <!ATTLIST xs:minLength id ID #IMPLIED>
        <!ATTLIST xs:maxLength id ID #IMPLIED>
        <!ATTLIST xs:enumeration id ID #IMPLIED>
        <!ATTLIST xs:pattern id ID #IMPLIED>
        <!ATTLIST xs:appinfo id ID #IMPLIED>
        <!ATTLIST xs:documentation id ID #IMPLIED>
        <!ATTLIST xs:list id ID #IMPLIED>
        <!ATTLIST xs:union id ID #IMPLIED>
        ]>

<xs:schema xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema" 

           blockDefault="#all" 
           elementFormDefault="qualified" 

           xml:lang="en"
           targetNamespace="http://www.w3.org/2001/XMLSchema"
           version="datatypes.xsd (wd-20060217)">
  <xs:annotation>
    <xs:documentation source="../datatypes/datatypes.html">
      The schema corresponding to this document is normative,
      with respect to the syntactic constraints it expresses in the
      XML Schema language.  The documentation (within &lt;documentation>
      elements) below, is not normative, but rather highlights important
      aspects of the W3C Recommendation of which this is a part
    </xs:documentation>
  </xs:annotation>
  <xs:annotation>
    <xs:documentation>
      First the built-in primitive datatypes.  These definitions are for
      information only, the real built-in definitions are magic.
    </xs:documentation>
    <xs:documentation>
      For each built-in datatype in this schema (both primitive and
      derived) can be uniquely addressed via a URI constructed
      as follows:
        1) the base URI is the URI of the XML Schema namespace
        2) 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:
        1) the base URI is the URI of the XML Schema namespace
        2) the fragment identifier is the name of the facet

      For example, to address the maxInclusive facet, the URI is:

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

      Additionally, each facet usage in a built-in datatype definition
      can be uniquely addressed via a URI constructed as follows:
        1) the base URI is the URI of the XML Schema namespace
        2) the fragment identifier is the name of the datatype, followed
           by a period (".") followed by the name of the facet

      For example, to address the usage of the maxInclusive facet in
      the definition of int, the URI is:

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

    </xs:documentation>
  </xs:annotation>
  <xs:simpleType name="string" id="string">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#string"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace value="preserve" id="string.preserve"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="boolean" id="boolean">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#boolean"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="boolean.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="float" id="float">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#float"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="float.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="double" id="double">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#double"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="double.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="decimal" id="decimal">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="totalDigits"/>
        <hfp:hasFacet name="fractionDigits"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="total"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#decimal"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="decimal.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="precisionDecimal" id="precisionDecimal">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="totalDigits"/>
        <hfp:hasFacet name="maxScale"/>
        <hfp:hasFacet name="minScale"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#precisionDecimal"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="precisionDecimal.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="duration" id="duration">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#duration"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="duration.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dateTime" id="dateTime">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#dateTime"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="dateTime.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="time" id="time">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#time"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="time.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="date" id="date">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#date"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="date.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gYearMonth" id="gYearMonth">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gYearMonth"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gYearMonth.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gYear" id="gYear">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gYear"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gYear.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gMonthDay" id="gMonthDay">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gMonthDay"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gMonthDay.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gDay" id="gDay">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gDay"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gDay.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gMonth" id="gMonth">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gMonth"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gMonth.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="hexBinary" id="hexBinary">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#binary"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="hexBinary.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="base64Binary" id="base64Binary">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#base64Binary"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="base64Binary.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="anyURI" id="anyURI">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#anyURI"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="anyURI.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="QName" id="QName">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#QName"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="QName.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NOTATION" id="NOTATION">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NOTATION"/>
      <xs:documentation>
        NOTATION cannot be used directly in a schema; rather a type
        must be derived from it by specifying at least one enumeration
        facet whose value is the name of a NOTATION declared in the
        schema.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="NOTATION.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:annotation>
    <xs:documentation>
      Now the ordinary non-primitive built-in types
    </xs:documentation>
  </xs:annotation>
  <xs:simpleType name="normalizedString" id="normalizedString">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#normalizedString"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:whiteSpace value="replace" id="normalizedString.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="token" id="token">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#token"/>
    </xs:annotation>
    <xs:restriction base="xs:normalizedString">
      <xs:whiteSpace value="collapse" id="token.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="language" id="language">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#language"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
                  id="language.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.ietf.org/rfc/rfc3066.txt">
            pattern specifies the content of section 2.12 of XML 1.0e2
            and RFC 3066 (Revised version of RFC 1766).
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="IDREFS" id="IDREFS">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#IDREFS"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:IDREF"/>
      </xs:simpleType>
      <xs:minLength value="1" id="IDREFS.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ENTITIES" id="ENTITIES">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ENTITIES"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:ENTITY"/>
      </xs:simpleType>
      <xs:minLength value="1" id="ENTITIES.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NMTOKEN" id="NMTOKEN">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NMTOKEN"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="\c+" id="NMTOKEN.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Nmtoken">
            pattern matches production 7 from the XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NMTOKENS" id="NMTOKENS">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NMTOKENS"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:NMTOKEN"/>
      </xs:simpleType>
      <xs:minLength value="1" id="NMTOKENS.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="Name" id="Name">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#Name"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="\i\c*" id="Name.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Name">
            pattern matches production 5 from the XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NCName" id="NCName">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NCName"/>
    </xs:annotation>
    <xs:restriction base="xs:Name">
      <xs:pattern value="[\i-[:]][\c-[:]]*" id="NCName.pattern">
        <xs:annotation>
          <xs:documentation
               source="http://www.w3.org/TR/REC-xml-names/#NT-NCName">
            pattern matches production 4 from the Namespaces in XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ID" id="ID">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ID"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="IDREF" id="IDREF">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#IDREF"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="ENTITY" id="ENTITY">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ENTITY"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="integer" id="integer">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#integer"/>
    </xs:annotation>
    <xs:restriction base="xs:decimal">
      <xs:fractionDigits fixed="true" value="0" id="integer.fractionDigits"/>
      <xs:pattern value="[\-+]?[0-9]+" id="integer.pattern"/>
      
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="nonPositiveInteger" id="nonPositiveInteger">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#nonPositiveInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:maxInclusive value="0" id="nonPositiveInteger.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="negativeInteger" id="negativeInteger">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#negativeInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:nonPositiveInteger">
      <xs:maxInclusive value="-1" id="negativeInteger.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="long" id="long">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#long"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="-9223372036854775808" id="long.minInclusive"/>
      <xs:maxInclusive value="9223372036854775807" id="long.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="int" id="int">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#int"/>
    </xs:annotation>
    <xs:restriction base="xs:long">
      <xs:minInclusive value="-2147483648" id="int.minInclusive"/>
      <xs:maxInclusive value="2147483647" id="int.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="short" id="short">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#short"/>
    </xs:annotation>
    <xs:restriction base="xs:int">
      <xs:minInclusive value="-32768" id="short.minInclusive"/>
      <xs:maxInclusive value="32767" id="short.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="byte" id="byte">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#byte"/>
    </xs:annotation>
    <xs:restriction base="xs:short">
      <xs:minInclusive value="-128" id="byte.minInclusive"/>
      <xs:maxInclusive value="127" id="byte.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="nonNegativeInteger" id="nonNegativeInteger">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0" id="nonNegativeInteger.minInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedLong" id="unsignedLong">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedLong"/>
    </xs:annotation>
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxInclusive value="18446744073709551615"
                       id="unsignedLong.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedInt" id="unsignedInt">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedInt"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedLong">
      <xs:maxInclusive value="4294967295" id="unsignedInt.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedShort" id="unsignedShort">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedShort"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedInt">
      <xs:maxInclusive value="65535" id="unsignedShort.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedByte" id="unsignedByte">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedByte"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedShort">
      <xs:maxInclusive value="255" id="unsignedByte.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="positiveInteger" id="positiveInteger">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#positiveInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:minInclusive value="1" id="positiveInteger.minInclusive"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="yearMonthDuration">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#yearMonthDuration">
        This type includes just those durations expressed in years and months.
        Since the pattern given excludes days, hours, minutes, and seconds,
        the values of this type have a seconds property of zero.  They are
        totally ordered.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:duration">
      <xs:pattern id="yearMonthDuration.pattern" value="[^DT]*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dayTimeDuration">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#dayTimeDuration">
        This type includes just those durations expressed in days, hours, minutes, and seconds.
        The pattern given excludes years and months, so the values of this type 
        have a months property of zero.  They are totally ordered.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:duration">
      <xs:pattern id="dayTimeDuration.pattern"
        value="[^YM]*(T.*)?"/>
     </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="derivationControl">
    <xs:annotation>
      <xs:documentation>
   A utility type, not for public use</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="substitution"/>
      <xs:enumeration value="extension"/>
      <xs:enumeration value="restriction"/>
      <xs:enumeration value="list"/>
      <xs:enumeration value="union"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:group name="simpleDerivation">
    <xs:choice>
      <xs:element ref="xs:restriction"/>
      <xs:element ref="xs:list"/>
      <xs:element ref="xs:union"/>
    </xs:choice>
  </xs:group>
  <xs:simpleType name="simpleDerivationSet">
    <xs:annotation>
      <xs:documentation>
   #all or (possibly empty) subset of {restriction, extension, union, list}
   </xs:documentation>
      <xs:documentation>
   A utility type, not for public use</xs:documentation>
    </xs:annotation>
    <xs:union>
      <xs:simpleType>
        <xs:restriction base="xs:token">
          <xs:enumeration value="#all"/>
        </xs:restriction>
      </xs:simpleType>
      <xs:simpleType>
        <xs:list>
          <xs:simpleType>
            <xs:restriction base="xs:derivationControl">
              <xs:enumeration value="list"/>
              <xs:enumeration value="union"/>
              <xs:enumeration value="restriction"/>

              <xs:enumeration value="extension"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:list>
      </xs:simpleType>
    </xs:union>
  </xs:simpleType>
  <xs:complexType name="simpleType" abstract="true">
    <xs:complexContent>
      <xs:extension base="xs:annotated">
        <xs:group ref="xs:simpleDerivation"/>
        <xs:attribute name="final" type="xs:simpleDerivationSet"/>
        <xs:attribute name="name" type="xs:NCName">
          <xs:annotation>
            <xs:documentation>
              Can be restricted to required or forbidden
            </xs:documentation>
          </xs:annotation>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="topLevelSimpleType">
    <xs:complexContent>
      <xs:restriction base="xs:simpleType">
        <xs:sequence>
          <xs:element ref="xs:annotation" minOccurs="0"/>
          <xs:group ref="xs:simpleDerivation"/>
        </xs:sequence>
        <xs:attribute name="name" type="xs:NCName" use="required">
          <xs:annotation>
            <xs:documentation>
              Required at the top level
            </xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="localSimpleType">
    <xs:complexContent>
      <xs:restriction base="xs:simpleType">
        <xs:sequence>
          <xs:element ref="xs:annotation" minOccurs="0"/>
          <xs:group ref="xs:simpleDerivation"/>
        </xs:sequence>
        <xs:attribute name="name" use="prohibited">
          <xs:annotation>
            <xs:documentation>
              Forbidden when nested
            </xs:documentation>
          </xs:annotation>
        </xs:attribute>
        <xs:attribute name="final" use="prohibited"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="simpleType" type="xs:topLevelSimpleType" id="simpleType">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-simpleType"/>
    </xs:annotation>
  </xs:element>
  <xs:group name="facets">
    <xs:annotation>
      <xs:documentation>
       We should use a substitution group for facets, but
       that's ruled out because it would allow users to
       add their own, which we're not ready for yet.
    </xs:documentation>
    </xs:annotation>
    <xs:choice>
      <xs:element ref="xs:minExclusive"/>
      <xs:element ref="xs:minInclusive"/>
      <xs:element ref="xs:maxExclusive"/>
      <xs:element ref="xs:maxInclusive"/>
      <xs:element ref="xs:totalDigits"/>
      <xs:element ref="xs:fractionDigits"/>

      <xs:element ref="xs:maxScale"/>
      <xs:element ref="xs:minScale"/>
      <xs:element ref="xs:length"/>
      <xs:element ref="xs:minLength"/>
      <xs:element ref="xs:maxLength"/>
      <xs:element ref="xs:enumeration"/>
      <xs:element ref="xs:whiteSpace"/>
      <xs:element ref="xs:pattern"/>
    </xs:choice>
  </xs:group>
  <xs:group name="simpleRestrictionModel">
    <xs:sequence>
      <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/>
      <xs:group ref="xs:facets" minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:group>
  <xs:element name="restriction" id="restriction">
    <xs:complexType>
      <xs:annotation>
        <xs:documentation
             source="http://www.w3.org/TR/xmlschema-2/#element-restriction">
          base attribute and simpleType child are mutually
          exclusive, but one or other is required
        </xs:documentation>
      </xs:annotation>
      <xs:complexContent>
        <xs:extension base="xs:annotated">
          <xs:group ref="xs:simpleRestrictionModel"/>
          <xs:attribute name="base" type="xs:QName" use="optional"/>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:element name="list" id="list">
    <xs:complexType>
      <xs:annotation>
        <xs:documentation
             source="http://www.w3.org/TR/xmlschema-2/#element-list">
          itemType attribute and simpleType child are mutually
          exclusive, but one or other is required
        </xs:documentation>
      </xs:annotation>
      <xs:complexContent>
        <xs:extension base="xs:annotated">
          <xs:sequence>
            <xs:element name="simpleType" type="xs:localSimpleType"
                        minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="itemType" type="xs:QName" use="optional"/>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:element name="union" id="union">
    <xs:complexType>
      <xs:annotation>
        <xs:documentation
             source="http://www.w3.org/TR/xmlschema-2/#element-union">
          memberTypes attribute must be non-empty or there must be
          at least one simpleType child
        </xs:documentation>
      </xs:annotation>
      <xs:complexContent>
        <xs:extension base="xs:annotated">
          <xs:sequence>
            <xs:element name="simpleType" type="xs:localSimpleType"
                        minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
          <xs:attribute name="memberTypes" use="optional">
            <xs:simpleType>
              <xs:list itemType="xs:QName"/>
            </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:complexType name="facet">
    <xs:complexContent>
      <xs:extension base="xs:annotated">
        <xs:attribute name="value" use="required"/>
        <xs:attribute name="fixed" type="xs:boolean" default="false"
                      use="optional"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <xs:complexType name="noFixedFacet">
    <xs:complexContent>
      <xs:restriction base="xs:facet">
        <xs:sequence>
          <xs:element ref="xs:annotation" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="fixed" use="prohibited"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>
  <xs:element name="minExclusive" type="xs:facet" id="minExclusive">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-minExclusive"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="minInclusive" type="xs:facet" id="minInclusive">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-minInclusive"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="maxExclusive" type="xs:facet" id="maxExclusive">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-maxExclusive"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="maxInclusive" type="xs:facet" id="maxInclusive">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-maxInclusive"/>
    </xs:annotation>
  </xs:element>
  <xs:complexType name="numFacet">
    <xs:complexContent>
      <xs:restriction base="xs:facet">
        <xs:sequence>
          <xs:element ref="xs:annotation" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="value" type="xs:nonNegativeInteger" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>


  <xs:complexType name="intFacet">
    <xs:complexContent>
      <xs:restriction base="xs:facet">
        <xs:sequence>
          <xs:element ref="xs:annotation" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="value" type="xs:integer" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="totalDigits" id="totalDigits">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-totalDigits"/>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:numFacet">
          <xs:sequence>
            <xs:element ref="xs:annotation" minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="value" type="xs:positiveInteger" use="required"/>
          <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
  <xs:element name="fractionDigits" type="xs:numFacet" id="fractionDigits">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-fractionDigits"/>
    </xs:annotation>
  </xs:element>

  <xs:element name="maxScale" type="xs:intFacet" id="maxScale">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-maxScale"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="minScale" type="xs:intFacet" id="minScale">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-minScale"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="length" type="xs:numFacet" id="length">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-length"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="minLength" type="xs:numFacet" id="minLength">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-minLength"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="maxLength" type="xs:numFacet" id="maxLength">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-maxLength"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="enumeration" type="xs:noFixedFacet" id="enumeration">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-enumeration"/>
    </xs:annotation>
  </xs:element>
  <xs:element name="whiteSpace" id="whiteSpace">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-whiteSpace"/>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:facet">
          <xs:sequence>
            <xs:element ref="xs:annotation" minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="value" use="required">
            <xs:simpleType>
              <xs:restriction base="xs:NMTOKEN">
                <xs:enumeration value="preserve"/>
                <xs:enumeration value="replace"/>
                <xs:enumeration value="collapse"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
          <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

  <xs:element name="pattern" id="pattern">
    <xs:annotation>
      <xs:documentation
           source="http://www.w3.org/TR/xmlschema-2/#element-pattern"/>
    </xs:annotation>
    <xs:complexType>
      <xs:complexContent>
        <xs:restriction base="xs:noFixedFacet">
          <xs:sequence>
            <xs:element ref="xs:annotation" minOccurs="0"/>
          </xs:sequence>
          <xs:attribute name="value" type="xs:string" use="required"/>
          <xs:anyAttribute namespace="##other" processContents="lax"/>
        </xs:restriction>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>
</xs:schema>

B DTD for Datatype Definitions (non-normative)

The DTD for the datatypes-specific aspects of schema documents is given below. Note there is no implication here that schema must be the root element of a document.

DTD for datatype definitions
<!--
        DTD for XML Schemas: Part 2: Datatypes
        
        Id: datatypes.dtd,v 1.1.2.4 2005/01/31 18:40:42 cmsmcq Exp 
        Note this DTD is NOT normative, or even definitive.
  -->

<!--
        This DTD cannot be used on its own, it is intended
        only for incorporation in XMLSchema.dtd, q.v.
  -->

<!-- Define all the element names, with optional prefix -->
<!ENTITY % simpleType "%p;simpleType">
<!ENTITY % restriction "%p;restriction">
<!ENTITY % list "%p;list">
<!ENTITY % union "%p;union">
<!ENTITY % maxExclusive "%p;maxExclusive">
<!ENTITY % minExclusive "%p;minExclusive">
<!ENTITY % maxInclusive "%p;maxInclusive">
<!ENTITY % minInclusive "%p;minInclusive">
<!ENTITY % totalDigits "%p;totalDigits">
<!ENTITY % fractionDigits "%p;fractionDigits">

<!ENTITY % maxScale "%p;maxScale">
<!ENTITY % minScale "%p;minScale">
<!ENTITY % length "%p;length">
<!ENTITY % minLength "%p;minLength">
<!ENTITY % maxLength "%p;maxLength">

<!ENTITY % enumeration "%p;enumeration">
<!ENTITY % whiteSpace "%p;whiteSpace">
<!ENTITY % pattern "%p;pattern">

<!--
        Customization entities for the ATTLIST of each element
        type. Define one of these if your schema takes advantage
        of the anyAttribute='##other' in the schema for schemas
  -->

<!ENTITY % simpleTypeAttrs "">
<!ENTITY % restrictionAttrs "">
<!ENTITY % listAttrs "">
<!ENTITY % unionAttrs "">
<!ENTITY % maxExclusiveAttrs "">
<!ENTITY % minExclusiveAttrs "">
<!ENTITY % maxInclusiveAttrs "">
<!ENTITY % minInclusiveAttrs "">
<!ENTITY % totalDigitsAttrs "">
<!ENTITY % fractionDigitsAttrs "">
<!ENTITY % lengthAttrs "">
<!ENTITY % minLengthAttrs "">
<!ENTITY % maxLengthAttrs "">


<!ENTITY % maxScaleAttrs "">
<!ENTITY % minScaleAttrs "">
<!ENTITY % enumerationAttrs "">
<!ENTITY % whiteSpaceAttrs "">
<!ENTITY % patternAttrs "">

<!-- Define some entities for informative use as attribute
        types -->
<!ENTITY % URIref "CDATA">
<!ENTITY % XPathExpr "CDATA">
<!ENTITY % QName "NMTOKEN">
<!ENTITY % QNames "NMTOKENS">
<!ENTITY % NCName "NMTOKEN">
<!ENTITY % nonNegativeInteger "NMTOKEN">
<!ENTITY % boolean "(true|false)">
<!ENTITY % simpleDerivationSet "CDATA">
<!--
        #all or space-separated list drawn from derivationChoice
  -->

<!--
        Note that the use of 'facet' below is less restrictive
        than is really intended:  There should in fact be no
        more than one of each of minInclusive, minExclusive,
        maxInclusive, maxExclusive, totalDigits, fractionDigits,
        length, maxLength, minLength within datatype,
        and the min- and max- variants of Inclusive and Exclusive
        are mutually exclusive. On the other hand,  pattern and
        enumeration may repeat.
  -->
<!ENTITY % minBound "(%minInclusive; | %minExclusive;)">
<!ENTITY % maxBound "(%maxInclusive; | %maxExclusive;)">
<!ENTITY % bounds "%minBound; | %maxBound;">
<!ENTITY % numeric "%totalDigits; | %fractionDigits; |
%minScale; | %maxScale;"> 
<!ENTITY % ordered "%bounds; | %numeric;">
<!ENTITY % unordered
   "%pattern; | %enumeration; | %whiteSpace; | %length; |
   %maxLength; | %minLength;">
<!ENTITY % facet "%ordered; | %unordered;">
<!ENTITY % facetAttr 
        "value CDATA #REQUIRED
        id ID #IMPLIED">
<!ENTITY % fixedAttr "fixed %boolean; #IMPLIED">
<!ENTITY % facetModel "(%annotation;)?">
<!ELEMENT %simpleType;
        ((%annotation;)?, (%restriction; | %list; | %union;))>
<!ATTLIST %simpleType;
    name      %NCName; #IMPLIED
    final     %simpleDerivationSet; #IMPLIED
    id        ID       #IMPLIED
    %simpleTypeAttrs;>
<!-- name is required at top level -->
<!ELEMENT %restriction; ((%annotation;)?,
                         (%restriction1; |
                          ((%simpleType;)?,(%facet;)*)),
                         (%attrDecls;))>
<!ATTLIST %restriction;
    base      %QName;                  #IMPLIED
    id        ID       #IMPLIED
    %restrictionAttrs;>
<!--
        base and simpleType child are mutually exclusive,
        one is required.

        restriction is shared between simpleType and
        simpleContent and complexContent (in XMLSchema.xsd).
        restriction1 is for the latter cases, when this
        is restricting a complex type, as is attrDecls.
  -->
<!ELEMENT %list; ((%annotation;)?,(%simpleType;)?)>
<!ATTLIST %list;
    itemType      %QName;             #IMPLIED
    id        ID       #IMPLIED
    %listAttrs;>
<!--
        itemType and simpleType child are mutually exclusive,
        one is required
  -->
<!ELEMENT %union; ((%annotation;)?,(%simpleType;)*)>
<!ATTLIST %union;
    id            ID       #IMPLIED
    memberTypes   %QNames;            #IMPLIED
    %unionAttrs;>
<!--
        At least one item in memberTypes or one simpleType
        child is required
  -->

<!ELEMENT %maxExclusive; %facetModel;>
<!ATTLIST %maxExclusive;
        %facetAttr;
        %fixedAttr;
        %maxExclusiveAttrs;>
<!ELEMENT %minExclusive; %facetModel;>
<!ATTLIST %minExclusive;
        %facetAttr;
        %fixedAttr;
        %minExclusiveAttrs;>

<!ELEMENT %maxInclusive; %facetModel;>
<!ATTLIST %maxInclusive;
        %facetAttr;
        %fixedAttr;
        %maxInclusiveAttrs;>
<!ELEMENT %minInclusive; %facetModel;>
<!ATTLIST %minInclusive;
        %facetAttr;
        %fixedAttr;
        %minInclusiveAttrs;>

<!ELEMENT %totalDigits; %facetModel;>
<!ATTLIST %totalDigits;
        %facetAttr;
        %fixedAttr;
        %totalDigitsAttrs;>
<!ELEMENT %fractionDigits; %facetModel;>
<!ATTLIST %fractionDigits;
        %facetAttr;
        %fixedAttr;
        %fractionDigitsAttrs;>
<!ELEMENT %maxScale; %facetModel;>
<!ATTLIST %maxScale;
        %facetAttr;
        %fixedAttr;
        %maxScaleAttrs;>
<!ELEMENT %minScale; %facetModel;>
<!ATTLIST %minScale;
        %facetAttr;
        %fixedAttr;
        %minScaleAttrs;>

<!ELEMENT %length; %facetModel;>
<!ATTLIST %length;
        %facetAttr;
        %fixedAttr;
        %lengthAttrs;>
<!ELEMENT %minLength; %facetModel;>
<!ATTLIST %minLength;
        %facetAttr;
        %fixedAttr;
        %minLengthAttrs;>
<!ELEMENT %maxLength; %facetModel;>
<!ATTLIST %maxLength;
        %facetAttr;
        %fixedAttr;
        %maxLengthAttrs;>

<!-- This one can be repeated -->
<!ELEMENT %enumeration; %facetModel;>
<!ATTLIST %enumeration;
        %facetAttr;
        %enumerationAttrs;>

<!ELEMENT %whiteSpace; %facetModel;>
<!ATTLIST %whiteSpace;
        %facetAttr;
        %fixedAttr;
        %whiteSpaceAttrs;>

<!-- This one can be repeated -->
<!ELEMENT %pattern; %facetModel;>
<!ATTLIST %pattern;
        %facetAttr;
        %patternAttrs;>

C Illustrative XML representations for the built-in simple type definitions

next sub-sectionC.1 Illustrative XML representations for the built-in primitive type definitions

The (not a) schema document for primitive built-in type definitions
<?xml version='1.0'?>
<!DOCTYPE xs:schema SYSTEM "../namespace/XMLSchema.dtd" [

<!--
     keep this schema XML1.0 DTD valid
  -->
        <!ENTITY % schemaAttrs 'xmlns:hfp CDATA #IMPLIED'>

        <!ELEMENT hfp:hasFacet EMPTY>
        <!ATTLIST hfp:hasFacet
                name NMTOKEN #REQUIRED>

        <!ELEMENT hfp:hasProperty EMPTY>
        <!ATTLIST hfp:hasProperty
                name NMTOKEN #REQUIRED
                value CDATA #REQUIRED>
]>
<xs:schema
  xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  blockDefault="#all" 
  elementFormDefault="qualified" 
  xml:lang="en" 
  targetNamespace="http://www.w3.org/2001/XMLSchema">

  <xs:annotation>
    <xs:documentation>
      First the built-in primitive datatypes.This document contains XML elements which look like 
      definitions for the primitive datatypes.  These definitions are for
      information only,; the real built-in definitions are magic.
    </xs:documentation>
    <xs:documentation>
      For each built-in datatype in this schema (both primitive and
      derived) can be uniquely addressed via a URI constructed
      as follows:
        1) the base URI is the URI of the XML Schema namespace
        2) 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:
        1) the base URI is the URI of the XML Schema namespace
        2) the fragment identifier is the name of the facet

      For example, to address the maxInclusive facet, the URI is:

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

      Additionally, each facet usage in a built-in datatype definition
      can be uniquely addressed via a URI constructed as follows:
        1) the base URI is the URI of the XML Schema namespace
        2) the fragment identifier is the name of the datatype, followed
           by a period (".") followed by the name of the facet

      For example, to address the usage of the maxInclusive facet in
      the definition of int, the URI is:

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

    </xs:documentation>
  </xs:annotation>
  <xs:simpleType name="string" id="string">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#string"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace value="preserve" id="string.preserve"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="boolean" id="boolean">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#boolean"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="boolean.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="float" id="float">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#float"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="float.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="double" id="double">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#double"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="double.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="decimal" id="decimal">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="totalDigits"/>
        <hfp:hasFacet name="fractionDigits"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="total"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#decimal"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="decimal.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="precisionDecimal" id="precisionDecimal">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="totalDigits"/>
        <hfp:hasFacet name="maxScale"/>
        <hfp:hasFacet name="minScale"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="true"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#precisionDecimal"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="precisionDecimal.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="duration" id="duration">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#duration"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="duration.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dateTime" id="dateTime">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#dateTime"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="dateTime.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="time" id="time">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#time"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="time.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="date" id="date">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#date"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="date.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gYearMonth" id="gYearMonth">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gYearMonth"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gYearMonth.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gYear" id="gYear">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gYear"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gYear.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gMonthDay" id="gMonthDay">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gMonthDay"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gMonthDay.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gDay" id="gDay">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gDay"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gDay.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="gMonth" id="gMonth">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="maxInclusive"/>
        <hfp:hasFacet name="maxExclusive"/>
        <hfp:hasFacet name="minInclusive"/>
        <hfp:hasFacet name="minExclusive"/>
        <hfp:hasProperty name="ordered" value="partial"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#gMonth"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="gMonth.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="hexBinary" id="hexBinary">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#binary"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="hexBinary.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="base64Binary" id="base64Binary">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#base64Binary"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="base64Binary.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="anyURI" id="anyURI">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#anyURI"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="anyURI.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="QName" id="QName">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#QName"/>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="QName.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NOTATION" id="NOTATION">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NOTATION"/>
      <xs:documentation>
        NOTATION cannot be used directly in a schema; rather a type
        must be derived from it by specifying at least one enumeration
        facet whose value is the name of a NOTATION declared in the
        schema.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:anyAtomicType">
      <xs:whiteSpace fixed="true" value="collapse" id="NOTATION.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

previous sub-section C.2 Illustrative XML representations for the built-in ordinary type definitions

Illustrative schema document for derived built-in type definitions
<?xml version='1.0'?>
<!DOCTYPE xs:schema SYSTEM "../namespace/XMLSchema.dtd" [

<!--
     keep this schema XML1.0 DTD valid
  -->
        <!ENTITY % schemaAttrs 'xmlns:hfp CDATA #IMPLIED'>

        <!ELEMENT hfp:hasFacet EMPTY>
        <!ATTLIST hfp:hasFacet
                name NMTOKEN #REQUIRED>

        <!ELEMENT hfp:hasProperty EMPTY>
        <!ATTLIST hfp:hasProperty
                name NMTOKEN #REQUIRED
                value CDATA #REQUIRED>

]>
<xs:schema
  xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  blockDefault="#all" 
  elementFormDefault="qualified" 
  xml:lang="en" 
  targetNamespace="http://www.w3.org/2001/XMLSchema">
 <xs:annotation>
    <xs:documentation>
      NowThis document contains XML representations for the 
     ordinary non-primitive built-in datatypes
    </xs:documentation>
  </xs:annotation>
  <xs:simpleType name="normalizedString" id="normalizedString">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#normalizedString"/>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:whiteSpace value="replace" id="normalizedString.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="token" id="token">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#token"/>
    </xs:annotation>
    <xs:restriction base="xs:normalizedString">
      <xs:whiteSpace value="collapse" id="token.whiteSpace"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="language" id="language">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#language"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*" id="language.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.ietf.org/rfc/rfc3066.txt">
            pattern specifies the content of section 2.12 of XML 1.0e2
            and RFC 3066 (Revised version of RFC 1766).
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="IDREFS" id="IDREFS">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#IDREFS"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:IDREF"/>
      </xs:simpleType>
      <xs:minLength value="1" id="IDREFS.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ENTITIES" id="ENTITIES">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ENTITIES"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:ENTITY"/>
      </xs:simpleType>
      <xs:minLength value="1" id="ENTITIES.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NMTOKEN" id="NMTOKEN">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NMTOKEN"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="\c+" id="NMTOKEN.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Nmtoken">
            pattern matches production 7 from the XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NMTOKENS" id="NMTOKENS">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasFacet name="length"/>
        <hfp:hasFacet name="minLength"/>
        <hfp:hasFacet name="maxLength"/>
        <hfp:hasFacet name="enumeration"/>
        <hfp:hasFacet name="whiteSpace"/>
        <hfp:hasFacet name="pattern"/>
        <hfp:hasProperty name="ordered" value="false"/>
        <hfp:hasProperty name="bounded" value="false"/>
        <hfp:hasProperty name="cardinality" value="countably infinite"/>
        <hfp:hasProperty name="numeric" value="false"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NMTOKENS"/>
    </xs:annotation>
    <xs:restriction>
      <xs:simpleType>
        <xs:list itemType="xs:NMTOKEN"/>
      </xs:simpleType>
      <xs:minLength value="1" id="NMTOKENS.minLength"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="Name" id="Name">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#Name"/>
    </xs:annotation>
    <xs:restriction base="xs:token">
      <xs:pattern value="\i\c*" id="Name.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Name">
            pattern matches production 5 from the XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="NCName" id="NCName">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#NCName"/>
    </xs:annotation>
    <xs:restriction base="xs:Name">
      <xs:pattern value="[\i-[:]][\c-[:]]*" id="NCName.pattern">
        <xs:annotation>
          <xs:documentation source="http://www.w3.org/TR/REC-xml-names/#NT-NCName">
            pattern matches production 4 from the Namespaces in XML spec
          </xs:documentation>
        </xs:annotation>
      </xs:pattern>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="ID" id="ID">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ID"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="IDREF" id="IDREF">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#IDREF"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="ENTITY" id="ENTITY">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#ENTITY"/>
    </xs:annotation>
    <xs:restriction base="xs:NCName"/>
  </xs:simpleType>
  <xs:simpleType name="integer" id="integer">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#integer"/>
    </xs:annotation>
    <xs:restriction base="xs:decimal">
      <xs:fractionDigits fixed="true" value="0" id="integer.fractionDigits"/>
      <xs:pattern value="[\-+]?[0-9]+" id="integer.pattern"/>
      
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="nonPositiveInteger" id="nonPositiveInteger">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#nonPositiveInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:maxInclusive value="0" id="nonPositiveInteger.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="negativeInteger" id="negativeInteger">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#negativeInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:nonPositiveInteger">
      <xs:maxInclusive value="-1" id="negativeInteger.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="long" id="long">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#long"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="-9223372036854775808" id="long.minInclusive"/>
      <xs:maxInclusive value="9223372036854775807" id="long.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="int" id="int">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#int"/>
    </xs:annotation>
    <xs:restriction base="xs:long">
      <xs:minInclusive value="-2147483648" id="int.minInclusive"/>
      <xs:maxInclusive value="2147483647" id="int.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="short" id="short">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#short"/>
    </xs:annotation>
    <xs:restriction base="xs:int">
      <xs:minInclusive value="-32768" id="short.minInclusive"/>
      <xs:maxInclusive value="32767" id="short.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="byte" id="byte">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#byte"/>
    </xs:annotation>
    <xs:restriction base="xs:short">
      <xs:minInclusive value="-128" id="byte.minInclusive"/>
      <xs:maxInclusive value="127" id="byte.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="nonNegativeInteger" id="nonNegativeInteger">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0" id="nonNegativeInteger.minInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedLong" id="unsignedLong">
    <xs:annotation>
      <xs:appinfo>
        <hfp:hasProperty name="bounded" value="true"/>
        <hfp:hasProperty name="cardinality" value="finite"/>
      </xs:appinfo>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedLong"/>
    </xs:annotation>
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:maxInclusive value="18446744073709551615" id="unsignedLong.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedInt" id="unsignedInt">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedInt"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedLong">
      <xs:maxInclusive value="4294967295" id="unsignedInt.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedShort" id="unsignedShort">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedShort"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedInt">
      <xs:maxInclusive value="65535" id="unsignedShort.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="unsignedByte" id="unsignedByte">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#unsignedByte"/>
    </xs:annotation>
    <xs:restriction base="xs:unsignedShort">
      <xs:maxInclusive value="255" id="unsignedByte.maxInclusive"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="positiveInteger" id="positiveInteger">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#positiveInteger"/>
    </xs:annotation>
    <xs:restriction base="xs:nonNegativeInteger">
      <xs:minInclusive value="1" id="positiveInteger.minInclusive"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="yearMonthDuration">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#yearMonthDuration">
        This type includes just those durations expressed in years and months.
        Since the pattern given excludes days, hours, minutes, and seconds,
        the values of this type have a seconds property of zero.  They are
        totally ordered.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:duration">
      <xs:pattern id="yearMonthDuration.pattern" value="[^DT]*"/>
    </xs:restriction>
  </xs:simpleType>
  <xs:simpleType name="dayTimeDuration">
    <xs:annotation>
      <xs:documentation source="http://www.w3.org/TR/xmlschema-2/#dayTimeDuration">
        This type includes just those durations expressed in days, hours, minutes, and seconds.
        The pattern given excludes years and months, so the values of this type 
        have a months property of zero.  They are totally ordered.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:duration">
      <xs:pattern id="dayTimeDuration.pattern" value="[^YM]*(T.*)?"/>
     </xs:restriction>
  </xs:simpleType>

</xs:schema>

D Built-up Value Spaces

Some datatypes, such as integer, describe well-known mathematically abstract systems.  Others, such as the date/time datatypes, describe "real-life", "applied" systems.  Certain of the systems described by datatypes, both abstract and applied, have values in their value spaces most easily described as things having several properties, which in turn have values which are in some sense "primitive" or are from the value spaces of simpler datatypes.

In this document, the arguments to functions are assumed to be "call by value" unless explicitly noted to the contrary, meaning that if the argument is modified during the processing of the algorithm, that modification is not reflected in the "outside world".  On the other hand, the arguments to procedures are assumed to be "call by location", meaning that modifications are so reflected, since that is the only way the processing of the algorithm can have any effect.

Properties always have values.  [Definition:]  An optional property is permitted but not required to have the special value absent.

Those values that are more primitive, and are used (among other things) herein to construct object value spaces but which we do not explicitly define are described here:

next sub-sectionD.1 Numerical Values

The following standard operators are defined here in case the reader is unsure of their definition:

  • [Definition:]  If m and n are numbers, then m div n is the greatest integer less than or equal to m / n .
  • [Definition:]  If m and n are numbers, then m mod n is  m − n × ( m ·div· n) .

Note: n ·div· 1  is a convenient and short way of expressing "the greatest integer less than or equal to n".

D.1.1 Exact Lexical Mappings

Generic Numeral-to-Number Lexical Mappings
·unsignedNoDecimalMap· (N) → integer
Maps an unsignedNoDecimalPtNumeral to its numerical value.
·noDecimalMap· (N) → integer
Maps an noDecimalPtNumeral to its numerical value.
·unsignedDecimalPtMap· (D) → decimal number
Maps an unsignedDecimalPtNumeral to its numerical value.
·decimalPtMap· (N) → decimal number
Maps a decimalPtNumeral to its numerical value.
·scientificMap· (N) → decimal number
Maps a scientificNotationNumeral to its numerical value.

Some numerical datatypes include some or all of three constant non-numerical values:  positiveInfinity, negativeInfinity, and notANumber.  Their lexical spaces include non-numeral lexical representations for these non-numeric values:

Lexical Mapping for Non-numerical constants Used With Numerical Datatypes
Maps the ·lexical representations· of constants used with some numerical datatypes to those constants.

Canonical Mapping for Non-numerical constants Used With Numerical Datatypes
Maps the constants used with some numerical datatypes to their ·canonical representations·.

previous sub-section D.2 Date/time Values

There are several different primitive but related datatypes defined in the specification which pertain to various combinations of dates and times, and parts thereof.  They all use related value-space models, which are described in detail in this section.  It is not difficult for a casual reader of the descriptions of the individual datatypes elsewhere in this specification to misunderstand some of the details of just what the datatypes are intended to represent, so more detail is presented here in this section.

All of the value spaces for dates and times described here represent moments or periods of time in Universal Coordinated Time (UTC).  [Definition:]  Universal Coordinated Time (UTC) is an adaptation of TAI which closely approximates UT1 by adding ·leap-seconds· to selected ·UTC· days.

[Definition:]  A leap-second is an additional second added to the last day of December, June, October, or March, when such an adjustment is deemed necessary by the International Earth Rotation and Reference Systems Service in order to keep ·UTC· within 0.9 seconds of observed astronomical time.  When leap seconds are introduced, the last minute in the day has more than sixty seconds.  In theory leap seconds can also be removed from a day, but this has not yet occurred. Leap seconds are not supported by the types defined here.

Because the dateTime type and other date- and time-related types defined in this specification do not support leap seconds, there are portions of the ·UTC· timeline which cannot be represented by values of these types. Users whose applications require that leap seconds be represented and that date/time arithmetic take historically occurring leap seconds into account will wish to make appropriate adjustments at the application level, or to use other types.

D.2.1 The Seven-property Model

There are two distinct ways to model moments in time:  either by tracking their year, month, day, hour, minute and second (with fractional seconds as needed), or by tracking their time (measured generally in seconds or days) from some starting moment.  Each has its advantages.  The two are isomorphic.  For definiteness, we choose to model the first using five integer and one decimal number properties.  We superimpose the second by providing one decimal number-valued function which gives the corresponding count of seconds from zero (the "time on the time line").

There is also a seventh integer property which specifies the timezone, which is conceptually a duration measuring the offset of times with that timezone from ·UTC·.  Values for the six primary properties are always stored in their "local" values (the values shown in the lexical representations), rather than converted to ·UTC·.

an integer
an integer between 1 and 12 inclusive
an integer between 1 and 31 inclusive, possibly restricted further depending on ·month· and ·year·
an integer between 0 and 23 inclusive
an integer between 0 and 59 inclusive
a decimal number greater than or equal to 0 and less than 60.
an ·optional· integer between −840 and 840 inclusive

Non-negative values of the properties map to the years, months, days of month, etc. of the Gregorian calendar in the obvious way. Values less than 1582 in the ·year· property represent years in the "proleptic Gregorian calendar". A value of zero in the ·year· property represents the year 1 BCE; a value of −1 represents the year 2 BCE, −2 is 3 BCE, etc.

Note: In version 1.0 of this specification, the ·year· property was not permitted to have the value zero. The year 1 BCE was represented by a ·year· value of −1, 2 BCE by −2, and so forth. In this version of this specification, two changes are made in order to agree with existing usage. First, ·year· is permitted to have the value zero. Second, the interpretation of ·year· values is changed accordingly: a ·year· value of zero represents 1 BCE, −1 represents 2 BCE, etc. This representation simplifies interval arithmetic and leap-year calculation for dates before the common era.

Note that 1 BCE, 5 BCE, and so on (years 0000, -0004, etc. in the lexical representation defined here) are leap years in the proleptic Gregorian calendar used for the date/time datatypes defined here. Version 1.0 of this specification was unclear about the treatment of leap years before the common era; caution should be used if existing schemas or data specify dates of 29 February for any years before the common era. With that possible exception, schemas and data valid under the old interpretation remain valid under the new.

The model just described is called herein the "seven-property" model for date/time datatypes.  It is used "as is" for dateTime; all other date/time datatypes except duration use the same model except that some of the six primary properties are required to have the value absent, instead of being required to have a numerical value.  (An ·optional· property, like ·timezone·, is always permitted to have the value absent.)

·timezone· values are limited to 14 hours, which is 840 (= 60 × 14) minutes.

Note: Leap-seconds are not permitted

As of the time this specification was published, leap-seconds (always one leap-second) have been introduced by the responsible authorities at the end (in ·UTC·) of the following days (see [USNO Historical List]):

  • 1972-06-30
  • 1972-12-31
  • 1973-12-31
  • 1974-12-31
  • 1975-12-31
  • 1976-12-31
  • 1977-12-31
  • 1978-12-31
  • 1979-12-31
  • 1981-06-30
  • 1982-06-30
  • 1983-06-30
  • 1985-06-30
  • 1987-12-31
  • 1989-12-31
  • 1990-12-31
  • 1992-06-30
  • 1993-06-30
  • 1994-06-30
  • 1995-12-31
  • 1997-06-30
  • 1998-12-31
  • 2005-12-31

Because the simple types defined here do not support leap seconds, they cannot be used to represent the final second, in ·UTC·, of any of the days listed above. If it is important, at the application level, to track the occurrence of leap seconds, then users will need to make special arrangements for special handling of the dates above and of time intervals crossing them.

While calculating, property values from the dateTime 1972-12-31T00:00:00 are used to fill in for those that are absent, except that if ·day· is absent but ·month· is not, the largest permitted day for that month is used.  1972-12-31T00:00:00 happens to permit both the maximum number of days and the maximum number of seconds.

Time on Timeline for Date/time Seven-property Model Datatypes
·timeOnTimeline· (dt) → decimal number
Maps a date/timeSevenPropertyModel value to the decimal number representing its position on the "time line".

Values from any one date/time datatype using the seven-component model (all except duration) are ordered the same as their ·timeOnTimeline· values, except that if one value's ·timezone· is absent and the other's is not, and using maximum and minimum ·timezone· values for the one whose ·timezone· is actually absent changes the resulting (strict) inequality, the original two values are incomparable.

D.2.2 Lexical Mappings

[Definition:]  Each lexical representation is made up of certain date/time fragments, each of which corresponds to a particular property of the datatype value.  They are defined by the following productions.

Each fragment other than timezoneFrag defines a subset of the ·lexical space· of precisionDecimal; the corresponding ·lexical mapping· is the precisionDecimal ·lexical mapping· restricted to that subset.  These fragment ·lexical mappings· are combined separately for each date/time datatype (other than duration) to make up ·the complete lexical mapping· for that datatype.  The ·yearFragValue· mapping is used to obtain the value of the ·year· property, the ·monthFragValue· mapping is used to obtain the value of the ·month· property, etc.  Each datatype which specifies some properties to be mandatorily absent also does not permit the corresponding lexical fragments in its lexical representations.

Partial Date/time Lexical Mappings
·yearFragValue· (YR) → integer
Maps a yearFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·year· property of a date/timeSevenPropertyModel value.
·monthFragValue· (MO) → integer
Maps a monthFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·month· property of a date/timeSevenPropertyModel value.
·dayFragValue· (DA) → integer
Maps a dayFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·day· property of a date/timeSevenPropertyModel value.
·hourFragValue· (HR) → integer
Maps a hourFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·hour· property of a date/timeSevenPropertyModel value.
·minuteFragValue· (MI) → integer
Maps a minuteFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·minute· property of a date/timeSevenPropertyModel value.
·secondFragValue· (SE) → decimal number
Maps a secondFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto a decimal number, presumably the ·second· property of a date/timeSevenPropertyModel value.
·timezoneFragValue· (TZ) → integer
Maps a timezoneFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·timezone· property of a date/timeSevenPropertyModel value.

(The redundancy between 'Z', '+00:00', and '-00:00', and the possibility of trailing fractional '0' digits for secondFrag, are the only redundancies preventing these mappings from being one-to-one.)

The following fragment ·canonical mappings· for each value-object property are combined as appropriate to make the ·canonical mapping· for each date/time datatype (other than duration):

Partial Date/time Canonical Mappings
Maps an integer, presumably the ·year· property of a date/timeSevenPropertyModel value, onto a yearFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps an integer, presumably the ·month· property of a date/timeSevenPropertyModel value, onto a monthFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps an integer, presumably the ·day· property of a date/timeSevenPropertyModel value, onto a dayFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps an integer, presumably the ·hour· property of a date/timeSevenPropertyModel value, onto a hourFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps an integer, presumably the ·minute· property of a date/timeSevenPropertyModel value, onto a minuteFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps a decimal number, presumably the ·second· property of a date/timeSevenPropertyModel value, onto a secondFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Maps an integer, presumably the ·timezone· property of a date/timeSevenPropertyModel value, onto a timezoneFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.

E Function Definitions

The more important functions and procedures defined here are summarized in the text  When there is a text summary, the name of the function in each is a "hot-link" to the same name in the other.  All other links to these functions link to the complete definition in this section.

next sub-sectionE.1 Generic Number-related Functions

The following functions are used with various numeric and date/time datatypes.

Auxiliary Functions for Operating on Numeral Fragments
·digitValue· (d) → integer
Maps each digit to its numerical value.
Arguments:
dmatches digit
Result:
a nonnegative integer less than ten
Algorithm:
Return
  • 0   when  d = '0' ,
  • 1   when  d = '1' ,
  • 2   when  d = '2' ,
  • etc.
·digitSequenceValue· (S) → integer
Maps a sequence of digits to the position-weighted sum of the terms numerical values.
Arguments:
Sa finite sequence of ·literals·, each term matching digit.
Result:
a nonnegative integer
Algorithm:
Return the sum of ·digitValue·(Si) × 10length(S)−i  where i runs over the domain of S.
·fractionDigitSequenceValue· (S) → integer
Maps a sequence of digits to the position-weighted sum of the terms numerical values, weighted appropriately for fractional digits.
Arguments:
Sa finite sequence of ·literals·, each term matching digit.
Result:
a nonnegative integer
Algorithm:
Return the sum of ·digitValue·(Si) − 10i  where i runs over the domain of S.
·fractionFragValue· (N) → decimal number
Maps a fracFrag to the appropriate fractional decimal number.
Arguments:
Nmatches fracFrag
Result:
a nonnegative decimal number
Algorithm:
N is necessarily the left-to-right concatenation of a finite sequence S of ·literals·, each term matching digit.
Generic Numeral-to-Number Lexical Mappings
·unsignedNoDecimalMap· (N) → integer
Maps an unsignedNoDecimalPtNumeral to its numerical value.
Arguments: Result:
a nonnegative integer
Algorithm:
N is the left-to-right concatenation of a finite sequence S of ·literals·, each term matching digit.
·noDecimalMap· (N) → integer
Maps an noDecimalPtNumeral to its numerical value.
Arguments:
Nmatches noDecimalPtNumeral
Result:
an integer
Algorithm:
N necessarily consists of an optional sign('+' or '-') and then a ·literal· U that matches unsignedNoDecimalPtNumeral.
Return
·unsignedDecimalPtMap· (D) → decimal number
Maps an unsignedDecimalPtNumeral to its numerical value.
Arguments: Result:
a nonnegative decimal number
Algorithm:
D necessarily consists of an optional ·literal· N matching unsignedNoDecimalPtNumeral, a decimal point, and then an optional ·literal· F matching fracFrag.
Return
·decimalPtMap· (N) → decimal number
Maps a decimalPtNumeral to its numerical value.
Arguments:
Nmatches decimalPtNumeral
Result:
a decimal number
Algorithm:
N necessarily consists of an optional sign('+' or '-') and then an instance U of unsignedDecimalPtNumeral.
Return
·scientificMap· (N) → decimal number
Maps a scientificNotationNumeral to its numerical value.
Arguments: Result:
a decimal number
Algorithm:
N necessarily consists of an instance C of either noDecimalPtNumeral or decimalPtNumeral, either an 'e' or an 'E', and then an instance E of noDecimalPtNumeral.
Return
Auxiliary Functions for Producing Numeral Fragments
·digit· (i) → digit
Maps each integer between 0 and 9 to the corresponding digit.
Arguments:
ibetween 0 and 9 inclusive
Result:
matches digit
Algorithm:
Return
  • '0'   when  i = 0 ,
  • '1'   when  i = 1 ,
  • '2'   when  i = 2 ,
  • etc.
·digitRemainderSeq· (i) → sequence of integers
Maps each nonnegative integer to a sequence of integers used by ·digitSeq· to ultimately create an unsignedNoDecimalPtNumeral.
Arguments:
ia nonnegative integer
Result:
sequence of nonnegative integers
Algorithm:
Return that sequence s for which
  • s0 = i  and
  • sj+1 = sj ·div· 10 .
·digitSeq· (i) → sequence of integers
Maps each nonnegative integer to a sequence of integers used by ·unsignedNoDecimalPtCanonicalMap· to create an unsignedNoDecimalPtNumeral.
Arguments:
ia nonnegative integer
Result:
sequence of integers where each term is between 0 and 9 inclusive
Algorithm:
Return that sequence s for which  sj =·digitRemainderSeq·(i)j ·mod· 10 .
·lastSignificantDigit· (s) → integer
Maps a sequence of nonnegative integers to the index of the first zero term.
Arguments:
sa sequence of nonnegative integers
Result:
a nonnegative integer
Algorithm:
Return the smallest nonnegative integer j such that s(i)j+1 is 0.
·FractionDigitRemainderSeq· (f) → sequence of decimal numbers
Maps each nonnegative decimal number less than 1 to a sequence of decimal numbers used by ·fractionDigitSeq· to ultimately create an unsignedNoDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
a sequence of nonnegative decimal numbers
Algorithm:
Return that sequence s for which
  • s0 = f − 10 , and
  • sj+1 = (sj ·mod· 1) − 10 .
·fractionDigitSeq· (f) → sequence of integers
Maps each nonnegative decimal number less than 1 to a sequence of integers used by ·fractionDigitsCanonicalFragmentMap· to ultimately create an unsignedNoDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
a sequence of integer;s where each term is between 0 and 9 inclusive
Algorithm:
Return that sequence s for which  sj = ·FractionDigitRemainderSeq·(f)j ·div· 1 .
·fractionDigitsCanonicalFragmentMap· (f) → fracFrag
Maps each nonnegative decimal number less than 1 to a ·literal· used by ·unsignedDecimalPtCanonicalMap· to create an unsignedDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
matches fracFrag
Algorithm:
Generic Number to Numeral Canonical Mappings
Arguments:
ia nonnegative integer
Result: Algorithm:
Return ·digit·(·digitSeq·(i)·lastSignificantDigit·(·digitRemainderSeq·(i))) & . . . & ·digit·(·digitSeq·(i)0) .   (Note that the concatenation is in reverse order.)
Arguments:
ian integer
Result: Algorithm:
Return
Arguments:
na nonnegative decimal number
Result: Algorithm: Arguments:
na decimal number
Result: Algorithm:
Return
Arguments:
na nonnegative decimal number
Result: Algorithm:
Return  ·unsignedDecimalPtCanonicalMap·(n / 10log(n·div· 1) & 'E' & ·noDecimalPtCanonicalMap·(log(n·div· 1)
Arguments:
na decimal number
Result: Algorithm:
Return

For example:

Lexical Mapping for Non-numerical constants Used With Numerical Datatypes
·specialRepValue· (S) → constant
Maps the ·lexical representations· of constants used with some numerical datatypes to those constants.
Arguments:
Smatches numericalSpecialRep
Result:
one of positiveInfinity, negativeInfinity, or notANumber.
Algorithm:
Return
  • positiveInfinity   when S is 'INF' or '+INF',
  • negativeInfinity   when S is '-INF', and
  • notANumber   when S is 'NaN'
Canonical Mapping for Non-numerical constants Used With Numerical Datatypes
·specialRepCanonicalMap· (c) → numericalSpecialRep
Maps the constants used with some numerical datatypes to their ·canonical representations·.
Arguments:
cone of positiveInfinity, negativeInfinity, and notANumber
Result: Algorithm:
Return
  • 'INF'   when c is positiveInfinity
  • '-INF'   when c is negativeInfinity
  • 'NaN'   when c is notANumber
Auxiliary Functions for Reading Instances of pDecimalRep
·decimalPtPrecision· (LEX) → integer
Maps a decimalPtNumeral onto an integer; used in calculating the ·arithmeticPrecision· of a precisionDecimal value.
Arguments:
LEXmatches decimalPtNumeral
Result:
an integer
Algorithm:
LEX necessarily contains a decimal point ('.') and may optionally contain a following fracFrag F consisting of some number n of digits.
Return
  • n   when F is present, and
  • 0   otherwise.
·scientificPrecision· (LEX) → integer
Maps a scientificNotationNumeral onto an integer; used in calculating the ·arithmeticPrecision· of a precisionDecimal value.
Arguments: Result:
an integer
Algorithm:
LEX necessarily contains a noDecimalPtNumeral or decimalPtNumeral C preceding an exponent indicator ('E' or 'e', and a following noDecimalPtNumeral E.
Return
Lexical Mapping
Arguments:
LEXmatches pDecimalRep
Result: Algorithm:
Let pD be a complete precisionDecimal value.
  1. Set pD's ·numericalValue· to
  2. Set pD's ·arithmeticPrecision· to
  3. Set pD's ·sign· to
    • absent   when LEX is 'NaN'
    • negative   when the first character of LEX is '-', and
    • positive   otherwise.
  4. Return pD.
Lexical Mapping
·decimalLexicalMap· (LEX) → decimal
Maps a decimalLexicalRep onto a decimal value.
Arguments:
LEXmatches decimalLexicalRep
Result:
a decimal value
Algorithm:
Let d be a decimal value.
  1. Set d to
  2. Return d.
Canonical Mapping
Arguments:
da decimal value
Result: Algorithm:
  1. If d is an integer, then return ·noDecimalPtCanonicalMap·(d).
  2. Otherwise, return ·decimalPtCanonicalMap·(d).
Auxiliary Functions for Binary Floating-point Lexical/Canonical Mappings
·floatingPointRound· (nVcWidtheMineMax) → decimal number or constant
Rounds a non-zero decimal number to the nearest floating-point value.
Arguments:
nVan initially non-zero decimal number (may be set to zero during calculations)
cWidtha positive integer
eMinan integer
eMaxan integer greater than eMin
Result:
a decimal number or constant (INF or -INF)
Algorithm:
Let
  • s be an integer intially 1,
  • c be a nonnegative integer, and
  • e be an integer.
  1. Set s to −1   when  nV < 0 .
  2. So select e that 2cWidth × 2(e − 1) < |nV| ≤ 2cWidth × 2e .
  3. So select c that  (c − 1) × 2e ≤ |nV | <c × 2e  and  2cWidth−1 < c ≤ 2cWidth .
    • when  eMax < e  (overflow) return:
      • positiveInfinity   when s is positive, and
      • negativeInfinity   otherwise.
    • otherwise:
      1. When e < eMin  (underflow):
        • Set  e = eMin
        • So select c that  (c − 1) × 2e ≤ |nV | <c × 2e .
      2. Set nV to
        • c × 2e   when  |nV | > c × 2e − 2(e−1) ;
        • (c − 1) × 2e   when  |nV | < c × 2e − 2(e−1) ;
        • c × 2e or (c − 1) × 2e   according to whether c is even or  c − 1  is even, otherwise (i.e.,  |nV | = c × 2e − 2(e−1) , the midpoint between the two values).
      3. Return 
        • s × nV   when nV < 2cWidth × 2eMax,
        • positiveInfinity   when s is positive, and
        • negativeInfinity   otherwise.
Note: Implementers will find the algorithms of [Clinger, WD (1990)] more efficient in memory than the simple abstract algorithm employed above.
·round· (nk) → decimal number
Maps a decimal number to that value rounded by some power of 10.
Arguments:
na decimal number
ka nonnegative integer
Result:
a decimal number
Algorithm:
Return  ((n / 10k + 0.5) ·div·1) × 10k .
·floatApprox· (cej) → decimal number
Maps a decimal number ( c × 10e ) to successive approximations.
Arguments:
ca nonnegative integer
ean integer
ja nonnegative integer
Result:
a decimal number
Algorithm:
Return  ·round·(cj ) × 10e
Lexical Mapping
·floatLexicalMap· (LEX) → float
Maps a floatRep onto a float value.
Arguments:
LEXmatches floatRep
Result:
a float value
Algorithm:
Let nV be a decimal number or constant (INF or −INF).
Note: This specification permits the substitution of any other rounding algorithm which conforms to the requirements of [IEEE 754-1985].
Lexical Mapping
·doubleLexicalMap· (LEX) → double
Maps a doubleRep onto a double value.
Arguments:
LEXmatches doubleRep
Result:
a double value
Algorithm:
Let nV be a decimal number or constant (INF or −INF).
Note: This specification permits the substitution of any other rounding algorithm which conforms to the requirements of [IEEE 754-1985].
Canonical Mapping
Arguments:
fa float value
Result: Algorithm:
Let
  • l be a nonnegative integer
  • s be an integer intially 1,
  • c be a positive integer, and
  • e be an integer.
  • Return ·specialRepCanonicalMap·(f )   when f is one of positiveInfinity, negativeInfinity, or notANumber;
  • return '0.0E0'   when f is positiveZero;
  • return '-0.0E0'   when f is negativeZero;
  • otherwise (f is numeric and non-zero):
    1. Set s to −1   when  f < 0 .
    2. Let c be the smallest integer for which there exists an integer e for which  |f | = c × 10e .
    3. Let e be log10(|f | / c)   (so that  |f | = c × 10e ).
    4. Let l be the largest nonnegative integer for which  c × 10e = ·floatingPointRound·(·floatApprox·(cel ), 24, −149, 104)
    5. Return ·scientificCanonicalMap·(s × ·floatApprox·(cel )) .
Canonical Mapping
Arguments:
fa double value
Result: Algorithm:
Let
  • l be a nonnegative integer
  • s be an integer intially 1,
  • c be a positive integer, and
  • e be an integer.
  • Return ·specialRepCanonicalMap·(f )   when f is one of positiveInfinity, negativeInfinity, or notANumber;
  • return '0.0E0'   when f is positiveZero;
  • return '-0.0E0'   when f is negativeZero;
  • otherwise (f is numeric and non-zero):
    1. Set s to −1   when  f < 0 .
    2. Let c be the smallest integer for which there exists an integer e for which  |f | = c × 10e .
    3. Let e be log10(|f | / c)   (so that  |f | = c × 10e ).
    4. Let l be the largest nonnegative integer for which  c × 10e = ·floatingPointRound·(·floatApprox·(cel ), 53, −1074, 971)
    5. Return ·scientificCanonicalMap·(s × ·floatApprox·(cel )) .
Canonical Mapping
Arguments:
pDa precisionDecimal value
Result: Algorithm:
  1. Let nV be the ·numericalValue· of pD.

    Let aP be the ·arithmeticPrecision· of pD.

  2. If pD is one of NaN, INF, or -INF, then return ·specialRepCanonicalMap·(nV).
  3. Otherwise, if nV is an integer and aP is zero and 1E-6 ≤ nV ≤ 1E6, then return ·noDecimalPtCanonicalMap·(nV).
  4. Otherwise, if aP is greater than zero and 1E-6 ≤ nV ≤ 1E6, then let s be ·decimalPtCanonicalMap·(nV). Let f be the number of fractional digits in s; f will invariably be less than or equal to aP. Return the concatenation of s with aP − f occurrences of the digit '0'.
  5. Otherwise, it will be the case that nV is less than 1E−6 or greater than 1E6.  Let
    • s be ·scientificCanonicalMap·(nV).
    • m be the part of s which precedes the "E".
    • n be the part of s which follows the "E".
    • p be the integer denoted by n.
    • f be the number of fractional digits in m; note that f will invariably be less than or equal to aP + p.
    • t be a string consisting of aP + p − f occurrences of the digit '0', preceded by a decimal point if and only if m contains no decimal point and aP + p − f is greater than zero.
    Return the concatenation m & t & 'E' & n.

previous sub-section next sub-sectionE.2 Duration-related Definitions

The following functions are primarily used with the duration datatype and its derivatives.

Auxiliary duration-related Functions Operating on Representation Fragments
·duYearFragmentMap· (Y) → integer
Maps a duYearFrag to an integer, intended as part of the value of the ·months· property of a duration value.
Arguments:
Ymatches duYearFrag
Result:
a nonnegative integer
Algorithm:
Y is necessarily the letter 'Y' followed by a numeral N:
Return ·noDecimalMap·(N).
·duMonthFragmentMap· (M) → integer
Maps a duMonthFrag to an integer, intended as part of the value of the ·months· property of a duration value.
Arguments:
Mmatches duYearFrag
Result:
a nonnegative integer
Algorithm:
M is necessarily the letter 'M' followed by a numeral N:
Return ·noDecimalMap·(N).
·duDayFragmentMap· (D) → integer
Maps a duDayFrag to an integer, intended as part of the value of the ·seconds· property of a duration value.
Arguments:
Dmatches duDayFrag
Result:
a nonnegative integer
Algorithm:
D is necessarily the letter 'D' followed by a numeral N:
Return ·noDecimalMap·(N).
·duHourFragmentMap· (H) → integer
Maps a duHourFrag to an integer, intended as part of the value of the ·seconds· property of a duration value.
Arguments:
Hmatches duHourFrag
Result:
a nonnegative integer
Algorithm:
D is necessarily the letter 'D' followed by a numeral N:
Return ·noDecimalMap·(N).
·duMinuteFragmentMap· (M) → integer
Maps a duMinuteFrag to an integer, intended as part of the value of the ·seconds· property of a duration value.
Arguments:
Mmatches duMinuteFrag
Result:
a nonnegative integer
Algorithm:
M is necessarily the letter 'M' followed by a numeral N:
Return ·noDecimalMap·(N).
·duSecondFragmentMap· (S) → decimal number
Maps a duSecondFrag to a decimal number, intended as part of the value of the ·seconds· property of a duration value.
Arguments:
Smatches duSecondFrag
Result:
a nonnegative decimal number
Algorithm:
S is necessarily 'S' followed by a numeral N:
Return
·duYearMonthFragmentMap· (YM) → integer
Maps a duYearMonthFrag into an integer, intended as part of the ·months· property of a duration value.
Arguments:
YMmatches duYearMonthFrag
Result:
a nonnegative integer
Algorithm:
YM necessarily consists of an instance Y of duYearFrag and/or an instance M of duMonthFrag:
Let
Return  12 × y + m .
·duTimeFragmentMap· (T) → decimal number
Maps a duTimeFrag into a decimal number, intended as part of the ·seconds· property of a duration value.
Arguments:
Tmatches duTimeFrag
Result:
a nonnegative decimal number
Algorithm:
T necessarily consists of an instance H of duHourFrag, and/or an instance M of duMinuteFrag, and/or an instance S of duSecondFrag.
Let
Return  3600 × h + 60 × m + s .
·duDayTimeFragmentMap· (DT) → decimal number
Maps a duDayTimeFrag into a decimal number, which is the potential value of the ·seconds· property of a duration value.
Arguments:
DTmatches duDayTimeFrag
Result:
a nonnegative decimal number
Algorithm:
DT necesarily consists of an instance D of duDayFrag and/or an instance T of duTimeFrag.
Let
Return  86400 × d + t .

The duration Lexical Mapping
·durationMap· (DUR) → duration
Separates the durationLexicalRep into the month part and the seconds part, then maps them into the ·months· and ·seconds· of the duration value.
Arguments:
DURmatches durationLexicalRep
Result:
a complete duration value
Algorithm:
DUR consists of possibly a leading '-', followed by 'P' and then an instance Y of duYearMonthFrag and/or an instance D of duDayTimeFrag:
Return a duration whose and whose

The yearMonthDuration Lexical Mapping
·yearMonthDurationMap· (YM) → yearMonthDuration
Maps the lexical representation into the ·months· of a yearMonthDuration value.  (A yearMonthDuration's ·seconds· is always zero.)  ·yearMonthDurationMap· is a restriction of ·durationMap·.
Arguments: Result:
a complete yearMonthDuration value
Algorithm:
YM necessarily consists of an optional leading '-', followed by 'P' and then an instance Y of duYearMonthFrag:
Return a yearMonthDuration whose

The dayTimeDuration Lexical Mapping
·dayTimeDurationMap· (DT) → dayTimeDuration
Maps the lexical representation into the ·seconds· of a dayTimeDuration value.  (A dayTimeDuration's ·months· is always zero.)  ·dayTimeDurationMap· is a restriction of ·durationMap·.
Arguments:
DTa dayTimeDuration value
Result:
a complete dayTimeDuration value
Algorithm:
DT necessarily consists of possibly a leading '-', followed by 'P' and then an instance D of duDayTimeFrag:
Return a dayTimeDuration whose

Auxiliary duration-related Functions Producing Representation Fragments
·duYearMonthCanonicalFragmentMap· (ym) → duYearMonthFrag
Maps a nonnegative integer, presumably the absolute value of the ·months· of a duration value, to a duYearMonthFrag, a fragment of a duration ·lexical representation·.
Arguments:
yma nonnegative integer
Result: Algorithm:
Let
Return
·duDayCanonicalFragmentMap· (d) → duDayFrag
Maps a nonnegative integer, presumably the day normalized value from the ·seconds· of a duration value, to a duDayFrag, a fragment of a duration ·lexical representation·.
Arguments:
da nonnegative integer
Result: Algorithm:
Return
·duHourCanonicalFragmentMap· (h) → duHourFrag
Maps a nonnegative integer, presumably the hour normalized value from the ·seconds· of a duration value, to a duHourFrag, a fragment of a duration ·lexical representation·.
Arguments:
ha nonnegative integer
Result: Algorithm:
Return
·duMinuteCanonicalFragmentMap· (m) → duMinuteFrag
Maps a nonnegative integer, presumably the minute normalized value from the ·seconds· of a duration value, to a duMinuteFrag, a fragment of a duration ·lexical representation·.
Arguments:
ma nonnegative integer
Result: Algorithm:
Return
·duSecondCanonicalFragmentMap· (s) → duSecondFrag
Maps a nonnegative decimal number, presumably the second normalized value from the ·seconds· of a duration value, to a duSecondFrag, a fragment of a duration ·lexical representation·.
Arguments:
sa nonnegative decimal number
Result:
matches duSecondFrag
Algorithm:
Return
·duTimeCanonicalFragmentMap· (hms) → duTimeFrag
Maps three nonnegative numbers, presumably the hour, minute, and second normalized values from a duration's ·seconds·, to a duTimeFrag, a fragment of a duration ·lexical representation·.
Arguments:
ha nonnegative integer
ma nonnegative integer
sa nonnegative decimal number
Result: Algorithm:
Return
·duDayTimeCanonicalFragmentMap· (ss) → duDayTimeFrag
Maps a nonnegative decimal number, presumably the absolute value of the ·seconds· of a duration value, to a duDayTimeFrag, a fragment of a duration ·lexical representation·.
Arguments:
ssa nonnegative decimal number
Result: Algorithm:
Let
Return

The duration Canonical Mapping
·durationCanonicalMap· (v) → durationLexicalRep
Maps a duration's property values to durationLexicalRep fragments and combines the fragments into a complete durationLexicalRep.
Arguments:
va complete duration value
Result: Algorithm:
Let
  • m be v's ·months·,
  • s be v's ·seconds·, and
  • sgn be '-' if m or s is negative and the empty string ('') otherwise.
Return

The yearMonthDuration Canonical Mapping
Arguments:
yma complete yearMonthDuration value
Result: Algorithm:
Let
  • m be ym's ·months· and
  • sgn be '-' if m is negative and the empty string ('') otherwise.
Return  sgn & 'P' & ·duYearMonthCanonicalFragmentMap·(| m |) .

The dayTimeDuration Canonical Mapping
Arguments:
dta complete dayTimeDuration value
Result: Algorithm:
Let
  • s be dt's ·months· and
  • sgn be '-' if s is negative and the empty string ('') otherwise.
Return sgn & 'P' & ·duYearMonthCanonicalFragmentMap·(| s |) .

previous sub-section next sub-sectionE.3 Date/time-related Definitions

        E.3.1 Normalization of property values
        E.3.2 Auxiliary Functions
        E.3.3 Adding durations to dateTimes
        E.3.4 Time on timeline
        E.3.5 Lexical mappings
        E.3.6 Canonical Mappings

E.3.1 Normalization of property values

When adding and subtracting numbers from date/time properties, the immediate results may not conform to the limits specified.  Accordingly, the following procedures are used to "normalize" potential property values to corresponding values that do conform to the appropriate limits.  Normalization is required when dealing with timezone changes (as when converting to ·UTC· from "local" values) and when adding duration values to or subtracting them from dateTime values.

Date/time Datatype Normalizing Procedures
·normalizeMonth· (yrmo)
If month (mo) is out of range, adjust month and year (yr) accordingly; otherwise, make no change.
Arguments:
yran integer
moan integer
Algorithm:
  1. Add  (mo − 1) ·div· 12  to yr.
  2. Set mo to  (mo − 1) ·mod· 12 + 1 .
·normalizeDay· (yrmoda)
If month (mo) is out of range, or day (da) is out of range for the appropriate month, then adjust values accordingly, otherwise make no change.
Arguments:
yran integer
moan integer
daan integer
Algorithm:
  1. ·normalizeMonth·(yrmo)
  2. Repeat until da is positive and not greater than ·daysInMonth·(yrmo):
    1. If da exceeds the upper limit from the table then:
      1. Subtract that limit from da.
      2. Add 1 to mo.
      3. ·normalizeMonth·(yrmo)
    2. If da is not positive then:
      1. Subtract 1 from mo.
      2. ·normalizeMonth·(yrmo)
      3. Add the new upper limit from the table to da.
·normalizeMinute· (yrmodahrmi)
Normalizes minute, hour, month, and year values to values that obey the appropriate constraints.
Arguments:
yran integer
moan integer
daan integer
hran integer
mian integer
Algorithm:
  1. Add   mi ·div· 60  to hr.
  2. Set mi to  mi ·mod· 60 .
  3. Add  hr ·div· 24  to da.
  4. Set hr to  hr ·mod· 24 .
  5. ·normalizeDay·(yrmoda).
·normalizeSecond· (yrmodahrmise)
Normalizes second, minute, hour, month, and year values to values that obey the appropriate constraints.  (This algorithm ignores leap seconds.)
Arguments:
yran integer
moan integer
daan integer
hran integer
mian integer
sea decimal number
Algorithm:
  1. Add  se ·div· 60  to mi.
  2. Set se to se ·mod· 60 .
  3. ·normalizeMinute·(yrmodahrmi).

E.3.2 Auxiliary Functions

Date/time Auxiliary Functions
·daysInMonth· (ym) → integer
Returns the number of the last day of the month for any combination of year and month.
Arguments:
yan ·optional· integer
man integer between 1 and 12
Result:
between 28 and 31 inclusive
Algorithm:
Return:
  • 28   when m is 2 and y is not evenly divisible by 4, or is evenly divisible by 100 but not by 400, or is absent,
  • 29   when m is 2 and y is evenly divisible by 400, or is evenly divisible by 4 but not by 100,
  • 30   when m is 4, 6, 9, or 11,
  • 31   otherwise (m is 1, 3, 5, 7, 8, 10, or 12)
·newDateTime· (YrMoDaHrMiSeTz) → an instance of the date/timeSevenPropertyModel
Returns an instance of the date/timeSevenPropertyModel with property values as specified in the arguments. If an argument is omitted, the corresponding property is set to absent.
Arguments:
Yran ·optional· integer
Moan ·optional· integer between 1 and 12 inclusive
Daan ·optional· integer between 1 and 31 inclusive
Hran ·optional· integer between 0 and 24 inclusive
Mian ·optional· integer between 0 and 59 inclusive
Sean ·optional· decimal number greater than or equal to 0 and less than 60
Tzan ·optional· duration between -PT14H and PT14H, inclusive.
Result:
Algorithm:
Let
Return dt.

E.3.3 Adding durations to dateTimes

Given a dateTime S and a duration D, function ·dateTimePlusDuration· specifies how to compute a dateTime E, where E is the end of the time period with start S and duration D i.e. E = S + D.  Such computations are used, for example, to determine whether a dateTime is within a specific time period.  This algorithm can also be applied, when applications need the operation, to the addition of durations to the datatypes date, gYearMonth, gYear, gDay and gMonth, each of which can be viewed as denoting a set of dateTimes. In such cases, the addition is made to the first or starting dateTime in the set.  Note that the extension of this algorithm to types other than dateTime is not needed for schema-validity assessment.

Essentially, this calculation adds the ·months· and ·seconds· properties of the duration value separately to the dateTime value. The ·months· value is added to the starting dateTime value first. If the day is out of range for the new month value, it is pinned to be within range. Thus April 31 turns into April 30. Then the ·seconds· value is added. This latter addition can cause the year, month, day, hour, and minute to change.

Leap seconds are ignored by the computation. All calculations use 60 seconds per minute.

Thus the addition of either PT1M or PT60S to any dateTime will always produce the same result. This is a special definition of addition which is designed to match common practice, and—most importantly—be stable over time.

A definition that attempted to take leap-seconds into account would need to be constantly updated, and could not predict the results of future implementation's additions. The decision to introduce a leap second in ·UTC· is the responsibility of the [International Earth Rotation Service (IERS)]. They make periodic announcements as to when leap seconds are to be added, but this is not known more than a year in advance. For more information on leap seconds, see [U.S. Naval Observatory Time Service Department].

Adding duration to dateTime
·dateTimePlusDuration· (dudt) → dateTime
Adds a duration to a dateTime value, producing another dateTime value.
Arguments:
dua duration value
dta dateTime value
Result:
a dateTime value
Algorithm:
Let
  1. Add du's ·months· to mo.
  2. ·normalizeMonth·(yrmo). (I.e., carry any over- or underflow, adjust month.)
  3. Set da to  min(da·daysInMonth·(yrmo)). (I.e., pin the value if necessary.)
  4. Add du's ·seconds· to se.
  5. ·normalizeSecond·(yrmodahrmise). (I.e., carry over- or underflow of seconds up to minutes, hours, etc.)
  6. Return ·newDateTime·(yr, mo, da, hr, mi, se, tz)

This algorithm may be applied to date/time types other than dateTime, by

  1. For each absent property, supply the minimum legal value for that property (1 for years, months, days, 0 for hours, minutes, seconds).
  2. Call the function.
  3. For each property absent in the initial value, set the corresponding property in the result value to absent.

Examples:

dateTimedurationresult
2000-01-12T12:13:14ZP1Y3M5DT7H10M3.3S2001-04-17T19:23:17.3Z
2000-01-P3M1999-10
2000-01-12PT33H2000-01-13

Note that the addition defined by ·dateTimePlusDuration· differs from addition on integers or real numbers in not being commutative. The order of addition of durations to instants is significant. For example, there are cases where:

((dateTime + duration1) + duration2) != ((dateTime + duration2) + duration1)

Example:

  • (2000-03-30 + P1D) + P1M = 2000-03-31 + P1M = 2000-04-30
  • (2000-03-30 + P1M) + P1D = 2000-04-30 + P1D = 2000-05-01

E.3.4 Time on timeline

Time on Timeline for Date/time Seven-property Model Datatypes
·timeOnTimeline· (dt) → decimal number
Maps a date/timeSevenPropertyModel value to the decimal number representing its position on the "time line".
Arguments: Result:
a decimal number
Algorithm:
Let
  1. Subtract ·timezone· from mi   when ·timezone· is not absent.
  2. (·year·)
    1. Set ToTl to  31536000 × yr .
  3. (Leap-year Days, ·month·, and ·day·)
    1. Add  86400 × (yr ·div· 400 − yr ·div· 100 + yr ·div· 4)  to ToTl.
    2. Add   86400 × Summ < mo ·daysInMonth·(yr + 1, m) to ToTl
    3. Add   86400 × da  to ToTl.
  4. (·hour·, ·minute·, and ·second·)
    1. Add  3600 × hr + 60 × mi + se  to ToTl.
  5. Return ToTl.

E.3.5 Lexical mappings

Partial Date/time Lexical Mappings
·yearFragValue· (YR) → integer
Maps a yearFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·year· property of a date/timeSevenPropertyModel value.
Arguments:
YRmatches yearFrag
Result:
an integer
Algorithm:
Return ·noDecimalMap·(YR)
·monthFragValue· (MO) → integer
Maps a monthFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·month· property of a date/timeSevenPropertyModel value.
Arguments:
MOmatches monthFrag
Result:
an integer
Algorithm:
·dayFragValue· (DA) → integer
Maps a dayFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·day· property of a date/timeSevenPropertyModel value.
Arguments:
DAmatches dayFrag
Result:
an integer
Algorithm:
·hourFragValue· (HR) → integer
Maps a hourFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·hour· property of a date/timeSevenPropertyModel value.
Arguments:
HRmatches hourFrag
Result:
an integer
Algorithm:
·minuteFragValue· (MI) → integer
Maps a minuteFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·minute· property of a date/timeSevenPropertyModel value.
Arguments:
MImatches minuteFrag
Result:
an integer
Algorithm:
·secondFragValue· (SE) → decimal number
Maps a secondFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto a decimal number, presumably the ·second· property of a date/timeSevenPropertyModel value.
Arguments:
SEmatches secondFrag
Result:
a decimal number
Algorithm:
Return
·timezoneFragValue· (TZ) → integer
Maps a timezoneFrag, part of a date/timeSevenPropertyModel's ·lexical representation·, onto an integer, presumably the ·timezone· property of a date/timeSevenPropertyModel value.
Arguments:
TZmatches timezoneFrag
Result:
an integer
Algorithm:
TZ necessarily consists of either just 'Z', or a sign ('+' or '-') followed by an instance H of hourFrag, a colon, and an instance M of minuteFrag
Return
Lexical Mapping
Arguments:
LEXmatches dateTimeLexicalRep
Result:
a complete dateTime value
Algorithm:
LEX necessarily includes an instance Y of yearFrag, an instance MO of monthFrag, and an instance D of dayFrag hyphen-separated, an instance H of hourFrag, an instance MI of minuteFrag, and an instance S of secondFrag, colon-separated and optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
Lexical Mapping
·timeLexicalMap· (LEX) → time
Maps a timeLexicalRep to a time value.
Arguments:
LEXmatches timeLexicalRep
Result:
a complete time value
Algorithm:
LEX necessarily includes an instance H of hourFrag, an instance M of minuteFrag, and an instance S of secondFrag, colon-separated and optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent
  1. Return ·newDateTime·(absent, absent, absent, ·hourFragValue·(H), ·minuteFragValue·(M), ·secondFragValue·(S), tz).
Lexical Mapping
·dateLexicalMap· (LEX) → date
Maps a dateLexicalRep to a date value.
Arguments:
LEXmatches dateLexicalRep
Result:
a complete date value
Algorithm:
LEX necessarily includes an instance Y of yearFrag, an instance M of monthFrag, and an instance D of dayFrag, hyphen-separated and optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent
  1. Return ·newDateTime·(·yearFragValue·(Y), ·monthFragValue·(M), ·dayFragValue·(D), absent, absent, absent, tz).
Lexical Mapping
Arguments:
LEXmatches gYearMonthLexicalRep
Result:
a complete gYearMonth value
Algorithm:
LEX necessarily includes an instance Y of yearFrag and an instance M of monthFrag, hyphen-separated and optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
  1. Return ·newDateTime·(·yearFragValue·(Y), ·monthFragValue·(M), absent, absent, absent, absent, tz)
Lexical Mapping
·gYearLexicalMap· (LEX) → gYear
Maps a gYearLexicalRep to a gYear value.
Arguments:
LEXmatches gYearLexicalRep
Result:
a complete gYear value
Algorithm:
LEX necessarily includes an instance Y of dayFrag, optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
  1. Return ·newDateTime·(·dayFragValue·(Y), absent, absent, absent, absent, absent, tz).
Lexical Mapping
Arguments:
LEXmatches gMonthDayLexicalRep
Result:
a complete gMonthDay value
Algorithm:
LEX necessarily includes an instance M of monthFrag and an instance D of dayFrag, hyphen-separated and optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
  1. Return ·newDateTime·(gMD, absent, ·monthFragValue·(Y), ·dayFragValue·(M), absent, absent, absent, tz)
Lexical Mapping
·gDayLexicalMap· (LEX) → gDay
Maps a gDayLexicalRep to a gDay value.
Arguments:
LEXmatches gDayLexicalRep
Result:
a complete gDay value
Algorithm:
LEX necessarily includes an instance D of dayFrag, optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
  1. Return ·newDateTime·(gD, absent, absent, ·dayFragValue·(D), absent, absent, absent, tz).
Lexical Mapping
·gMonthLexicalMap· (LEX) → gMonth
Maps a gMonthLexicalRep to a gMonth value.
Arguments:
LEXmatches gMonthLexicalRep
Result:
a complete gMonth value
Algorithm:
LEX necessarily includes an instance M of monthFrag, optionally followed by an instance T of timezoneFrag.
Let tz be ·timezoneFragValue·(T) when T is present, otherwise absent.
  1. Return ·newDateTime·(gM, absent, ·monthFragValue·(M), absent, absent, absent, absent, tz)

E.3.6 Canonical Mappings

Auxiliary Functions for Date/time Canonical Mappings
·unsTwoDigitCanonicalFragmentMap· (i) → unsignedNoDecimalPtNumeral
Maps a nonnegative integer less than 100 onto an unsigned always-two-digit numeral.
Arguments:
ia nonnegative integer less than 100
Result: Algorithm:
Return ·digit·(i ·div· 10) & ·digit·(i ·mod· 10)
·fourDigitCanonicalFragmentMap· (i) → noDecimalPtNumeral
Maps an integer between -10000 and 10000 onto an always-four-digit numeral.
Arguments:
ian integer whose absolute value is less than 10000
Result: Algorithm:
Partial Date/time Canonical Mappings
·yearCanonicalFragmentMap· (y) → yearFrag
Maps an integer, presumably the ·year· property of a date/timeSevenPropertyModel value, onto a yearFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Arguments:
yan integer
Result:
matches yearFrag
Algorithm:
Return
Arguments:
man integer between 1 and 12 inclusive
Result:
matches monthFrag
Algorithm:
·dayCanonicalFragmentMap· (d) → dayFrag
Maps an integer, presumably the ·day· property of a date/timeSevenPropertyModel value, onto a dayFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Arguments:
dan integer between 1 and 31 inclusive  (may be limited further depending on associated ·year· and ·month·)
Result:
matches dayFrag
Algorithm:
·hourCanonicalFragmentMap· (h) → hourFrag
Maps an integer, presumably the ·hour· property of a date/timeSevenPropertyModel value, onto a hourFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Arguments:
han integer between 0 and 23 inclusive.
Result:
matches hourFrag
Algorithm: Arguments:
man integer between 0 and 59 inclusive.
Result:
matches minuteFrag
Algorithm:
·secondCanonicalFragmentMap· (s) → secondFrag
Maps a decimal number, presumably the ·second· property of a date/timeSevenPropertyModel value, onto a secondFrag, part of a date/timeSevenPropertyModel's ·lexical representation·.
Arguments:
sa nonnegative decimal number less than 70
Result:
matches secondFrag
Algorithm: Arguments:
tan integer between −840 and 840 inclusive
Result:
matches timezoneFrag
Algorithm:
Return
Canonical Mapping
Arguments:
dta complete dateTime value
Result: Algorithm:
Return
Canonical Mapping
Arguments:
tia complete time value
Result: Algorithm:
Return
Canonical Mapping
Arguments:
daa complete date value
Result: Algorithm:
Return
Canonical Mapping
Arguments:
yma complete gYearMonth value
Result: Algorithm:
Return
Canonical Mapping
Arguments:
gYa complete gYear value
Result: Algorithm:
Canonical Mapping
Arguments:
mda complete gMonthDay value
Result: Algorithm:
Let MD be  '--' & ·monthCanonicalFragmentMap·(md's ·month·) & '-' & ·dayCanonicalFragmentMap·(md's ·day·) .
Return
Canonical Mapping
Arguments:
gDa complete gDay value
Result: Algorithm:
Return
Canonical Mapping
Arguments:
gMa complete gMonth value
Result: Algorithm:
Return

previous sub-section E.4 Lexical and Canonical Mappings for Other Datatypes

The following functions are used with various datatypes neither numeric nor date/time related.

Lexical Mapping
·stringLexicalMap· (LEX) → string
Maps a ·literal· matching the stringRep production to a string value.
Arguments:
LEXa ·literal· matching stringRep
Result:
A string value
Algorithm:
Return LEX.  (The function is the identity function on the domain.)
Lexical Mapping
·booleanLexicalMap· (LEX) → boolean
Maps a ·literal· matching the booleanRep production to a boolean value.
Arguments:
LEXa ·literal· matching booleanRep
Result:
A boolean value
Algorithm:
Return
  • true   when LEX is 'true' or '1' , and
  • false   otherwise (LEX is 'false' or '0').
Canonical Mapping
·stringCanonicalMap· (s) → stringRep
Maps a string value to a stringRep.
Arguments:
sa string value
Result:
matches stringRep
Algorithm:
Return s.  (The function is the identity function on the domain.)
Canonical Mapping
Arguments:
ba boolean value
Result:
matches booleanRep
Algorithm:
Return
  • 'true'   when b is true, and
  • 'false'   otherwise (b is false).

E.4.1 Lexical and canonical mappings for hexBinary

The ·lexical mapping· for hexBinary maps each pair of hexadecimal digits to an octet, in the conventional way:

Lexical Mapping for hexBinary
·hexBinaryMap· (LEX) → hexBinary
Maps a ·literal· matching the hexBinary production to a sequence of octets in the form of a hexBinary value.
Arguments:
LEXa ·literal· matching hexBinary
Result:
A sequence of binary octets in the form of a hexBinary value
Algorithm:
LEX necessarily includes a sequence of zero or more substrings matching the hexOctet production.
Let o be the sequence of octets formed by applying ·hexOctetMap· to each hexOctet in LEX, in order, and concatenating the results.
Return o.

The auxiliary functions ·hexOctetMap· and ·hexDigitMap· are used by ·hexBinaryMap·.

Mappings for hexadecimal digits
·hexOctetMap· (LEX) → octet
Maps a ·literal· matching the hexOctet production to a single octet.
Arguments:
LEXa ·literal· matching hexOctet
Result:
A single binary octet
Algorithm:
LEX necessarily includes exactly two hexadecimal digits.
Let d0 be the first hexadecimal digit in LEX. Let d1 be the second hexadecimal digit in LEX.
Return the octet whose four high-order bits are ·hexDigitMap·(d0) and whose four low-order bits are ·hexDigitMap·(d1).
·hexDigitMap· (d) → a bit-sequence of length four
Maps a hexadecimal digit (a character matching the hexDigit production) to a sequence of four binary digits.
Arguments:
da hexadecimal digit
Result:
a sequence of four binary digits
Algorithm:
Return
  • 0000 when d = '0',
  • 0001 when d = '1',
  • 0010 when d = '2',
  • 0011 when d = '3',
  • ...
  • 1110 when d = 'E' or 'e',
  • 1111 when d = 'F' or 'f'.

The ·canonical mapping· for hexBinary uses only the uppercase forms of A-F.

Canonical Mapping for hexBinary
·hexBinaryCanonical· (o) → hexBinary
Maps a hexBinary value to a literal matching the hexBinary production.
Arguments:
oa hexBinary value
Result:
matches hexBinary
Algorithm:
Let h be the sequence of literals formed by applying ·hexOctetCanonical· to each octet in o, in order, and concatenating the results.
Return h.
Auxiliary procedures for canonical mapping of hexBinary
·hexOctetCanonical· (o) → hexOctet
Maps a binary octet to a literal matching the hexOctet production.
Arguments:
oa binary octet
Result:
matches hexOctet
Algorithm:
Let lo be the four low-order bits of o, and hi be the four high-order bits.
·hexDigitCanonical· (b) → hexDigit
Maps a four-bit sequence to a hexadecimal digit (a literal matching the hexDigit production).
Arguments:
ba sequence of four binary digits
Result:
matches hexDigit
Algorithm:
Return
  • '0' when d = 0000,
  • '1' when d = 0001,
  • '2' when d = 0010,
  • '3' when d = 0011,
  • ...
  • 'E' when d = 1110,
  • 'F' when d = 1111.

F Datatypes and Facets

F.1 Fundamental Facets

The following table shows the values of the fundamental facets for each ·built-in· datatype.

 Datatypeorderedboundedcardinalitynumeric
primitivestringfalsefalsecountably infinitefalse
booleanfalsefalsefinitefalse
floatpartialtruefinitetrue
doublepartialtruefinitetrue
decimaltotalfalsecountably infinitetrue
precisionDecimalpartialfalsecountably infinitetrue
durationpartialfalsecountably infinitefalse
dateTimepartialfalsecountably infinitefalse
timepartialfalsecountably infinitefalse
datepartialfalsecountably infinitefalse
gYearMonthpartialfalsecountably infinitefalse
gYearpartialfalsecountably infinitefalse
gMonthDaypartialfalsecountably infinitefalse
gDaypartialfalsecountably infinitefalse
gMonthpartialfalsecountably infinitefalse
hexBinaryfalsefalsecountably infinitefalse
base64Binaryfalsefalsecountably infinitefalse
anyURIfalsefalsecountably infinitefalse
QNamefalsefalsecountably infinitefalse
NOTATIONfalsefalsecountably infinitefalse
non-primitivenormalizedStringfalsefalsecountably infinitefalse
tokenfalsefalsecountably infinitefalse
languagefalsefalsecountably infinitefalse
IDREFSfalsefalsecountably infinitefalse
ENTITIESfalsefalsecountably infinitefalse
NMTOKENfalsefalsecountably infinitefalse
NMTOKENSfalsefalsecountably infinitefalse
Namefalsefalsecountably infinitefalse
NCNamefalsefalsecountably infinitefalse
IDfalsefalsecountably infinitefalse
IDREFfalsefalsecountably infinitefalse
ENTITYfalsefalsecountably infinitefalse
integertotalfalsecountably infinitetrue
nonPositiveIntegertotalfalsecountably infinitetrue
negativeIntegertotalfalsecountably infinitetrue
longtotaltruefinitetrue
inttotaltruefinitetrue
shorttotaltruefinitetrue
bytetotaltruefinitetrue
nonNegativeIntegertotalfalsecountably infinitetrue
unsignedLongtotaltruefinitetrue
unsignedInttotaltruefinitetrue
unsignedShorttotaltruefinitetrue
unsignedBytetotaltruefinitetrue
positiveIntegertotalfalsecountably infinitetrue
yearMonthDurationpartialfalsecountably infinitefalse
dayTimeDurationpartialfalsecountably infinitefalse

G Regular Expressions

A ·regular expression· R is a sequence of characters that denote a set of strings  L(R). When used to constrain a ·lexical space·, a regular expression  R asserts that only strings in L(R) are valid ·literals· for values of that type.

Note:  Unlike some popular regular expression languages (including those defined by Perl and standard Unix utilities), the regular expression language defined here implicitly anchors all regular expressions at the head and tail, as the most common use of regular expressions in ·pattern· is to match entire ·literals·. For example, a datatype derived from string such that all values must begin with the character A (#x41) and end with the character Z (#x5a) would be defined as follows:
<simpleType name='myString'>
 <restriction base='string'>
  <pattern value='A.*Z'/>
 </restriction>
</simpleType>
In regular expression languages that are not implicitly anchored at the head and tail, it is customary to write the equivalent regular expression as:

   ^A.*Z$

where "^" anchors the pattern at the head and "$" anchors at the tail.

In those rare cases where an unanchored match is desired, including .* at the beginning and ending of the regular expression will achieve the desired results. For example, a datatype derived from string such that all values must contain at least 3 consecutive A (#x41) characters somewhere within the value could be defined as follows:

<simpleType name='myString'>
 <restriction base='string'>
  <pattern value='.*AAA.*'/>
 </restriction>
</simpleType>

[Definition:]  A regular expression is composed from zero or more ·branch·es, separated by | characters.

Regular Expression
[64]   regExp   ::=    branch ( '|' branch )*

For all ·branch·es S, and for all ·regular expression·s T, valid ·regular expression·s R are: Denoting the set of strings L(R) containing:
(empty string)the set containing just the empty string
Sall strings in L(S)
S|Tall strings in L(S) and all strings in L(T)

[Definition:]   A branch consists of zero or more ·piece·s, concatenated together.

Branch
[65]   branch   ::=   piece*

For all ·piece·s S, and for all ·branch·es T, valid ·branch·es R are: Denoting the set of strings L(R) containing:
Sall strings in L(S)
STall strings st with s in L(S) and t in L(T)

[Definition:]   A piece is an ·atom·, possibly followed by a ·quantifier·.

Piece
[66]   piece   ::=   atom quantifier?

For all ·atom·s S and non-negative integers n, m such that n <= m, valid ·piece·s R are: Denoting the set of strings L(R) containing:
Sall strings in L(S)
S?the empty string, and all strings in L(S).
S* All strings in L(S?) and all strings st with s in L(S*) and t in L(S). ( all concatenations of zero or more strings from L(S) )
S+ All strings st with s in L(S) and t in L(S*)( all concatenations of one or more strings from L(S) )
S{n,m} All strings st with s in L(S) and t in L(S{n-1,m-1})( All sequences of at least n, and at most m, strings from L(S) )
S{n} All strings in L(S{n,n})( All sequences of exactly n strings from L(S) )
S{n,} All strings in L(S{n}S*) ( All sequences of at least n, strings from L(S) )
S{0,m} All strings st with s in L(S?) and t in L(S{0,m-1})( All sequences of at most m, strings from L(S) )
S{0,0} The set containing only the empty string
Note:  The regular expression language in the Perl Programming Language [Perl] does not include a quantifier of the form S{,m}, since it is logically equivalent to S{0,m}. We have, therefore, left this logical possibility out of the regular expression language defined by this specification.

[Definition:]   A quantifier is one of ?, *, +, {n,m} or {n,}, which have the meanings defined in the table above.

Quantifier
[67]   quantifier   ::=   [?*+] | ( '{' quantity '}' )
[68]   quantity   ::=   quantRange | quantMin | QuantExact
[69]   quantRange   ::=   QuantExact ',' QuantExact
[70]   quantMin   ::=   QuantExact ','
[71]   QuantExact   ::=   [0-9]+

[Definition:]   An atom is either a ·normal character·, a ·character class·, or a parenthesized ·regular expression·.

Atom
[72]   atom   ::=   Char | charClass | ( '(' regExp ')' )

For all ·normal character·s c, ·character class·es C, and ·regular expression·s S, valid ·atom·s R are: Denoting the set of strings L(R) containing:
cthe single string consisting only of c
Call strings in L(C)
(S)all strings in L(S)

[Definition:]   A metacharacter is either ., \, ?, *, +, {, } (, ), |, [, or ]. These characters have special meanings in ·regular expression·s, but can be escaped to form ·atom·s that denote the sets of strings containing only themselves, i.e., an escaped ·metacharacter· behaves like a ·normal character·.

[Definition:]   A normal character is any XML character that is not a metacharacter.  In ·regular expression·s, a normal character is an atom that denotes the singleton set of strings containing only itself.

Normal Character
[73]   Char   ::=   [^.\?*+{}()|#x5B#x5D]

Note that a ·normal character· can be represented either as itself, or with a character reference.

G.1 Character Classes

[Definition:]   A character class is an ·atom·  R that identifies a set of characters  C(R).  The set of strings L(R) denoted by a character class R contains one single-character string "c" for each character c in C(R).

Character Class
[74]   charClass   ::=    charClassEsc | charClassExpr | WildcardEsc

A character class is either a ·character class escape· or a ·character class expression·.

[Definition:]   A character class expression is a ·character group· surrounded by [ and ] characters.  For all character groups G, [G] is a valid character class expression, identifying the set of characters C([G]) = C(G).

Character Class Expression
[75]   charClassExpr   ::=   '[' charGroup ']'

[Definition:]   A character group is either a ·positive character group·, a ·negative character group·, or a ·character class subtraction·.

Character Group
[76]   charGroup   ::=    posCharGroup | negCharGroup | charClassSub

[Definition:]   A positive character group consists of one or more ·character range·s or ·character class escape·s, concatenated together.  A positive character group identifies the set of characters containing all of the characters in all of the sets identified by its constituent ranges or escapes.

Positive Character Group
[77]   posCharGroup   ::=    ( charRange | charClassEsc )+

For all ·character range·s R, all ·character class escape·s E, and all ·positive character group·s P, valid ·positive character group·s G are: Identifying the set of characters C(G) containing:
Rall characters in C(R).
Eall characters in C(E).
RPall characters in C(R) and all characters in C(P).
EPall characters in C(E) and all characters in C(P).

[Definition:]   A negative character group is a ·positive character group· preceded by the ^ character. For all ·positive character group·s P, ^P is a valid negative character group, and C(^P) contains all XML characters that are not in C(P).

Negative Character Group
[78]   negCharGroup   ::=   '^' posCharGroup

[Definition:]   A character class subtraction is a ·character class expression· subtracted from a ·positive character group· or ·negative character group·, using the - character.

Character Class Subtraction
[79]   charClassSub   ::=    ( posCharGroup | negCharGroup ) '-' charClassExpr

For any ·positive character group· or ·negative character group· G, and any ·character class expression· C, G-C is a valid ·character class subtraction·, identifying the set of all characters in C(G) that are not also in C(C).

[Definition:]   A character range R identifies a set of characters C(R) containing all XML characters with UCS code points in a specified range.

Character Range
[80]   charRange   ::=    seRange | XmlCharIncDash
[81]   seRange   ::=   charOrEsc '-' charOrEsc
[82]   charOrEsc   ::=   XmlChar | SingleCharEsc
[83]   XmlChar   ::=   [^\#x2D#x5B#x5D]
[84]   XmlCharIncDash   ::=   [^\#x5B#x5D]

A single XML character is a ·character range· that identifies the set of characters containing only itself.  All XML characters are valid character ranges, except as follows:

Note: The grammar for ·character range· as given above is ambiguous, but the second and third bullets above together remove the ambiguity.

A ·character range· ·may· also be written in the form s-e, identifying the set that contains all XML characters with UCS code points greater than or equal to the code point of s, but not greater than the code point of e.

s-e is a valid character range iff:

Note:  The code point of a ·single character escape· is the code point of the single character in the set of characters that it identifies.

G.1.1 Character Class Escapes

[Definition:]   A character class escape is a short sequence of characters that identifies predefined character class.  The valid character class escapes are the ·single character escape·s, the ·multi-character escape·s, and the ·category escape·s (including the ·block escape·s).

Character Class Escape
[85]   charClassEsc   ::=    ( SingleCharEsc | MultiCharEsc | catEsc | complEsc )

[Definition:]   A single character escape identifies a set containing a only one character -- usually because that character is difficult or impossible to write directly into a ·regular expression·.

Single Character Escape
[86]   SingleCharEsc   ::=   '\' [nrt\|.?*+(){}#x2D#x5B#x5D#x5E]

The valid ·single character escape·s are: Identifying the set of characters C(R) containing:
\nthe newline character (#xA)
\rthe return character (#xD)
\tthe tab character (#x9)
\\\
\||
\..
\--
\^^
\??
\**
\++
\{{
\}}
\((
\))
\[[
\]]

[Definition:]   [Unicode Database] specifies a number of possible values for the "General Category" property and provides mappings from code points to specific character properties. The set containing all characters that have property X, can be identified with a category escape \p{X}. The complement of this set is specified with the category escape \P{X}. ([\P{X}] = [^\p{X}]).

Category Escape
[87]   catEsc   ::=   '\p{' charProp '}'
[88]   complEsc   ::=   '\P{' charProp '}'
[89]   charProp   ::=   IsCategory | IsBlock
Note:  [Unicode Database] is subject to future revision.  For example, the mapping from code points to character properties might be updated. All ·minimally conforming· processors ·must· support the character properties defined in the version of [Unicode Database] cited in the normative references (Normative (§J.1)).  However, implementors are encouraged to support the character properties defined in any future version.

The following table specifies the recognized values of the "General Category" property.

CategoryPropertyMeaning
LettersLAll Letters
Luuppercase
Lllowercase
Lttitlecase
Lmmodifier
Loother
 
MarksMAll Marks
Mnnonspacing
Mcspacing combining
Meenclosing
 
NumbersNAll Numbers
Nddecimal digit
Nlletter
Noother
 
PunctuationPAll Punctuation
Pcconnector
Pddash
Psopen
Peclose
Piinitial quote (may behave like Ps or Pe depending on usage)
Pffinal quote (may behave like Ps or Pe depending on usage)
Poother
 
SeparatorsZAll Separators
Zsspace
Zlline
Zpparagraph
 
SymbolsSAll Symbols
Smmath
Sccurrency
Skmodifier
Soother
 
OtherCAll Others
Cccontrol
Cfformat
Coprivate use
Cnnot assigned
Categories
[90]   IsCategory   ::=    Letters | Marks | Numbers | Punctuation | Separators | Symbols | Others
[91]   Letters   ::=   'L' [ultmo]?
[92]   Marks   ::=   'M' [nce]?
[93]   Numbers   ::=   'N' [dlo]?
[94]   Punctuation   ::=   'P' [cdseifo]?
[95]   Separators   ::=   'Z' [slp]?
[96]   Symbols   ::=   'S' [mcko]?
[97]   Others   ::=   'C' [cfon]?
Note:  The properties mentioned above exclude the Cs property. The Cs property identifies "surrogate" characters, which do not occur at the level of the "character abstraction" that XML instance documents operate on.

[Definition:]   [Unicode Database] groups code points into a number of blocks such as Basic Latin (i.e., ASCII), Latin-1 Supplement, Hangul Jamo, CJK Compatibility, etc. The set containing all characters that have block name X (with all white space stripped out), can be identified with a block escape \p{IsX}. The complement of this set is specified with the block escape \P{IsX}. ([\P{IsX}] = [^\p{IsX}]).

Block Escape
[98]   IsBlock   ::=   'Is' [a-zA-Z0-9#x2D]+

The following table specifies the recognized block names (for more information, see the "Blocks.txt" file in [Unicode Database]).

Start CodeEnd CodeBlock Name Start CodeEnd CodeBlock Name
#x0000#x007FBasicLatin #x0080#x00FFLatin-1Supplement
#x0100#x017FLatinExtended-A #x0180#x024FLatinExtended-B
#x0250#x02AFIPAExtensions #x02B0#x02FFSpacingModifierLetters
#x0300#x036FCombiningDiacriticalMarks #x0370#x03FFGreek
#x0400#x04FFCyrillic #x0500#x052FCyrillicSupplement
#x0530#x058FArmenian #x0590#x05FFHebrew
#x0600#x06FFArabic #x0700#x074FSyriac
#x0750#x077FArabicSupplement #x0780#x07BFThaana
#x0900#x097FDevanagari #x0980#x09FFBengali
#x0A00#x0A7FGurmukhi #x0A80#x0AFFGujarati
#x0B00#x0B7FOriya #x0B80#x0BFFTamil
#x0C00#x0C7FTelugu #x0C80#x0CFFKannada
#x0D00#x0D7FMalayalam #x0D80#x0DFFSinhala
#x0E00#x0E7FThai #x0E80#x0EFFLao
#x0F00#x0FFFTibetan #x1000#x109FMyanmar
#x10A0#x10FFGeorgian #x1100#x11FFHangulJamo
#x1200#x137FEthiopic #x1380#x139FEthiopicSupplement
#x13A0#x13FFCherokee #x1400#x167FUnifiedCanadianAboriginalSyllabics
#x1680#x169FOgham #x16A0#x16FFRunic
#x1700#x171FTagalog #x1720#x173FHanunoo
#x1740#x175FBuhid #x1760#x177FTagbanwa
#x1780#x17FFKhmer #x1800#x18AFMongolian
#x1900#x194FLimbu #x1950#x197FTaiLe
#x1980#x19DFNewTaiLue #x19E0#x19FFKhmerSymbols
#x1A00#x1A1FBuginese #x1D00#x1D7FPhoneticExtensions
#x1D80#x1DBFPhoneticExtensionsSupplement #x1DC0#x1DFFCombiningDiacriticalMarksSupplement
#x1E00#x1EFFLatinExtendedAdditional #x1F00#x1FFFGreekExtended
#x2000#x206FGeneralPunctuation #x2070#x209FSuperscriptsandSubscripts
#x20A0#x20CFCurrencySymbols #x20D0#x20FFCombiningMarksforSymbols
#x2100#x214FLetterlikeSymbols #x2150#x218FNumberForms
#x2190#x21FFArrows #x2200#x22FFMathematicalOperators
#x2300#x23FFMiscellaneousTechnical #x2400#x243FControlPictures
#x2440#x245FOpticalCharacterRecognition #x2460#x24FFEnclosedAlphanumerics
#x2500#x257FBoxDrawing #x2580#x259FBlockElements
#x25A0#x25FFGeometricShapes #x2600#x26FFMiscellaneousSymbols
#x2700#x27BFDingbats #x27C0#x27EFMiscellaneousMathematicalSymbols-A
#x27F0#x27FFSupplementalArrows-A #x2800#x28FFBraillePatterns
#x2900#x297FSupplementalArrows-B #x2980#x29FFMiscellaneousMathematicalSymbols-B
#x2A00#x2AFFSupplementalMathematicalOperators #x2B00#x2BFFMiscellaneousSymbolsandArrows
#x2C00#x2C5FGlagolitic #x2C80#x2CFFCoptic
#x2D00#x2D2FGeorgianSupplement #x2D30#x2D7FTifinagh
#x2D80#x2DDFEthiopicExtended #x2E00#x2E7FSupplementalPunctuation
#x2E80#x2EFFCJKRadicalsSupplement #x2F00#x2FDFKangxiRadicals
#x2FF0#x2FFFIdeographicDescriptionCharacters #x3000#x303FCJKSymbolsandPunctuation
#x3040#x309FHiragana #x30A0#x30FFKatakana
#x3100#x312FBopomofo #x3130#x318FHangulCompatibilityJamo
#x3190#x319FKanbun #x31A0#x31BFBopomofoExtended
#x31C0#x31EFCJKStrokes #x31F0#x31FFKatakanaPhoneticExtensions
#x3200#x32FFEnclosedCJKLettersandMonths #x3300#x33FFCJKCompatibility
#x3400#x4DB5CJKUnifiedIdeographsExtensionA #x4DC0#x4DFFYijingHexagramSymbols
#x4E00#x9FFFCJKUnifiedIdeographs #xA000#xA48FYiSyllables
#xA490#xA4CFYiRadicals #xA700#xA71FModifierToneLetters
#xA800#xA82FSylotiNagri #xAC00#xD7A3HangulSyllables
[See note following this table.] [See note following this table.]
[See note following this table.] #xE000#xF8FFPrivateUse
#xF900#xFAFFCJKCompatibilityIdeographs #xFB00#xFB4FAlphabeticPresentationForms
#xFB50#xFDFFArabicPresentationForms-A #xFE00#xFE0FVariationSelectors
#xFE10#xFE1FVerticalForms #xFE20#xFE2FCombiningHalfMarks
#xFE30#xFE4FCJKCompatibilityForms #xFE50#xFE6FSmallFormVariants
#xFE70#xFEFFArabicPresentationForms-B 
#xFF00#xFFEFHalfwidthandFullwidthForms #xFFF0#xFFFFSpecials
#x10000#x1007FLinearBSyllabary #x10080#x100FFLinearBIdeograms
#x10100#x1013FAegeanNumbers #x10140#x1018FAncientGreekNumbers
#x10300#x1032FOldItalic #x10330#x1034FGothic
#x10380#x1039FUgaritic #x103A0#x103DFOldPersian
#x10400#x1044FDeseret #x10450#x1047FShavian
#x10480#x104AFOsmanya #x10800#x1083FCypriotSyllabary
#x10A00#x10A5FKharoshthi #x1D000#x1D0FFByzantineMusicalSymbols
#x1D100#x1D1FFMusicalSymbols #x1D200#x1D24FAncientGreekMusicalNotation
#x1D300#x1D35FTaiXuanJingSymbols #x1D400#x1D7FFMathematicalAlphanumericSymbols
#x20000#x2A6DFCJKUnifiedIdeographsExtensionB #x2F800#x2FA1FCJKCompatibilityIdeographsSupplement
#xE0000#xE007FTags #xE0100#xE01EFVariationSelectorsSupplement
#xF0000#xFFFFFSupplementaryPrivateUseArea-A #x100000#x10FFFFSupplementaryPrivateUseArea-B
Note:  The blocks mentioned above exclude the HighSurrogates, LowSurrogates and HighPrivateUseSurrogates blocks. These blocks identify "surrogate" characters, which do not occur at the level of the "character abstraction" that XML instance documents operate on.
Note:  [Unicode Database] is subject to future revision. For example, the grouping of code points into blocks might be updated. All ·minimally conforming· processors ·must· support the blocks defined in the version of [Unicode Database] cited in the normative references (Normative (§J.1)).  However, implementors are encouraged to support the blocks defined in any future version of the Unicode Standard.

For example, the ·block escape· for identifying the ASCII characters is \p{IsBasicLatin}.

[Definition:]   A multi-character escape provides a simple way to identify a commonly used set of characters:

Multi-Character Escape
[99]   MultiCharEsc   ::=   '\' [sSiIcCdDwW]
[100]   WildcardEsc   ::=   '.'

Character sequenceEquivalent ·character class·
.[^\n\r]
\s[#x20\t\n\r]
\S[^\s]
\i the set of initial name characters, those ·matched· by NameStartChar in [XML] or by Letter | '_' | ':' in [XML 1.0]
\I[^\i]
\c the set of name characters, those ·matched· by NameChar
\C[^\c]
\d\p{Nd}
\D[^\d]
\w [#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}] (all characters except the set of "punctuation", "separator" and "other" characters)
\W[^\w]
Note:  The ·regular expression· language defined here does not attempt to provide a general solution to "regular expressions" over UCS character sequences.  In particular, it does not easily provide for matching sequences of base characters and combining marks. The language is targeted at support of "Level 1" features as defined in [Unicode Regular Expression Guidelines].  It is hoped that future versions of this specification will provide support for "Level 2" features.

H Changes since version 1.0

next sub-sectionH.1 Datatypes, and Facets and Related Rewrites

The model of an abstract datatype has been made more precise and explicit.  Datatype System (§2) has mostly been rewritten and been "formally blessed" by the WG.  Driving this new text is not only a desire on the part of the WG to make it "more precise and explicit" but also a specific formal requirement to redo the handling of facets (RQ-24 (systematic facets)).  The primary intent of this requirement was to move the description of equality, identity, and order to Value space (§2.2).The treatment of datatypes has been made more precise and explicit; most of these changes affect the section on Datatype System (§2). Definitions have been revised thoroughly and technical terms are used more consistently.

RQ-24 (systematic facets: separate identity and equality) directed that we provide for equality that in some cases was different from identity.  Most datatypes still use identity as their equality, but the new precisionDecimal and the redesigned date/time datatypes will not.  float and double use this capability to separate minus zero from plus zero; they non-identical but equal.The (numeric) equality of values is now distinguished from the identity of the values themselves; this allows float and double to treat positive and negative zero as distinct values for purposes of enumeration, but nevertheless to treat them as equal for purposes of bounds checking. This allows a better alignment with the expectations of users working with IEEE floating-point binary numbers.

The {value} of the bounded component for list datatypes is now always false, reflecting the fact that no ordering is prescribed for ·list· datatypes are not ordered (except by the trivial order), and hence cannot reasonably be boundedso they cannot be bounded using the facets defined by this specification.

Units of length have been selectedspecified for all datatypes that are permitted the length constraining facet (RQ-6 (length for [almost] all primitive types)).

The use of the namespace http://www.w3.org/2001/XMLSchema-datatypes has been deprecated. The definition of a namespace separate from the main namespace defined by this specification proved not to be necessary or helpful in facilitating the use, by other specifications, of the datatypes defined here, and its use raises a number of difficult unsolved practical questions.

previous sub-section next sub-sectionH.2 Numerical Datatypes

The precisionDecimal datatype has been added.  It is intended to support the floating-point decimal datatypes defined in the forthcoming version of IEEE 754. The precisionDecimal datatype differs from decimal in that values carry not only a numeric value but also an (arithmetic) precision. 

As noted above, positive and negative zero, float and double are now treated as distinct but arithmetically equal values.

The description of the lexical spaces of unsignedLong, unsignedInt, unsignedShort, and unsignedByte has been revised to agree with the schema for schemas by allowing for the possibility of a leading sign.

The float and double datatypes now follow IEEE 754 implementation practice more closely; in particular, negative and positive zero are now distinct values, although arithmetically equal. Conversely, NaN is identical but not arithmetically equal to itself.

The minimum requirements for implementation support of the precisionDecimal datatype have been clarified.

previous sub-section next sub-sectionH.3 Date/time Datatypes

RQ-122 (define dateTime value space) has resulted in a revision of the value space for all date/time datatypes (except duration, which was changed as a result of another requirement).  The most visible effect of this change was to cause the values to retain knowledge of their timezone, which is explained in the new material.  The new version specifies a seven-property model used uniformly for values in all of these datatypes, described in The Seven-property Model (§D.2.1).  Only gDay (§3.3.14) has been rewritten to match this new generic approach; the other date/time datatype descriptions will be rewritten in a future draft.  These rewrites and the new Date/time Values (§D.2) have not yet been approved by the WG; in versions of this specification that show adds and dels, this material shows as a proposed change.  ↓The treatment of dateTime and related datatypes has been changed to provide a more explicit account of the value space in terms of seven numeric properties. The most important substantive change is that values now explicitly retain information about the time zone indicated in the lexical form; this allows better alignment with the treatment of such values in [XQuery 1.0 and XPath 2.0 Functions and Operators].

The seven property model rewrite of date/time datatype descriptions includes a carefully crafted definition of order that insures that for repeating datatypes (time, gDay, etc.), timezoned values will be compared as though they are on the same "calendar day" ("local" property values) so that in any given timezone, the days start at "local" 00:00:00 and end not quite including "local" 24:00:00.  Days are not 00:00:00Z to 24:00:00Z in timezones other than Z.  This covers the requirements of RQ-13 (time zone crosses date line).  In addition, in satisfaction of RQ-123 (year 0000 in date/time datatypes), the lexical representation '0000' for years is made legal and the mapping of values with negative years onto the timeline has been changed to match.  E.g., the year 0000 is 1 B.C.E., the year −0001 is 2 B.C.E., etc.  (This is a change from version 1.0 of this specification.)The treatment of the date/time datatype includes a carefully revised definition of order that ensures that for repeating datatypes (time, gDay, etc.), timezoned values will be compared as though they are on the same "calendar day" ("local" property values) so that in any given timezone, the days start at the local midnight and end just before local midnight.  Days do not run from 00:00:00Z to 24:00:00Z in timezones other than Z.

The lexical representation '0000' for years is recognized and maps to the year 1 BCE; '-0001' maps to 2 BCE, etc. This is a change from version 1.0 of this specification, in order to align with established practice (the so-called "astronomical year numbering") and [ISO 8601].

Algorithms for arithmetic involving dateTime and duration values have been provided, and corrections made to the ·timeOnTimeline· function.

The treatment of leap seconds is no longer implementation-defined: the date/time types described here do not include leap-second values.

previous sub-section H.4 Other changes

Support has been added for [XML] version 1.1 and [Namespaces in XML] version 1.1. The datatypes which depend on [XML] and [Namespaces in XML] may now be used with the definitions provided by the 1.1 versions of those specifications, as well as with the definitions in the 1.0 versions. It is implementation-defined whether software conforming to this specification supports the definitions given in version 1.0, or in version 1.1, of [XML] and [Namespaces in XML].

The account of the value space of duration has been changed to specify that values consist only of two numbers (the number of months and the number of seconds) rather than six (years, months, days, hours, minutes, seconds). This allows clearly equivalent durations like P2Y and P24M to have the same value.

Two new totally ordered restrictions of duration have been defined: yearMonthDuration, defined in yearMonthDuration (§3.4.26), and dayTimeDuration, defined in dayTimeDuration (§3.4.27). This allows better alignment with the treatment of durations in [XQuery 1.0 and XPath 2.0 Functions and Operators].

The XML representations of the ·primitive· and ·ordinary· built-in datatypes have been moved out of the schema document for schema documents in Schema for Schema Documents (Datatypes) (normative) (§A) and into a different appendix (Illustrative XML representations for the built-in simple type definitions (§C)).

Numerous minor corrections have been made in response to comments on earlier working drafts.

The treatment of topics handled both in this specification and in [XML Schema Part 1: Structures] has been revised to align the two specifications more closely.

Several references to other specifications have been updated to refer to current versions of those specifications, including [XML], [Namespaces in XML], [RFC 3986], [RFC 3987], and [RFC 3548].

Requirements for the datatype-validity of values of type language have been clarified.

Explicit definitions have been provided for the lexical and ·canonical mappings· of most of the primitive datatypes.

Some errors in the definition of regular-expression metacharacters have been corrected.

The descriptions of the pattern and enumeration facets have been revised to make clearer how values from different derivation steps are combined.

A warning against using the whitespace facet for tokenizing natural-language data has been added on the request of the W3C Internationalization Working Group.

I Glossary (non-normative)

The listing below is for the benefit of readers of a printed version of this document: it collects together all the definitions which appear in the document above.

active basic member
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.
active member type
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.
ancestor
The ancestors of a type definition are its {base type definition} and the ·ancestors· of its {base type definition}.
arithmetic precision
The arithmetic precision of a value is expressed in absolute quantitative terms, by indicating how many digits to the right of the decimal point are significant.
atomic
Atomic datatypes are those having values treated by this specification as indivisible.  Atomic datatypes are anyAtomicType and all datatypes ·derived· from it.
base type
Every datatype is associated with another datatype, its base type. Base types can be ·special·, ·primitive·, or ·ordinary·.
basic member
Those members of the ·transitive membership· of a ·union· datatype U which are themselves not ·union· datatypes are the basic members of U.
built-in
Built-in datatypes are those which are defined in this specification; they can be ·special·, ·primitive·, or ·ordinary· datatypes .
canonical mapping
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·).
canonical representation
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·
conformance to the XML Representation of Schemas
Processors which accept schemas in the form of XML documents as described in XML Representation of Simple Type Definition Schema Components (§4.1.2) (and other relevant portions of Datatype components (§4)) are additionally said to provide conformance to the XML Representation of Schemas, and ·must·, when processing schema documents, completely and correctly implement all ·Schema Representation Constraint·s in this specification, and ·must· adhere exactly to the specifications in XML Representation of Simple Type Definition Schema Components (§4.1.2) (and other relevant portions of Datatype components (§4)) for mapping the contents of such documents to schema components for use in validation.
constraining facet
constraining facets are schema components whose values may be set or changed during ·derivation· (subject to facet-specific controls) to control various aspects of the derived datatype.
Constraint on Schemas
Constraint on Schemas
constructed
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·.
datatype
In this specification, a datatype has three properties
derived
A datatype T is immediately derived from another datatype X if and only if X is the ·base type· of T.
derived
A datatype R is derived from another datatype B if and only if one of the following is true:
div
If m and n are numbers, then m div n is the greatest integer less than or equal to m / n .
error
error
facet-based restriction
A datatype is defined by facet-based restriction of another datatype (its ·base type·), when values for zero or more ·constraining facets· are specified that serve to constrain its ·value space· and/or its ·lexical space· to a subset of those of the ·base type·.
for compatibility
for compatibility
fundamental facet
Each fundamental facet is a schema component that provides a limited piece of information about some aspect of each datatype.
incomparable
Two values that are neither equal, less-than, nor greater-than are incomparable. Two values that are not ·incomparable· are comparable.
intervening union
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· if 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.
item type
The ·atomic· or ·union· datatype that participates in the definition of a ·list· datatype is the item type of that ·list· datatype.
leap-second
A leap-second is an additional second added to the last day of December, June, October, or March, when such an adjustment is deemed necessary by the International Earth Rotation and Reference Systems Service in order to keep ·UTC· within 0.9 seconds of observed astronomical time.  When leap seconds are introduced, the last minute in the day has more than sixty seconds.  In theory leap seconds can also be removed from a day, but this has not yet occurred. Leap seconds are not supported by the types defined here.
lexical mapping
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.
lexical representation
The members of the ·lexical space· are lexical representations of the values to which they are mapped.
lexical space
The lexical space of a datatype is the prescribed domain of ·the lexical mapping· for that datatype.
list
List datatypes are those having values each of which consists of a finite-length (possibly empty) sequence of values of an ·atomic· datatype (or a ·union· of ·atomic· datatypes), which is the ·item type· of the list.
literal
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.
match
match
may
may
member types
The datatypes that participate in the definition of a ·union· datatype are known as the member types of that ·union· datatype.
minimally conforming
Minimally conforming processors ·must· completely and correctly implement the ·Constraint on Schemas· and ·Validation Rule·.
mod
If m and n are numbers, then m mod n is  m − n × ( m ·div· n) .
must
must
optional
An optional property is permitted but not required to have the special value absent.
ordered
A ·value space·, and hence a datatype, is said to be ordered if this specification prescribes a non-trivial order for that ·value space·.
ordinary
Ordinary datatypes are all datatypes other than the ·special· and ·primitive· datatypes.
owner
A component may be referred to as the owner of its properties, and of the values of those properties.
precisionDecimal
The precisionDecimal datatype represents the numeric value and (arithmetic) precision of decimal numbers which retain precision; it also includes special values for positive and negative infinity and "not a number", and it differentiates between "positive zero" and "negative zero".
primitive
Primitive datatypes are those datatypes that are not ·special· and are not defined in terms of other datatypes; they exist ab initio.
regular expression
A regular expression is composed from zero or more ·branch·es, separated by | characters.
restriction
A datatype R is a restriction of another datatype B when
Schema Representation Constraint
Schema Representation Constraint
special
The special datatypes are anySimpleType and anyAtomicType.
transitive membership
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.
union
Union datatypes are (a) those whose ·value spaces·, and ·lexical spaces·, and ·lexical mappings· are the union of the ·value spaces·, and ·lexical spaces·, and ·lexical mappings· of one or more other datatypes, which are the ·member types· of the union, or (b) those derived by ·facet-based restriction· of another union datatype.
user-defined
User-defined datatypes are those datatypes that are defined by individual schema designers.
UTC
Universal Coordinated Time (UTC) is an adaptation of TAI which closely approximates UT1 by adding ·leap-seconds· to selected ·UTC· days.
Validation Rule
Validation Rule
value space
The value space of a datatype is the set of values for that datatype.

J References

next sub-sectionJ.1 Normative

Clinger, WD (1990)
William D Clinger. How to Read Floating Point Numbers Accurately. In Proceedings of Conference on Programming Language Design and Implementation, pages 92-101. Available at: ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps
IEEE 754-1985
IEEE. IEEE Standard for Binary Floating-Point Arithmetic. See http://standards.ieee.org/
ITU-R TF.460-6
International Telecommunication Union (ITU). Recommendation ITU-R TF.460-6: Standard-frequency and time-signal emissions. [Geneva: ITU, February 2002.]
Namespaces in XML↑
World Wide Web Consortium.  Namespaces in XML 1.1. Available at: http://www.w3.org/TR/xml-names11/For details of the dependency of this specification on Namespaces in XML 1.1, see Dependencies on Other Specifications (§1.3).
Namespaces in XML 1.0
World Wide Web Consortium.  Namespaces in XML. Available at: http://www.w3.org/TR/REC-xml-names/ For details of the dependency of this specification on Namespaces in XML 1.0, see Dependencies on Other Specifications (§1.3).
RFC 2396
Tim Berners-Lee, et. al. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. 1998.  Available at: http://www.ietf.org/rfc/rfc2396.txt
RFC 2732
RFC 2732: Format for Literal IPv6 Addresses in URL's. 1999. Available at: http://www.ietf.org/rfc/rfc2732.txt
RFC 3548
S. Josefsson, ed. RFC 3548: The Base16, Base32, and Base64 Data Encodings. July 2003.  Available at: http://www.ietf.org/rfc/rfc3548.txt
Unicode Database
The Unicode Consortium. Unicode Character Database. Revision 4.1.0, by Mark Davis and Ken Whistler, 2005-03-30. Available at: http://www.unicode.org/Public/4.1.0/ucd/UCD.html
XML
Extensible Markup Language (XML) 1.1,, Tim Bray et al., eds., W3C, 15 April 2004. See http://www.w3.org/TR/xml11/For details of the dependency of this specification on XML 1.1, see Dependencies on Other Specifications (§1.3).
XML 1.0
Extensible Markup Language (XML) 1.0, Third Edition, Tim Bray et al., eds., W3C, 4 February 2004. See http://www.w3.org/TR/2004/REC-xml-20040204 For details of the dependency of this specification on XML, see Dependencies on Other Specifications (§1.3).
XML Base
World Wide Web Consortium.  XML Base. Available at: http://www.w3.org/TR/2001/REC-xmlbase-20010627/
XML Linking Language
World Wide Web Consortium.  XML Linking Language (XLink). Available at: http://www.w3.org/TR/2001/REC-xlink-20010627/. Note: only the URI reference escaping procedure defined in Section 5.4 is normatively referenced.
XML Schema Part 1: Structures
XML Schema Version 1.1 Part 1: Structures. Available at: http://www.w3.org/TR/2005/WD-xmlschema11-1-20050224/structures.diff-wd.html
XML Schema Requirements

previous sub-section J.2 Non-normative

Character Model
Martin J. Dürst and François Yergeau, eds.  Character Model for the World Wide Web 1.0:  Fundamentals.  2001.  Available at:  http://www.w3.org/TR/2004/WD-charmod-20040225
Gay, DM (1990)
David M. Gay.  Correctly Rounded Binary-Decimal and Decimal-Binary Conversions. AT&T Bell Laboratories Numerical Analysis Manuscript 90-10, November 1990. Available at: http://cm.bell-labs.com/cm/cs/doc/90/4-10.ps.gz
HTML 4.01
World Wide Web Consortium.  Hypertext Markup Language, version 4.01.  Available at: http://www.w3.org/TR/1999/REC-html401-19991224/
IETF INTERNET-DRAFT: IRIs
M. Dürst and M. Suignard . Internationalized Resource Identifiers 2002. Available at: http://www.w3.org/International/iri-edit/draft-duerst-iri-08.txt
International Earth Rotation Service (IERS)
International Earth Rotation Service (IERS). See http://maia.usno.navy.mil
ISO 11404
ISO (International Organization for Standardization). Language-independent Datatypes. See http://www.iso.org/iso/en/ISOOnline.frontpage
ISO 8601
ISO (International Organization for Standardization). Representations of dates and times, 1988-06-15.
ISO 8601:1998 Draft Revision
ISO (International Organization for Standardization). Representations of dates and times, draft revision, 1998.
ISO 8601:2000 Second Edition
ISO (International Organization for Standardization). Representations of dates and times, second edition, 2000-12-15.
Perl
The Perl Programming Language.  See http://www.perl.com/pub/language/info/software.html
RDF Schema
World Wide Web Consortium. RDF Schema Specification. Available at: http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
RFC 2045
N. Freed and N. Borenstein. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. 1996.  Available at: http://www.ietf.org/rfc/rfc2045.txt
RFC 3066
H. Alvestrand, ed. RFC 3066: Tags for the Identification of Languages 1995. Available at: http://www.ietf.org/rfc/rfc3066.txt
RFC 3986
T. Berners-Lee, R. Fielding, and L. Masinter, RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. January 2005.  Available at: http://www.ietf.org/rfc/rfc3986.txt
RFC 3987
M. Duerst and M. Suignard. RFC 3987: Internationalized Resource Identifiers (IRIs) . January 2005.  Available at: http://www.ietf.org/rfc/rfc3987.txt
Ruby
World Wide Web Consortium.  Ruby Annotation.  Available at: http://www.w3.org/TR/2001/REC-ruby-20010531
SQL
ISO (International Organization for Standardization).  ISO/IEC 9075-2:1999, Information technology --- Database languages --- SQL --- Part 2: Foundation (SQL/Foundation). [Geneva]: International Organization for Standardization, 1999. See http://www.iso.org/iso/en/ISOOnline.frontpage
U.S. Naval Observatory Time Service Department
Information about Leap Seconds Available at: http://tycho.usno.navy.mil/leapsec.html
Unicode Regular Expression Guidelines
Mark Davis.  Unicode Regular Expression Guidelines, 1988. Available at: http://www.unicode.org/unicode/reports/tr18/
USNO Historical List
U.S. Naval Observatory Time Service Department, Historical list of leap seconds Available at: ftp://maia.usno.navy.mil/ser7/tai-utc.dat
XML Schema Language: Part 0 Primer
World Wide Web Consortium.  XML Schema Language: Part 0 Primer.  Available at: http://www.w3.org/TR/xmlschema-0/
XML Schema Requirements
XML Schema Requirements , Ashok Malhotra and Murray Maloney, eds., W3C, 15 February 1999. See http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215
XQuery 1.0 and XPath 2.0 Functions and Operators
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Functions and Operators, ed. Ashok Malhotra, Jim Melton, and Norman Walsh. W3C Candidate Recommendation 3 November 2005. Available at: http://www.w3.org/TR/2005/CR-xpath-functions-20051103/.
XSL
World Wide Web Consortium.  Extensible Stylesheet Language (XSL).  Available at:  http://www.w3.org/TR/2001/REC-xsl-20011015/

K Acknowledgements (non-normative)

Along with the editors thereof, the following contributed material to the first version of this specification:

Asir S. Vedamuthu, webMethods, Inc
Mark Davis, IBM

Co-editor Ashok Malhotra's work on this specification from March 1999 until February 2001 was supported by IBM, and from then until May 2004 by Microsoft.  Since July 2004 his work on this specification has been supported by Oracle Corporation.

The XML Schema Working Group acknowledges with thanks the members of other W3C Working Groups and industry experts in other forums who have contributed directly or indirectly to the creation of this document and its predecessor.

At the time this Working Draft is published, the members in good standing of the XML Schema Working Group are:

The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people who are no longer members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we note with sadness the accidental death of Mario Jeckle shortly before publication of the first Working Draft of XML Schema 1.1. Affiliations given are those current at the time of their (first) work with the WG.