This document is also available in these nonnormative 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 builtin datatypes only, in a separate namespace↓, Independent copy of the DTD for schema documents, and List of translations.
Copyright © 2009 W3C^{®} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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 Public Working Draft of↓ ↑ W3C Last Call Working Draft specifies ↑ ↓XML Schema 1.1↓↑the W3C XML Schema Definition Language (XSD) 1.1 Part 2: 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 3 December 2009.
Changes since the previous public Working Draft include the following:
For those primarily interested in the changes since version 1.0, the Changes since version 1.0 (§K) 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:
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/publicbugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, wwwxmlschemacomments@w3.org (archive) ↑and note explicitly that you have not made a Bugzilla entry for the comment.↑ Each Bugzilla entry and email message should contain only one comment.
The Last Call review period for this document extends until 31 December 2009.
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. Any feature mentioned in a priority feedback note is a "feature at risk": the feature may be retained as is or dropped, depending on the feedback received from readers, schema authors, schema users, and implementors.
Publication as a Last Call 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 ↑by a group operating↑ under the 5 February 2004 W3C Patent Policy. ↓The Working Group↓↑W3C↑ maintains a public list of ↑any↑ patent disclosures made in connection with ↓this document↓↑the deliverables of the group↑; 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 dgstatusquocolor1.0.xml
, which shows differences from version 1.0 of this specification. Three kinds of changes are highlighted:
↑new, added text↑,
↑changed text↓, and
↓deleted text↓.
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:
The overall aim as regards compatibility is that
The ↓[XML 1.0]↓↑[XML]↑ specification defines limited facilities for applying datatypes to document content in that documents may contain or refer to DTDs that assign types to elements and attributes. However, document authors, including authors of traditional documents and those transporting data in XML, often require a higher degree of type checking to ensure robustness in document understanding and data interchange.
The table below offers two typical examples of XML instances in which datatypes are implicit: the instance on the left represents a billing invoice, the instance on the right a memo or perhaps an email message in XML.
Data oriented  Document oriented 

<invoice> <orderDate>19990121</orderDate> <shipDate>19990125</shipDate> <billingAddress> <name>Ashok Malhotra</name> <street>123 Microsoft Ave.</street> <city>Hawthorne</city> <state>NY</state> <zip>105320000</zip> </billingAddress> <voice>5551234</voice> <fax>5554321</fax> </invoice> 
<memo importance='high' date='19990323'> <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>5559876</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 XMLrelated standards as well.
Other specifications on which this one depends are listed in References (§M).
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 ·implementationdefined·.
Conforming implementations of this specification may provide either the 1.1based datatypes or the 1.0based datatypes, or both. If both are supported, the choice of which datatypes to use in a particular assessment episode should be under user control.
This specification makes use of the EBNF notation used in the [XML] specification. Note that some constructs of the EBNF notation used here resemble the regularexpression syntax defined in this specification (Regular Expressions (§I)), but that they are not identical: there are differences. For a fuller description of the EBNF notation, see Section 6. Notation of the [XML] specification.
The [XML Schema Requirements] document spells out concrete requirements to be fulfilled by this specification, which state that the XML Schema Language must:
This ↓portion of the XML Schema Language discusses↓↑specification defines↑ 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 XMLrelated activities such as [XSL] and [RDF Schema].
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:
This specification provides three different kinds of normative statements about schema components, their representations in XML and their contribution to the schemavalidation of information items:
This section describes the conceptual framework behind the ↑data↑type system defined in this specification. The framework has been influenced by the [ISO 11404] standard on languageindependent datatypes as well as the datatypes for [SQL] and for programming languages such as Java.
The datatypes discussed in this specification are ↓computer representations of↓↑for the most part↑ well known abstract concepts such as integer and date. It is not the place of this specification to ↑thoroughly ↑define these abstract concepts; many other publications provide excellent definitions.↑ However, this specification will attempt to describe the abstract concepts well enough that they can be readily recognized and distinguished from other abstractions with which they may be confused.↑
[Definition:] In this specification, a datatype is a 3tuple, consisting of a) a set of distinct values, called its ·value space·, b) a set of lexical representations, called its ·lexical space·, and c) a set of ·facet·s that characterize properties of the ·value space·, individual values or lexical items.
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 contextdependent; for these types, no ·canonical mapping· is defined.
[Definition:] A value space is the set of values for a given datatype. Each value in the value space of a datatype is denoted by one or more literals in its ·lexical space·.
[Definition:] The value space of a datatype is the set of values for that datatype. Associated with each value space are selected operations and relations necessary to permit proper schema processing. Each value in the value space of a ·primitive· or ·ordinary· datatype is denoted by one or more character strings in its ·lexical space·, according to ·the lexical mapping·; ·special· datatypes, by contrast, may include "ineffable" values not mapped to by any lexical representation. (If the mapping is restricted during a derivation in such a way that a value has no denotation, that value is dropped from the value space.)
The value spaces of datatypes are abstractions, and are defined in ↓Builtin datatypes↓↑Builtin 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.
·value spaces· have certain properties. For example, they always have the property of ·cardinality·, some definition of equality and might be ·ordered·, by which individual values within the ·value space· can be compared to one another. The properties of ·value spaces· that are recognized by this specification are defined in Fundamental facets (§2.5.1).
The relations of identity and equality are required for each value space. An order relation is specified for some value spaces, but not all. A very few datatypes have other relations or operations prescribed for the purposes of this specification.
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.
In the identity relation defined herein, values from different ·primitive· datatypes' ·value spaces· are made artificially distinct if they might otherwise be considered identical. For example, there is a number two in the decimal datatype and a number two in the float datatype. In the identity relation defined herein, these two values are considered distinct. Other applications making use of these datatypes may choose to consider values such as these identical, but for the view of ·primitive· datatypes' ·value spaces· used herein, they are distinct.
WARNING: Care must be taken when identifying
values across distinct primitive datatypes. The
·literals· '0.1
' and '0.10000000009
' map
to the same value in float (neither 0.1 nor 0.10000000009 is in the value space, and
each literal is mapped to the
nearest value, namely 0.100000001490116119384765625), but map to
distinct values in decimal.
+2
', treated as a decimal,
'+2
', treated as an integer, and
'+2
', treated as a byte, all denote the
same value. They are not only equal but identical.Given a list A and a list B, A and B are the same list if they are the same sequence of atomic values. The necessary and sufficient conditions for this identity are that A and B have the same length and that the items of A are pairwise identical to the items of B.
Each ·primitive· datatype has prescribed an equality relation for its value space. The equality relation for most datatypes is the identity relation. In the few cases where it is not, equality has been carefully defined so that for most operations of interest to the datatype, if two values are equal and one is substituted for the other as an argument to any of the operations, the results will always also be equal.
On the other hand, equality need not cover the entire value space of the datatype (though it usually does). In particular, NaN is not equal to itself in the precisionDecimal, float, and double datatypes.
This equality relation is used when making ·facetbased restrictions· by enumeration, when checking identity constraints (in the context of [XSD 1.1 Part 1: Structures]), when checking value constraints, and in conjunction with order when making ·facetbased restrictions· involving order, with the following exception: When processing XPath expressions as part of XML schemavalidity assessment or otherwise testing membership in the ·value space· of a datatype whose derivation involves ·assertions·, equality (like all other relations) within those expressions is interpreted using the rules of XPath ([XPath 2.0]). All comparisons for "sameness" prescribed by this specification test for equality, not for identity.
In the equality relation defined herein, values from different primitive data spaces are made artificially unequal even if they might otherwise be considered equal. For example, there is a number two in the decimal datatype and a number two in the float datatype. In the equality relation defined herein, these two values are considered unequal. Other applications making use of these datatypes may choose to consider values such as these equal; nonetheless, in the equality relation defined herein, they are unequal.
Two lists A and B are equal if and only if they have the same length and their items are pairwise equal. A list of length one containing a value V1 and an atomic value V2 are equal if and only if V1 is equal to V2.
For the purposes of this specification, there is one equality relation for all values of all datatypes (the union of the various datatype's individual equalities, if one consider relations to be sets of ordered pairs). The equality relation is denoted by '=' and its negation by '≠', each used as a binary infix predicate: x = y and x ≠ y . On the other hand, identity relationships are always described in words.
For some datatypes, an order relation is prescribed for use in checking upper and lower bounds of the ·value space·. This order may be a partial order, which means that there may be values in the ·value space· which are neither equal, lessthan, nor greaterthan. Such value pairs are incomparable. In many cases, no order is prescribed; each pair of values is either equal or ·incomparable·. [Definition:] Two values that are neither equal, lessthan, nor greaterthan are incomparable. Two values that are not ·incomparable· are comparable.
The order relation is used in conjunction with equality when making ·facetbased restrictions· involving order. This is the only use of this order relation for schema processing. Of course, when processing XPath expressions as part of XML schemavalidity assessment or otherwise testing membership in the ·value space· of a datatype whose derivation involves ·assertions·, order (like all other relations) within those expressions is interpreted using the rules of XPath ([XPath 2.0]).
In this specification, this lessthan 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 .
For purposes of this specification, the value spaces of primitive datatypes are disjoint, even in cases where the abstractions they represent might be thought of as having values in common. In the order relations defined in this specification, values from different value spaces are ·incomparable·. For example, the numbers two and three are values in both the decimal datatype and the float datatype. In the order relation defined here, the two in the decimal datatype is not less than the three in the float datatype; the two values are incomparable. Other applications making use of these datatypes may choose to consider values such as these comparable.
In addition to its ·value space·, each datatype also has a lexical space.
[Definition:] A lexical space is the set of valid literals for a datatype.
For example, "100" and "1.0E2" are two different literals from the ·lexical space· of float which both denote the same value. The type system defined in this specification provides a mechanism for schema designers to control the set of values and the corresponding set of acceptable literals of those values for a datatype.
While the datatypes defined in this specification have, for the most part, a single lexical representation i.e. each value in the datatype's ·value space· is denoted by a single literal in its ·lexical space·, this is not always the case. The example in the previous section showed two literals for the datatype float which denote the same value. Similarly, there ·may· be several literals for one of the date or time datatypes that denote the same value using different timezone indicators.
[Definition:] A canonical lexical representation is a set of literals from among the valid set of literals for a datatype such that there is a onetoone mapping between literals in the canonical lexical representation and values in the ·value space·.
[Definition:] The lexical mapping for a datatype is a prescribed relation which maps from the ·lexical space· of the datatype into its ·value space·.
[Definition:] The lexical space of a datatype is the prescribed set of strings which ·the lexical mapping· for that datatype maps to values of that datatype.
[Definition:] The members of the ·lexical space· are lexical representations of the values to which they are mapped.
[Definition:] A sequence of zero or more characters in the Universal Character Set (UCS) which may or may not prove upon inspection to be a member of the ·lexical space· of a given datatype and thus a ·lexical representation· of a given value in that datatype's ·value space·, is referred to as a literal. The term is used indifferently both for character sequences which are members of a particular ·lexical space· and for those which are not.
If a derivation introduces a ·prelexical· facet value (a new value for whiteSpace or an implementationdefined ·prelexical· facet), the corresponding ·prelexical· transformation of a character string, if indeed it changed that string, could prevent that string from ever having the ·lexical mapping· of the derived datatype applied to it. Character strings that a ·prelexical· transformation blocks in this way (i.e., they are not in the range of the ·prelexical· facet's transformation) are always dropped from the derived datatype's ·lexical space·.
Should a derivation be made using a derivation mechanism that removes ·lexical representations· from the·lexical space· to the extent that one or more values cease to have any ·lexical representation·, then those values are dropped from the ·value space·.
Conversely, should a derivation remove values then their ·lexical representations· are dropped from the ·lexical space· unless there is a facet value whose impact is defined to cause the otherwisedropped ·lexical representation· to be mapped to another value instead.
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.
While the datatypes defined in this specification often 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 onetoone 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)
[Definition:] A facet is a single defining aspect of a ·value space·. Generally speaking, each facet characterizes a ·value space· along independent axes or dimensions.
The facets of a datatype serve to distinguish those aspects of one datatype which differ from other datatypes. Rather than being defined solely in terms of a prose description the datatypes in this specification are defined in terms of the synthesis of facet values which together determine the ·value space· and properties of the datatype.
Facets are of two types: fundamental facets that define the datatype and nonfundamental or constraining facets that constrain the permitted values of a datatype.
[Definition:] A fundamental facet is an abstract property which serves to semantically characterize the values in a ·value space·.
All fundamental facets are fully described in Fundamental Facets (§4.2).
[Definition:] A constraining facet is an optional property that can be applied to a datatype to constrain its ·value space·.
Constraining the ·value space· consequently constrains the ·lexical space·. Adding ·constraining facets· to a ·base type· is described in Derivation by restriction (§4.1.2.1).
All constraining facets are fully described in Constraining Facets (§4.3).
It is useful to categorize the datatypes defined in this specification along various dimensions, ↓forming a set of characterization dichotomies↓↑defining terms which can be used to characterize datatypes and the Simple Type Definitions which define them↑.
[Definition:] An atomic value is an elementary value, not constructed from simpler values by any useraccessible means defined by this specification.
For example, a single token which ·matches· Nmtoken from ↓[XML 1.0]↓↑[XML]↑ ↓could be the value↓↑is in the value space↑ of ↓an↓↑the↑ ·atomic· datatype ↓(↓NMTOKEN↓);↓↑,↑ while a sequence of such tokens ↓could be the value of a↓↑is in the value space of the↑ ·list· datatype ↓(↓NMTOKENS↓)↓.
·atomic· datatypes can be either ·primitive· or ·derived·. The ·value space· of an ·atomic· datatype is a set of "atomic" values, which for the purposes of this specification, are not further decomposable. The ·lexical space· of an ·atomic· datatype is a set of literals whose internal structure is specific to the datatype in question.
An ·atomic· datatype has a ·value space· consisting of a set of "atomic" or elementary values.
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 ·userdefined· datatype may have anyAtomicType as its ·base type·.
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·↓↑·List·↑ datatypes are always ↓·derived·↓↑·constructed·↑↑ from some other type; they are never ·primitive·↑. The ·value space· of a ·list· datatype is ↓a↓↑the↑ set of finitelength sequences of ↑zero or more↑ ·atomic· values↑ where each ·atomic· value is drawn from the ·value space· of the lists's ·item type· and has a ·lexical representation· containing no whitespace↑. The ·lexical space· of a ·list· datatype is a set of ↓literals↓↑·literals·↑ ↓whose internal structure↓↑each of which↑ is a spaceseparated sequence of ↓literals↓↑·literals·↑ of the ↓·atomic· datatype of the items in the ·list·↓↑·item type·↑.
[Definition:] The ·atomic· or ·union· datatype that participates in the definition of a ·list· datatype is ↓known as ↓the ↓itemType↓↑item type↑ of that ·list· datatype.↑ If the ·item type· is a ·union·, each of its ·basic members· must be ·atomic·.↑
<simpleType name='sizes'> <list itemType='decimal'/> </simpleType>
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
A ·list· datatype can be ↓·derived·↓↑·constructed·↑ from an ↑ordinary ↑↑or ·primitive· ↑·atomic· datatype whose ·lexical space· allows ↓space↓↑whitespace↑ (such as string or anyURI) or a ·union· datatype any of whose {member type definitions}'s ·lexical space· allows space. ↓In such a case, regardless of the input, list items will be separated at space boundaries.↓↑Since ·list· items are separated at whitespace before the ·lexical representations· of the items are mapped to values, no whitespace will ever occur in the ·lexical representation· of a ·list· item, even when the item type would in principle allow it. For the same reason, when every possible ·lexical representation· of a given value in the ·value space· of the ·item type· includes whitespace, that value can never occur as an item in any value of the ·list· datatype.↑
<simpleType name='listOfString'> <list itemType='string'/> </simpleType>
<someElement xsi:type='listOfString'> this is not list item 1 this is not list item 2 this is not list item 3 </someElement>
For each of ·length·, ·maxLength· and ·minLength·, the ↓unit of ↓length is measured in number of list items. The value of ·whiteSpace· is fixed to the value collapse.
For ·list· datatypes the ·lexical space· is composed of spaceseparated ↓literals↓↑·literals·↑ of ↓its↓↑the↑ ·item type·. ↓Hence, a↓↑A↑ny ·pattern· specified when a new datatype is ·derived· from a ·list· datatype ↓is matched against each literal of the ·list· datatype and not against the literals of the datatype that serves as its ·item type·↓↑applies to the members of the ·list· datatype's ·lexical space·, not to the members of the ·lexical space· of the ·item type·. Similarly, enumerated values are compared to the entire ·list·, not to individual list items, and assertions apply to the entire ·list· too.↑ ↑Lists are identical if and only if they have the same length and their items are pairwise identical; they are equal if and only if they have the same length and their items are pairwise equal. And a list of length one whose item is an atomic value V1 is equal to an atomic value V2 if and only if V1 is equal to V2. ↑
<xs:simpleType name='myList'> <xs:list itemType='xs:integer'/> </xs:simpleType> <xs:simpleType name='myRestrictedList'> <xs:restriction base='myList'> <xs:pattern value='123 (\d+\s)*456'/> </xs:restriction> </xs:simpleType> <someElement xsi:type='myRestrictedList'>123 456</someElement> <someElement xsi:type='myRestrictedList'>123 987 456</someElement> <someElement xsi:type='myRestrictedList'>123 987 567 456</someElement>
The canonicallexicalrepresentation for the ·list· datatype is defined as the lexical form in which each item in the ·list· has the canonical lexical representation of its ·item type·.
The ·canonical mapping· of a ·list· datatype maps each value onto the spaceseparated concatenation of the ·canonical representations· of all the items in the value (in order), using the ·canonical mapping· of the ·item type·.
↑ ↑
↓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·.↑
It will be observed that the ·lexical mapping· of a union, so
defined, is not necessarily a function: a given ↓literal↓↑·literal·↑ may map to
one value or to several values of different ·primitive· datatypes, and
it may be indeterminate which value is to be preferred in a particular
context. When the datatypes defined here are used in the context of
[XSD 1.1 Part 1: Structures], the xsi:type
attribute defined by that
specification in section xsi:type can be used to indicate
which value a ↓literal↓↑·literal·↑ which is the content of an element should map
to. In other contexts, other rules (such as type coercion rules) may
be employed to determine which value is to be used.
↑When a union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·.↑
·Union· datatypes are always ↓·derived·↓↑·constructed·↑↑ from other datatypes; they are never ·primitive·↑. Currently, there are no ·builtin· ·union· datatypes.
<attributeGroup name="occurs"> <attribute name="minOccurs" type="nonNegativeInteger" use="optional" default="1"/> <attribute name="maxOccurs"use="optional" default="1"> <simpleType> <union> <simpleType> <restriction base='nonNegativeInteger'/> </simpleType> <simpleType> <restriction base='string'> <enumeration value='unbounded'/> </restriction> </simpleType> </union> </simpleType> </attribute> </attributeGroup>
Any number ↓(greater than 1)↓↑(zero or more)↑ of ↑ordinary ↑↑ or ·primitive· ↑↓·atomic· or ·list·↓ ↓·datatype·s ↓↑·datatypes·↑ can participate in a ·union· type.
[Definition:] The datatypes that participate in the definition of a ·union· datatype are known as the ↓memberTypes↓↑member types↑ of that ·union· datatype.
[Definition:] The transitive membership of a ·union· is the set of its own ·member types·, and the ·member types· of its members, and so on. More formally, if U is a ·union·, then (a) its ·member types· are in the transitive membership of U, and (b) for any datatypes T1 and T2, if T1 is in the transitive membership of U and T2 is one of the ·member types· of T1, then T2 is also in the transitive membership of U.
The ·transitive membership· of a ·union· must not contain the ·union· itself, nor any datatype ·derived· or ·constructed· from the ·union·.
[Definition:] Those members of the ·transitive membership· of a ·union· datatype U which are themselves not ·union· datatypes are the basic members of U.
[Definition:] If a datatype M is in the ·transitive membership· of a ·union· datatype U, but not one of U's ·member types·, then a sequence of one or more ·union· datatypes necessarily exists, such that the first is one of the ·member types· of U, each is one of the ·member types· of its predecessor in the sequence, and M is one of the ·member types· of the last in the sequence. The ·union· datatypes in this sequence are said to intervene between M and U. When U and M are given by the context, the datatypes in the sequence are referred to as the intervening unions. When M is one of the ·member types· of U, the set of intervening unions is the empty set.
[Definition:] In a valid instance of any ·union·, the first of its members in order which accepts the instance as valid is the active member type. [Definition:] If the ·active member type· is itself a ·union·, one of its members will be its ·active member type·, and so on, until finally a ·basic (nonunion) 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 ↓↑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↓ ↑As noted above,
the↑ evaluation order can be overridden with the use of
xsi:type.
<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 canonicallexicalrepresentation for a ·union· datatype is defined as the lexical form in which the values have the canonical lexical representation of the appropriate ·member types·.
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.
Next, we distinguish between ·primitive· and ·derived· datatypes.
Next, we distinguish ·special·, ·primitive·, and ·ordinary· (or ·constructed·) datatypes. Each datatype defined by or in accordance with this specification falls into exactly one of these categories.
For example, in this specification, float is a ↑·primitive· datatype based on a ↑welldefined mathematical concept ↓that cannot be↓↑and not↑ defined in terms of other datatypes, while↓ a↓ integer is ↓a special case of↓↑·constructed· from↑ the more general datatype decimal.
[Definition:] The simple urtype definition is a special restriction of the urtype definition whose name is anySimpleType in the XML Schema namespace. anySimpleType can be considered as the ·base type· of all ·primitive· datatypes. anySimpleType is considered to have an unconstrained lexical space and a ·value space· consisting of the union of the ·value spaces· of all the ·primitive· datatypes and the set of all lists of all members of the ·value spaces· of all the ·primitive· datatypes.
The datatypes defined by this specification fall into both the ·primitive· and ·derived· categories. It is felt that a judiciously chosen set of ·primitive· datatypes will serve the widest possible audience by providing a set of convenient datatypes that can be used as is, as well as providing a rich enough base from which the variety of datatypes needed by schema designers can be ·derived·.
As described in more detail in XML Representation of Simple Type Definition Schema Components (§4.1.2), each ·userderived· datatype ·must· be defined in terms of another datatype in one of three ways: 1) by assigning ·constraining facets· which serve to restrict the ·value space· of the ·userderived· datatype to a subset of that of the ·base type·; 2) by creating a ·list· datatype whose ·value space· consists of finitelength sequences of values of its ·item type·; or 3) by creating a ·union· datatype whose ·value space· consists of the union of the ·value spaces· of its ·member types·.
[Definition:] A datatype is said to be ·derived· by restriction from another datatype 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 its ·base type·.
[Definition:] A datatype is defined by facetbased 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 ·facetbased restriction· must be a ·primitive· or ·ordinary· datatype.
[Definition:] Every datatype that is ·derived· by ·restriction· is defined in terms of an existing datatype, referred to as its base type. Base types can be either ·primitive· or ·derived·.
A ·list· datatype can be ↓·derived·↓↑·constructed·↑ from another datatype (its ·item type·) by creating a ·value space· that consists of ↓a↓ finitelength sequence↑s↑ of ↑zero or more↑ 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. ↑
One datatype can be ↓·derived·↓↑·constructed·↑ from one or more datatypes by ↓·union·ing↓↑unioning↑ their ↓·value spaces·↓↑·lexical mappings·↑ and, consequently, their ↑·value spaces· and↑ ↓·lexical spaces·↓↑·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. ↑
Definition, derivation, restriction, and construction are conceptually distinct, although in practice they are frequently performed by the same mechanisms.
By 'definition' is meant the explicit identification of the relevant properties of a datatype, in particular its ·value space·, ·lexical space·, and ·lexical mapping·.
The properties of the ·special· and the standard ·primitive· datatypes are defined by this specification. A Simple Type Definition is present for each of these datatypes in every valid schema; it serves as a representation of the datatype, but by itself it does not capture all the relevant information and does not suffice (without knowledge of this specification) to define the datatype.
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 other than anySimpleType is associated with another datatype, its base type. Base types can be ·special·, ·primitive·, or ·ordinary·.
[Definition:] A datatype T is immediately derived from another datatype X if and only if X is the ·base type· of T.
A datatype must not be ·derived· from itself. That is, the base type relation must be acyclic.
It is a consequence of the above that every datatype other than anySimpleType is ·derived· from anySimpleType.
Since each datatype has exactly one ·base type·, and every datatype other than anySimpleType is ·derived· directly or indirectly from anySimpleType, it follows that the ·base type· relation arranges all simple types into a tree structure, which is conventionally referred to as the derivation hierarchy.
By 'restriction' is meant the definition of a datatype whose ·value space· and ·lexical space· are subsets of those of its ·base type·.
Note that all three forms of datatype ·construction· produce ·restrictions· of the ·base type·: ·facetbased 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 "·facetbased restriction·", "·construction· by ·list·", and "·construction· by ·union·", respectively. Datatypes so constructed may be understood fully (for purposes of a type system) in terms of (a) the properties of the datatype(s) from which they are constructed, and (b) their Simple Type Definition. This distinguishes ·ordinary· datatypes from the ·special· and ·primitive· datatypes, which can be understood only in the light of documentation (namely, their descriptions elsewhere in this specification, or, for ·implementationdefined· ·primitives·, in the appropriate implementationspecific documentation). All ·ordinary· datatypes are ·constructed·, and all ·constructed· datatypes are ·ordinary·.
The ·builtin· datatypes are intended to be available automatically whenever this specification is implemented or used, whether by itself or embedded in a host language. In the language defined by [XSD 1.1 Part 1: Structures], the ·builtin· datatypes are automatically included in every valid schema. Other host languages should specify that all of the datatypes decribed here as builtins are automatically available; they may specify that additional datatypes are also made available automatically.
The mechanism for making ·userdefined· datatypes available for use is not defined in this specification; if ·userdefined· datatypes are to be available, some such mechanism must be specified by the host language.
[Definition:] A datatype which is not available for use is said to be unknown.
Conceptually there is no difference between the ↑·ordinary·↑ ·builtin· ↓·derived·↓ datatypes included in this specification and the ↓·userderived·↓↑·userdefined·↑ datatypes which will be created by individual schema designers. The ·builtin· ↓·derived·↓↑·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"↓↑reinventing↑ them. Furthermore, including these ↓·derived·↓↑·constructed·↑ datatypes in this specification serves to demonstrate the mechanics and utility of the datatype generation facilities of this specification.
http://www.w3.org/2001/XMLSchema#int
http://www.w3.org/2001/XMLSchema#maxInclusive
.
') followed by the name of the facethttp://www.w3.org/2001/XMLSchema#int.maxInclusive
The ·builtin· 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 ·builtin· datatypes in this specification have the namespace name:
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 ↓↓ ·builtin· datatype is also defined in the namespace whose URI is:
This applies to both ·builtin· ·primitive· and ·builtin· ·derived· datatypes.
Each ↓·userderived·↓↑·userdefined·↑ datatype ↓is also↓↑may also be↑ associated with a ↓unique↓↑target↑ namespace. ↓However, ·userderived· 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↓↑If it is constructed from a schema document, then its namespace is typically the target namespace of that schema document. (See↑ XML Representation of Schemas in [XSD 1.1 Part 1: Structures]↓).↓↑.)↑
The two datatypes at the root of the hierarchy of simple types are anySimpleType and anyAtomicType.
[Definition:] The definition of anySimpleType is a special ·restriction· of anyType. The ·lexical space· of anySimpleType is the set of all sequences of Unicode characters, and its ·value space· includes all ·atomic values· and all finitelength lists of zero or more ·atomic values·.
For further details of anySimpleType and its representation as a Simple Type Definition, see Builtin Simple Type Definitions (§4.1.7).
The ·value space· of anySimpleType is the set of all ·atomic values· and of all finitelength lists of zero or more ·atomic values·.
The ·lexical space· of anySimpleType is the set of all finitelength sequences of zero or more 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 ·implementationdefined· 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 [XSD 1.1 Part 1: Structures], the
xsi:type
attribute defined by that specification in section
xsi:type can be used
to indicate which value a ·literal· which is the content of an element
should map to. In other contexts, other rules (such as type coercion
rules) may be employed to determine which value is to be used.
When a new datatype is defined by ·facetbased restriction·, anySimpleType must not be used as the ·base type·. So no ·constraining facets· are directly applicable to anySimpleType.
[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 Builtin Simple Type Definitions (§4.1.7).
The ·value space· of anyAtomicType is the union of the ·value spaces· of all the ·primitive· datatypes defined here or supplied as ·implementationdefined· ·primitives·.
The ·lexical space· of anyAtomicType is the set of all finitelength sequences of zero or more 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 ·implementationdefined· 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 [XSD 1.1 Part 1: Structures], the
xsi:type
attribute defined by that specification in section
xsi:type can be used
to indicate which value a ·literal· which is the content of an element
should map to. In other contexts, other rules (such as type coercion
rules) may be employed to determine which value is to be used.
When a new datatype is defined by ·facetbased restriction·, anyAtomicType must not be used as the ·base type·. So no ·constraining facets· are directly applicable to anyAtomicType.
The ·primitive· datatypes defined by this specification are described below. For each datatype, the ·value space· ↑is described; ↑↓and ↓↑the ↑·lexical space· ↓are↓↑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 (§I));↑ ·constraining facets· which apply to the datatype are listed↑;↑ and any datatypes ↓·derived·↓↑·constructed·↑ from this datatype are specified.
↑Conforming processors must support the ·primitive· datatypes defined in this specification; it is ·implementationdefined· whether they support others.↑ ↓·primitive·↓↑·Primitive·↑ datatypes ↓can only↓↑may↑ be added by revisions to this specification.
[Definition:] The string datatype represents character strings in XML.↓ The ·value space· of string is the set of finitelength sequences of characters (as defined in [XML 1.0]) that ·match· the Char production from [XML 1.0]. 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 code point, which is an integer.↓
The ·value space· of string is the set of finitelength sequences of ↑zero or more↑ characters (as defined in ↓[XML 1.0]↓↑[XML]↑) that ·match· the Char production from ↓[XML 1.0]↓↑[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 ·implementationdefined· 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.
It is ·implementationdefined· 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.
↓string has the following ·constraining facets·:↓
↑string has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from string↑ may also specify values for the following↑ ·constraining facets·:↑
string has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from string
[Definition:] boolean ↓has the ·value space· required to support the mathematical concept of binaryvalued logic: {true, false}↓↑represents the values of twovalued logic↑.
boolean has the ·value space· of twovalued logic: {true, false}.
An instance of a datatype that is defined as ·boolean· can have the following legal literals {true, false, 1, 0}.
The ·canonical representation· for boolean is the set of literals {true, false}.
The ·lexical mapping· for boolean is ·booleanLexicalMap·; the ·canonical mapping· is ·booleanCanonicalMap·.
↓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·:
[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 ↓multiplying↓↑dividing↑ an integer by a non↓positive↓↑negative↑ power of ten, i.e., expressible as ↓i × 10^n↓↑i / 10^{n}↑ where i and n are integers and ↓n >= 0↓↑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 ↓·orderrelation·↓↑order relation↑ on decimal is the order relation on real numbers, restricted to this subset.
decimal
has
a lexical representation
consisting of a
↑nonempty↑ finitelength
sequence of
decimal
digits (#x30–#x39) separated
by a period as a decimal indicator.
An optional leading sign is allowed.
If the sign is omitted,
"+"
is assumed. Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example:
↓1.23, 12678967.543233, +100000.00,
210
↓↑'1.23
',
'12678967.543233
', '+100000.00
',
'210
'↑.
(\+)?([09]+(\.[09]*)?\.[09]+)
The mapping from lexical representations to values is the usual one for decimal numerals; it is given formally in ·decimalLexicalMap·.
The definition of the ·canonical representation· has the effect of prohibiting certain options from the Lexical ↓representation↓↑Mapping↑ (§3.3.3.1). Specifically, for integers, the decimal point and fractional part are prohibited. For other values, the preceding optional "+" sign is prohibited. The decimal point is required. In all cases, 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·.
The ·canonical representation· for decimal is defined by prohibiting certain options from the Lexical ↓representation↓↑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.
↓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·:
The following ·builtin· datatype is ·derived· from decimal
[Definition:] The precisionDecimal datatype represents the numeric value and (arithmetic) precision of decimal numbers which retain precision; it also includes values for positive and negative infinity and for "not a number", and it differentiates between "positive zero" and "negative zero". This datatype is introduced to provide a variant of decimal that closely corresponds to the floatingpoint decimal datatypes described by [IEEE 7542008]. Precision of values is retained and values are included for two zeroes, two infinities, and notanumber.
Informally, the precision of a value is denoted by the number of decimal digits after the decimal point in its ·lexical representations·. The numbers 2 and 2.00, although numerically equal, have different precision (0 and 2 respectively). The precision of a value is derived from the ·lexical representation· using rules described in Lexical Mapping (§3.3.4.2). Values retain their precision, but that precision plays no part in any operations defined in this specification other than identity: specifically, it does not affect equality or ordering comparisons. Precision may play a role in arithmetic operations, but that is outside the scope of this specification.
Editorial Note: Priority Feedback Request
The precisionDecimal datatype is a ‘feature at risk’. It may be retained or dropped at the end of the Candidate Recommendation period. The determination of whether to retain it or remove it will depend both on the existence of two independent implementations in the context of this specification and on the degree of uptake of [IEEE 7542008] in the industry. Possible outcomes include retention of precisionDecimal, dropping precisionDecimal, rearrangement of the type hierarchy in this area, and merger with the existing decimal datatype.
NaN
' is the lexical
representation of the precisionDecimal value whose ·numericalValue·
property
has the ·special value·
notANumber. Accordingly, in English text we
use 'NaN' to refer to that value. Similarly we
use 'INF' and '−INF' to refer
to the two values whose
·numericalValue· properties have
the ·special values· positiveInfinity and
negativeInfinity. These three precisionDecimal values are also
informally called "notanumber", "positive
infinity", and "negative infinity". The latter two
together are called "the infinities".NaN
") can be used instead.
INF
',
'+INF
', 'INF
',
and 'NaN
'.
(\+)?([09]+(\.[09]*)?\.[09]+)([Ee](\+)?[09]+)?
(\+)?INFNaN
The ·lexical mapping· for precisionDecimal is ·precisionDecimalLexicalMap·. The ·canonical mapping· is ·precisionDecimalCanonicalMap·.
3
' ( 3 , 0 ,
positive ) '3
'3.00
' ( 3 , 2 ,
positive ) '3.00
'03.00
' ( 3 , 2 ,
positive ) '3.00
'300
' ( 300 , 0 ,
positive ) '300
'3.00e2
' ( 300 , 0 ,
positive ) '300
'3.0e2
' ( 300 , −1 ,
positive ) '3.0E2
'30e1
' ( 300 , −1 ,
positive ) '3.0E2
'.30e3
' ( 300 , −1 ,
positive ) '3.0E2
'↓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·:
[Definition:] ↑The ↑float↑ datatype↑ is↓ patterned after↓↑ patterned after↑ the IEEE singleprecision 32bit floating point ↑data↑type ↓[IEEE 7541985]↓↑[IEEE 7542008]↑↓↓.↓ The basic ·value space· of float consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^24, and e is an integer between 149 and 104, inclusive. In addition to the basic ·value space· described above, the ·value space· of float also contains the following three special values: positive and negative infinity and notanumber (NaN). The ·orderrelation· on float is: x < y iff y  x is positive for x and y in the value space. Positive infinity is greater than all other nonNaN values. NaN equals itself but is incomparable with (neither greater than nor less than) any other value in the ·value space·. ↓↑ Its value space is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.↑
A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· of float that is closest to d in the sense defined by [Clinger, WD (1990)]; if d is exactly halfway between two such values then the even value is chosen.
The ·value space· of float contains the nonzero numbers m × 2^{e} , where m is an integer whose absolute value is less than 2^{24}, and e is an integer between −149 and 104, inclusive. In addition to these values, the ·value space· of float also contains the following ·special values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.
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.NaN
") can be used instead.
float values have a lexical representation
consisting of a mantissa followed, optionally, by the character
'E
' or 'e
',
followed by an exponent. The exponent ·must·
be an integer. The mantissa must be a
decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and decimal. If the
'E
' or 'e
' and
the following exponent are omitted, an exponent value of 0 is assumed.
The special values
positive
and negative infinity and notanumber have lexical representations
INF
, INF
and
NaN
, respectively.
Lexical representations for zero may take a positive or negative sign.
For example, 1E4, 1267.43233E12, 12.78e2, 12
, 0, 0
and INF
are all legal literals for float.
The ·canonical representation· for float is defined by prohibiting certain options from the Lexical representation (§3.3.5.2). Specifically, the exponent must be indicated by "E". Leading zeroes and the preceding optional "+" sign are prohibited in the exponent. If the exponent is zero, it must be indicated by "E0". For the mantissa, the preceding optional "+" sign is prohibited and the decimal point is required. Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit which is nonzero to the left of the decimal point and at least a single digit to the right of the decimal point unless the value being represented is zero. The ·canonical representation· for zero is 0.0E0.
INF
', '+INF
',
'INF
',
and 'NaN
'
(\+)?([09]+(\.[09]*)?\.[09]+)([Ee](\+)?[09]+)?
(\+)?INFNaN
The float datatype is designed to implement for schema
processing the singleprecision floatingpoint datatype of
[IEEE 7542008]. 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·, is a function,
satisfies the requirements of
[IEEE 7542008], and correctly handles the
mapping of the literals
'INF
', 'NaN
', etc., to the
·special values·,
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 interimplementation reproducibility and interimplementation roundtripping. The simple rounding algorithm used in ·floatLexicalMap· may be more efficiently implemented using the algorithms of [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 7542008].
↓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·:
[Definition:] The double datatype is↓ patterned after↓↑ patterned after↑ the IEEE doubleprecision 64bit floating point ↑data↑type ↓[IEEE 7541985]↓↑[IEEE 7542008]↑↓↓.↓ The basic ·value space· of double consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^{53}, and e is an integer between 1075 and 970, inclusive. In addition to the basic ·value space· described above, the ·value space· of double also contains the following three special values: positive and negative infinity and notanumber (NaN). The ·orderrelation· on double is: x < y iff y  x is positive for x and y in the value space. Positive infinity is greater than all other nonNaN values. NaN equals itself but is incomparable with (neither greater than nor less than) any other value in the ·value space·. ↓↑ Each floating point datatype has a value space that is a subset of the rational numbers. Floating point numbers are often used to approximate arbitrary real numbers.↑
A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· of double that is closest to d; if d is exactly halfway between two such values then the even value is chosen. This is the best approximation of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is more accurate than the mapping required by [IEEE 7541985].
The ·value space· of double contains the nonzero numbers m × 2^{e} , where m is an integer whose absolute value is less than 2^{53}, 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 values·: positiveZero, negativeZero, positiveInfinity, negativeInfinity, and notANumber.
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.NaN
") can be used instead.
double values have a lexical representation
consisting of a mantissa followed, optionally, by the character "E" or
"e", followed by an exponent. The exponent ·must· be
an integer. The mantissa must be
a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
integer and
decimal. If the 'E
' or 'e
' and
the following exponent are omitted, an exponent value of 0 is assumed.
The special values
positive
and negative infinity and notanumber have lexical representations
INF
, INF
and
NaN
, respectively.
Lexical representations for zero may take a positive or negative sign.
For example, 1E4, 1267.43233E12, 12.78e2, 12
, 0, 0
and INF
are all legal literals for double.
The ·canonical representation· for double is defined by prohibiting certain options from the Lexical representation (§3.3.6.2). Specifically, the exponent must be indicated by "E". Leading zeroes and the preceding optional "+" sign are prohibited in the exponent. If the exponent is zero, it must be indicated by "E0". For the mantissa, the preceding optional "+" sign is prohibited and the decimal point is required. Leading and trailing zeroes are prohibited subject to the following: number representations must be normalized such that there is a single digit which is nonzero to the left of the decimal point and at least a single digit to the right of the decimal point unless the value being represented is zero. The ·canonical representation· for zero is 0.0E0.
INF
', '+INF
',
'INF
', and 'NaN
'
(\+)?([09]+(\.[09]*)?\.[09]+)([Ee](\+)?[09]+)? (\+)?INFNaN
The double datatype is designed to implement for schema
processing the doubleprecision floatingpoint datatype of
[IEEE 7542008]. 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·, is a function,
satisfies the requirements of
[IEEE 7542008], and correctly handles the
mapping of the literals
'INF
', 'NaN
', etc., to the
·special values·,
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 interimplementation reproducibility and interimplementation roundtripping. The simple rounding algorithm used in ·doubleLexicalMap· may be more efficiently implemented using the algorithms of [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 7542008].
↓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·:
[Definition:] duration represents a duration of time. The ·value space· of duration is a sixdimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [ISO 8601], respectively. These components are ordered in their significance by their order of appearance i.e. as year, month, day, hour, minute, and second.
YYYY
) and a minimum fractional second precision of
milliseconds or three decimal digits (i.e. s.sss
).
However, ·minimally conforming· processors
·may· set an applicationdefined limit on the maximum number
of digits they are prepared to support in these two cases, in which
case that applicationdefined 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
values. 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·.
Under the definition just given, two duration values are equal if and only if they are identical.
The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision.
The values of the Year, Month, Day, Hour and Minutes components are not restricted but allow an arbitrary integer. Similarly, the value of the Seconds component allows an arbitrary decimal. Thus, the lexical representation of duration does not follow the alternative format of § 5.5.3.2.1 of [ISO 8601].
An optional preceding minus sign ('') is allowed, to indicate a negative duration. If the sign is omitted a positive duration is indicated. See also ISO 8601 Date and Time Formats (§G).
For example, to indicate a duration of 1 year, 2 months, 3 days, 10
hours, and 30 minutes, one would write: P1Y2M3DT10H30M
.
One could also indicate a duration of minus 120 days as:
P120D
.
Reduced precision and truncated representations of this format are allowed provided they conform to the following:
For example, P1347Y, P1347M and P1Y2MT2H are all allowed; P0Y1347M and P0Y1347M0D are allowed. P1347M is not allowed although P1347M is allowed. P1Y2MT is not allowed.
T
' ((duHourFrag duMinuteFrag? duSecondFrag?) 
(duMinuteFrag duSecondFrag?) 
duSecondFrag)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.
matches only strings in which the fields occur in the proper order.
?P([09]+Y)?([09]+M)?([09]+D)?(T([09]+H)?([09]+M)?([09]+(\.[09]+)?S)?)?
.*[YMDHS].*
' matches only
strings in which at least one field occurs..*[^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.?P(([09]+Y)([09]+M)?([09]+D)?(T(([09]+H)([09]+M)?([09]+(\.[09]+)?S)?([09]+M)?([09]+(\.[09]+)?S)?([09]+(\.[09]+)?S)))? ([09]+M)([09]+D)?(T(([09]+H)([09]+M)?([09]+(\.[09]+)?S)?([09]+M)?([09]+(\.[09]+)?S)?([09]+(\.[09]+)?S)))? ([09]+D)?(T(([09]+H)([09]+M)?([09]+(\.[09]+)?S)?([09]+M)?([09]+(\.[09]+)?S)?([09]+(\.[09]+)?S)))? T(([09]+H)([09]+M)?([09]+(\.[09]+)?S)? ([09]+M)?([09]+(\.[09]+)?S)? ([09]+(\.[09]+)?S)))
The ·lexical mapping· for duration is ·durationMap·.
·The canonical mapping· for duration is ·durationCanonicalMap·.
The following table shows the strongest relationship that can be determined between example durations. The symbol <> means that the order relation is indeterminate. Note that because of leapseconds, a seconds field can vary from 59 to 60. However, because of the way that addition is defined in Adding durations to dateTimes (§H), they are still totally ordered.
Relation  

P1Y  > P364D  <> P365D  <> P366D  < P367D  
P1M  > P27D  <> P28D  <> P29D  <> P30D  <> P31D  < P32D  
P5M  > P149D  <> P150D  <> P151D  <> P152D  <> P153D  < P154D 
Implementations are free to optimize the computation of the ordering relationship. For example, the following table can be used to compare durations of a small number of months against days.
Months  1  2  3  4  5  6  7  8  9  10  11  12  13  ...  

Days  Minimum  28  59  89  120  150  181  212  242  273  303  334  365  393  ... 
Maximum  31  62  92  123  153  184  215  245  276  306  337  366  397  ... 
In comparing duration values with minInclusive, minExclusive, maxInclusive and maxExclusive facet values, indeterminate comparisons should be considered as "false".
Certain derived datatypes of durations can be guaranteed have a total order. For this, they must have fields from only one row in the list below and the time zone must either be required or prohibited.
For example, a datatype could be defined to correspond to the [SQL] datatype YearMonth interval that required a four digit year field and a two digit month field but required all other fields to be unspecified. This datatype could be defined as below and would have a total order.
<simpleType name='SQLYearMonthInterval'> <restriction base='duration'> <pattern value='P\p{Nd}{4}Y\p{Nd}{2}M'/> </restriction> </simpleType>
↓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·:
The following ·builtin· datatypes are ·derived· from duration
[Definition:] dateTime values may be viewed as objects with integervalued year, month, day, hour and minute properties, a decimalvalued second property, and a boolean timezoned property. Each such object also has one decimalvalued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 00010101T00:00:00 and the value of timeOnTimeline for other dateTime values is computed using the Gregorian algorithm as modified for leapseconds. The timeOnTimeline values form two related "timelines", one for timezoned values and one for nontimezoned values. Each timeline is a copy of the ·value space· of decimal, with integers given units of seconds.
dateTime represents instants of time, optionally marked with a particular time zone offset. Values representing the same instant but having different time zone offsets are equal but not identical.
The ·value space· of dateTime is closely related to the dates and times described in ISO 8601. For clarity, the text above specifies a particular origin point for the timeline. It should be noted, however, that schema processors need not expose the timeOnTimeline value to schema users, and there is no requirement that a timelinebased implementation use the particular origin described here in its internal representation. Other interpretations of the ·value space· which lead to the same results (i.e., are isomorphic) are of course acceptable.
All timezoned times are Coordinated Universal Time (UTC, sometimes called "Greenwich Mean Time"). Other timezones indicated in lexical representations are converted to UTC during conversion of literals to values. "Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority; currently there are no legally prescribed timezones which are durations whose magnitude is greater than 14 hours. The value of each numericvalued property (other than timeOnTimeline) is limited to the maximum value within the interval determined by the nexthigher property. For example, the day value can never be 32, and cannot even be 29 for month 02 and year 2002 (February 2002).
''
is likely to change in
subsequent versions.dateTime uses the date/timeSevenPropertyModel, with no properties except ·timezoneOffset· permitted to be absent. The ·timezoneOffset· property remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1). dateTime values are ordered by their ·timeOnTimeline· value.
The ·lexical space· of dateTime consists of
finitelength sequences of characters of the form:
''? yyyy '' mm '' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?
,
where
For example, 20021010T12:00:0005:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is 20021010T17:00:00Z, five hours later than 20021010T12:00:00Z.
For further guidance on arithmetic with dateTimes and durations, see Adding durations to dateTimes (§H).
24
';0
';Z
' (All timezoned dateTime values are
UTC.).
' monthFrag '
' dayFrag 'T
' ((hourFrag ':
' minuteFrag ':
' secondFrag) 
endOfDayFrag) timezoneFrag? Constraint: Dayofmonth Representations3
' or be '29
'
unless the value to
which it would map would satisfy the value constraint on
·day· values
("Constraint: Dayofmonth Values") given above.
', 'T
', and
':
', separate the various numerals.Z
' is an alternative representation of the time zone offset
'00:00
',
which is, of course, zero minutes from UTC.?([19][09]{3,}0[09]{3}) (0[19]1[02]) (0[19][12][09]3[01]) T(([01][09]2[03]):[05][09]:[05][09](\.[09]+)?(24:00:00(\.0+)?)) (Z(\+)((0[09]1[03]):[05][09]14:00))?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·.
Timezones are durations with (integervalued) hour and minute properties (with the hour magnitude limited to at most 14, and the minute magnitude limited to at most 59, except that if the hour magnitude is 14, the minute value must be 0); they may be both positive or both negative.
The lexical representation of a timezone is a string of the form:
(('+'  '') hh ':' mm)  'Z'
,
where
The mapping so defined is onetoone, except that '+00:00', '00:00', and 'Z' all represent the same zerolength duration timezone, UTC; 'Z' is its ·canonical representation·.
When a timezone is added to a UTC dateTime, the result is the date and time "in that timezone". For example, 20021010T12:00:00+05:00 is 20021010T07:00:00Z and 20021010T00:00:00+05:00 is 20021009T19:00:00Z.
dateTime value objects on either timeline are totally ordered by their timeOnTimeline values; between the two timelines, dateTime value objects are ordered by their timeOnTimeline values when their timeOnTimeline values differ by more than fourteen hours, with those whose difference is a duration of 14 hours or less being incomparable.
In general, the ·orderrelation· on dateTime is a partial order since there is no determinate relationship between certain instants. For example, there is no determinate ordering between (a) 20000120T12:00:00 and (b) 20000120T12:00:00Z. Based on timezones currently in use, (c) could vary from 20000120T12:00:00+12:00 to 20000120T12:00:0013:00. It is, however, possible for this range to expand or contract in the future, based on local laws. Because of this, the following definition uses a somewhat broader range of indeterminate values: +14:00..14:00.
The following definition uses the notation S[year] to represent the year field of S, S[month] to represent the month field, and so on. The notation (Q & "14:00") means adding the timezone 14:00 to Q, where Q did not already have a timezone. This is a logical explanation of the process. Actual implementations are free to optimize as long as they produce the same results.
The ordering between two dateTimes P and Q is defined by the following algorithm:
A.Normalize P and Q. That is, if there is a timezone present, but it is not Z, convert it to Z using the addition operation defined in Adding durations to dateTimes (§H)
B. If P and Q either both have a time zone or both do not have a time zone, compare P and Q field by field from the year field down to the second field, and return a result as soon as it can be determined. That is:
C.Otherwise, if P contains a time zone and Q does not, compare as follows:
D. Otherwise, if P does not contain a time zone and Q does, compare as follows:
Examples:
Determinate  Indeterminate 

20000115T00:00:00 < 20000215T00:00:00  20000101T12:00:00 <> 19991231T23:00:00Z 
20000115T12:00:00 < 20000116T12:00:00Z  20000116T12:00:00 <> 20000116T12:00:00Z 
20000116T00:00:00 <> 20000116T12:00:00Z 
Certain derived types from dateTime can be guaranteed have a total order. To do so, they must require that a specific set of fields are always specified, and that remaining fields (if any) are always unspecified. For example, the date datatype without time zone is defined to contain exactly year, month, and day. Thus dates without time zone have a total order among themselves.
↓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:↑
↑dateTime has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] time represents an instant of time that recurs every day. The ·value space· of time is the space of time of day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zeroduration daily time instances.
time represents instants of time that recur at the same point in each calendar day, or that occur in some arbitrary calendar day.
Since the lexical representation allows an optional time zone indicator, time values are partially ordered because it may not be able to determine the order of two values one of which has a time zone and the other does not. The order relation on time values is the Order relation on dateTime (§3.3.8.6) using an arbitrary date. See also Adding durations to dateTimes (§H). Pairs of time values with or without time zone indicators are totally ordered.
time uses the date/timeSevenPropertyModel, with ·year·, ·month·, and ·day· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1). time values (points in time in an "arbitrary" day) are ordered taking into account their ·timezoneOffset·.
A calendar (or "local time") day with a larger positive time zone offset begins earlier than the same calendar day with a smaller (or negative) time zone offset. Since the time zone offsets allowed spread over 28 hours, it is possible for the period denoted by a given calendar day with one time zone offset to be completely disjoint from the period denoted by the same calendar day with a different offset — the earlier day ends before the later one starts. The moments in time represented by a single calendar day are spread over a 52hour interval, from the beginning of the day in the +14:00 time zone offset to the end of that day in the −14:00 time zone offset.
05:00:0003:00
' and '10:00:00+02:00
',
now denote equal though distinct values
(because they identify the same points on the time line);
others,
such as '23:00:0003:00
' and '02:00:00Z
',
now denote unequal values (23:00:00−03:00 > 02:00:00Z
because 23:00:00−03:00 on any given day is equal to
02:00:00Z on the next day).
The lexical representation for time is the left truncated lexical representation for dateTime: hh:mm:ss.sss with optional following time zone indicator. For example, to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind Coordinated Universal Time (UTC), one would write: 13:20:0005:00. See also ISO 8601 Date and Time Formats (§G).
The ·canonical representation· for time is defined by prohibiting certain options from the Lexical representation (§3.3.9.2). Specifically, either the time zone must be omitted or, if present, the time zone must be Coordinated Universal Time (UTC) indicated by a "Z". Additionally, the ·canonical representation· for midnight is 00:00:00.
Note that neither the timeLexicalRep production nor this regular expression alone enforce the constraint on timeLexicalRep given above.
(([01][09]2[03]):[05][09]:[05][09](\.[09]+)?(24:00:00(\.0+)?))(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for time is ·timeLexicalMap·; the ·canonical mapping· is ·timeCanonicalMap·.
00:00:00
' and
'24:00:00
' to the same value, namely midnight
(·hour· = 0 ,
·minute· = 0 ,
·second· = 0).↓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:↑
↑time has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] ↓The ·value space· of date consists of topopen intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day (in each timezone), i.e. '00:00:00', up to but not including '24:00:00' (which is identical with '00:00:00'↓↑date represents topopen intervals of exactly one day in length on the timelines of dateTime, beginning on the beginning moment of each day, up to but not including the beginning moment↑ of the next day). For non↑↑timezoned values, the topopen intervals disjointly cover the non↑↑timezoned timeline, one per day. For timezoned values, the intervals begin at every minute and therefore overlap.
A "date object" is an object with year, month, and day properties just like those of dateTime objects, plus an optional timezonevalued timezone property. (As with values of dateTime timezones are a special case of durations.) Just as a dateTime object corresponds to a point on one of the timelines, a date object corresponds to an interval on one of the two timelines as just described.
timezoned date values track the starting moment of their day, as determined by their timezone; said timezone is generally recoverable for ·canonical representations·. [Definition:] The recoverable timezone is that duration which is the result of subtracting the first moment (or any moment) of the timezoned date from the first moment (or the corresponding moment) UTC on the same date. ·recoverable timezone·s are always durations between '+12:00' and '11:59'. This "timezone normalization" (which follows automatically from the definition of the date ·value space·) is explained more in Lexical representation (§3.3.10.2).
For example: the first moment of 20021010+13:00 is 20021010T00:00:00+13, which is 20021009T11:00:00Z, which is also the first moment of 2002100911:00. Therefore 20021010+13:00 is 2002100911:00; they are the same interval.
date uses the date/timeSevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).
For the following discussion, let the "date portion" of a dateTime or date object be an object similar to a dateTime or date object, with similar year, month, and day properties, but no others, having the same value for these properties as the original dateTime or date object.
The ·lexical space· of
date consists of finitelength
sequences of characters of the form:
''? yyyy '' mm '' dd zzzzzz?
where the date and optional timezone are represented exactly the
same way as they are for dateTime. The first moment of the
interval is that represented by:
'' yyyy '' mm '' dd 'T00:00:00' zzzzzz?
and the least upper bound of the interval is the timeline point represented
(noncanonically) by:
'' yyyy '' mm '' dd 'T24:00:00' zzzzzz?
.
Given a member of the date ·value space·, the date portion of the ·canonical representation· (the entire representation for nontimezoned values, and all but the timezone representation for timezoned values) is always the date portion of the dateTime ·canonical representation· of the interval midpoint (the dateTime representation, truncated on the right to eliminate 'T' and all following characters). For timezoned values, append the canonical representation of the ·recoverable timezone·.

' monthFrag '
' dayFrag timezoneFrag? Constraint: Dayofmonth Representations3
' or be '29
'
unless the value to
which it would map would satisfy the value constraint on
·day· values
("Constraint: Dayofmonth Values") given above.Note that neither the dateLexicalRep production nor this regular expression alone enforce the constraint on dateLexicalRep given above.
?([19][09]{3,}0[09]{3})(0[19]1[02])(0[19][12][09]3[01])(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for date is ·dateLexicalMap·. The ·canonical mapping· is ·dateCanonicalMap·.
↓date has the following ·constraining facets·:↓
↑date 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:↑
↑date has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from date↑ may also specify values for the following↑ ·constraining facets·:↑
date has the following values for its ·fundamental facets·:
[Definition:] gYearMonth represents a specific gregorian month in a specific gregorian year. The ·value space· of gYearMonth is the set of Gregorian calendar months as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of onemonth long, nonperiodic instances e.g. 199910 to represent the whole month of 199910, independent of how many days this month has.
gYearMonth represents specific whole Gregorian months in specific Gregorian years.
Since the lexical representation allows an optional time zone indicator, gYearMonth values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gYearMonth values are considered as periods of time, the order relation on gYearMonth values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.3.8.6). See also Adding durations to dateTimes (§H). Pairs of gYearMonth values with or without time zone indicators are totally ordered.
gYearMonth uses the date/timeSevenPropertyModel, with ·day·, ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).
The lexical representation for gYearMonth is the reduced (right truncated) lexical representation for dateTime: CCYYMM. No left truncation is allowed. An optional following time zone qualifier is allowed. To accommodate year values outside the range from 0001 to 9999, additional digits can be added to the left of this representation and a preceding "" sign is allowed.
For example, to indicate the month of May 1999, one would write: 199905. See also ISO 8601 Date and Time Formats (§G).
?([19][09]{3,}0[09]{3})(0[19]1[02])(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for gYearMonth is ·gYearMonthLexicalMap·. The ·canonical mapping· is ·gYearMonthCanonicalMap·.
↓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:↑
↑gYearMonth has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] gYear represents a gregorian calendar year. The ·value space· of gYear is the set of Gregorian calendar years as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of oneyear long, nonperiodic instances e.g. lexical 1999 to represent the whole year 1999, independent of how many months and days this year has.
gYear represents Gregorian calendar years.
Since the lexical representation allows an optional time zone indicator, gYear values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gYear values are considered as periods of time, the order relation on gYear values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.3.8.6). See also Adding durations to dateTimes (§H). Pairs of gYear values with or without time zone indicators are totally ordered.
gYear uses the date/timeSevenPropertyModel, with ·month·, ·day·, ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).
The lexical representation for gYear is the reduced (right truncated) lexical representation for dateTime: CCYY. No left truncation is allowed. An optional following time zone qualifier is allowed as for dateTime. To accommodate year values outside the range from 0001 to 9999, additional digits can be added to the left of this representation and a preceding "" sign is allowed.
For example, to indicate 1999, one would write: 1999. See also ISO 8601 Date and Time Formats (§G).
?([19][09]{3,}0[09]{3})(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for gYear is ·gYearLexicalMap·. The ·canonical mapping· is ·gYearCanonicalMap·.
↓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:↑
↑gYear has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] gMonthDay is a gregorian date that recurs, specifically a day of the year such as the third of May. Arbitrary recurring dates are not supported by this datatype. The ·value space· of gMonthDay is the set of calendar dates, as defined in § 3 of [ISO 8601]. Specifically, it is a set of oneday long, annually periodic instances.
gMonthDay represents whole calendar days that recur at the same point in each calendar year, or that occur in some arbitrary calendar year. (Obviously, days beyond 28 cannot occur in all Februaries; 29 is nonetheless permitted.)
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.
Since the lexical representation allows an optional time zone indicator, gMonthDay values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gMonthDay values are considered as periods of time, in an arbitrary leap year, the order relation on gMonthDay values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.3.8.6). See also Adding durations to dateTimes (§H). Pairs of gMonthDay values with or without time zone indicators are totally ordered.
gMonthDay uses the date/timeSevenPropertyModel, with ·year·, ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).
The lexical representation for gMonthDay is the left truncated lexical representation for date: MMDD. An optional following time zone qualifier is allowed as for date. No preceding sign is allowed. No other formats are allowed. See also ISO 8601 Date and Time Formats (§G).

' monthFrag '
' dayFrag timezoneFrag? Constraint: Dayofmonth Representations3
' or be '29
'
unless the value to
which it would map would satisfy the value constraint on
·day· values
("Constraint: Dayofmonth Values") given above.Note that neither the gMonthDayLexicalRep production nor this regular expression alone enforce the constraint on gMonthDayLexicalRep given above.
(0[19]1[02])(0[19][12][09]3[01])(Z(\+)((0[09]1[03]):[05][09]14:00))?
This datatype can be used to represent a specific day in a month. To say, for example, that my birthday occurs on the 14th of September ever year.
The ·lexical mapping· for gMonthDay is ·gMonthDayLexicalMap·. The ·canonical mapping· is ·gMonthDayCanonicalMap·.
↓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:↑
↑gMonthDay has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] gDay is a gregorian day that recurs, specifically a day of the month such as the 5th of the month. Arbitrary recurring days are not supported by this datatype. The ·value space· of gDay is the space of a set of calendar dates as defined in § 3 of [ISO 8601]. Specifically, it is a set of oneday long, monthly periodic instances.
↑[Definition:] gDay represents whole days within an arbitrary month—days that recur at the same point in each (Gregorian) month.↑ This datatype ↓can be↓↑is↑ used to represent a specific day of the month. To ↓say, for example, that I get my paycheck↓↑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.)↑
Since the lexical representation allows an optional time zone indicator, gDay values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gDay values are considered as periods of time, in an arbitrary month that has 31 days, the order relation on gDay values is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.3.8.6). See also Adding durations to dateTimes (§H). Pairs of gDay values with or without time zone indicators are totally ordered.
gDay uses the date/timeSevenPropertyModel, with ·year·, ·month·, ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional· and ·day· must be between 1 and 31 inclusive.
Equality and order are as prescribed in The Sevenproperty 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 ·timezoneOffset· values differ by at least 24 hours. (It is possible for ·timezoneOffset· values to differ by up to 28 hours.)
The lexical representation for gDay is the left truncated lexical representation for date: DD . An optional following time zone qualifier is allowed as for date. No preceding sign is allowed. No other formats are allowed. See also ISO 8601 Date and Time Formats (§G).
(0[19][12][09]3[01])(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for gDay is ·gDayLexicalMap·. The ·canonical mapping· is ·gDayCanonicalMap·.
↓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:↑
↑gDay has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] gMonth is a gregorian month that recurs every year. The ·value space· of gMonth is the space of a set of calendar months as defined in § 3 of [ISO 8601]. Specifically, it is a set of onemonth long, yearly periodic instances.
↓This datatype can be used to represent a specific month. To say, for example, that Thanksgiving falls in the month of November.↓↑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).↑
Since the lexical representation allows an optional time zone indicator, gMonth values are partially ordered because it may not be possible to unequivocally determine the order of two values one of which has a time zone and the other does not. If gMonth values are considered as periods of time, the order relation on gMonth is the order relation on their starting instants. This is discussed in Order relation on dateTime (§3.3.8.6). See also Adding durations to dateTimes (§H). Pairs of gMonth values with or without time zone indicators are totally ordered.
gMonth uses the date/timeSevenPropertyModel, with ·year·, ·day·, ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).
The lexical representation for gMonth is the left and right truncated lexical representation for date: MM. An optional following time zone qualifier is allowed as for date. No preceding sign is allowed. No other formats are allowed. See also ISO 8601 Date and Time Formats (§G).
(0[19]1[02])(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping· for gMonth is ·gMonthLexicalMap·. The ·canonical mapping· is ·gMonthCanonicalMap·.
↓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:↑
↑gMonth has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one 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·:
[Definition:] hexBinary represents arbitrary hexencoded binary data.
The ·value space· of ↓hexBinary↓↑hexBinary↑ is the set of ↓↓ finitelength sequences of ↑zero or more↑ binary octets.↑ The length of a value is the number of octets.↑
hexBinary has a
lexical representation where
each binary octet is encoded as a character tuple, consisting of two
hexadecimal digits ([09afAF]) representing the octet code. For example,
'0FB7
' is a hex encoding for the 16bit integer 4023
(whose binary representation is 111110110111).
hexBinary's ·lexical space·
consists of strings of hex (hexadecimal) digits, two consecutive digits
representing each octet in the corresponding value (treating the octet
as the binary representation of a number between 0 and 255). For
example, '0FB7
' is a ·lexical representation· of the
twooctet value 00001111 10110111.
The set recognized by hexBinary is the same as that recognized by the regular
expression '([09afAF]{2})*
'.
The ·lexical mapping· of hexBinary is ·hexBinaryMap·.
The ·canonical representation· for hexBinary is defined by prohibiting certain options from the Lexical ↓Representation↓↑Mapping↑ (§3.3.16.2). Specifically, the lower case hexadecimal digits ([af]) are not allowed.
The ·canonical mapping· of hexBinary is given formally in ·hexBinaryCanonical·.
The ·canonical representation· for hexBinary is defined by prohibiting certain options from the Lexical ↓Representation↓↑Mapping↑ (§3.3.16.2). Specifically, the lower case hexadecimal digits ([af]) are not allowed.
↓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·:
[Definition:] base64Binary represents ↑arbitrary↑ Base64encoded ↓arbitrary↓ binary data. ↓The ·value space· of base64Binary is the set of finitelength sequences of binary octets.↓ For base64Binary data the entire binary stream is encoded using the Base64 ↓Alphabet in [RFC 2045]↓↑Encoding defined in [RFC 3548], which is derived from the encoding described in [RFC 2045]↑.
The ·value space· of base64Binary is the set of ↓↓ finitelength sequences of ↑zero or more↑ binary octets.↑ The length of a value is the number of octets.↑
The ↓lexical forms↓↑·lexical representations·↑ of
↓base64Binary↓↑base64Binary↑
values are limited to the 65 characters of the Base64 Alphabet defined in
↓[RFC 2045]↓↑[RFC 3548]↑,
i.e., az
, AZ
,
09
, the plus sign (+), the forward slash (/) and the
equal sign (=), together with
↓the characters defined in [XML 1.0] as
white space↓↑the space character
(#x20)↑. No other characters are allowed.
For compatibility with older mail gateways, [RFC 2045] suggests that ↓b↓↑B↑ase64 data should have lines limited to at most 76 characters in length. This linelength limitation is not ↑required by [RFC 3548] and is not↑ mandated in the ↓lexical forms↓↑·lexical representations·↑ of ↓base64Binary↓↑base64Binary↑ data↓ and ↓↑. It↑ ↓must not↓↑must not↑ be enforced by XML Schema processors.
The ·lexical space· of ↓base64Binary↓↑base64Binary↑ is ↓given by the following grammar (the notation is that used in [XML 1.0]); legal lexical forms must match↓↑the set of literals which ·match·↑ the ↓base64Binary↓↑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 ::= [AZaz09+/]
Note that each '
((([AZaz09+/] ?){4})*(([AZaz09+/] ?){3}[AZaz09+/]([AZaz09+/] ?){2}[AEIMQUYcgkosw048] ?=[AZaz09+/] ?[AQgw] ?= ?=))?
?
' except the last is preceded by a
single space character.Note that this grammar requires the number of nonwhitespace 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·↑; ↓strings↓↑literals↑ which do not meet these constraints are not legal ↓lexical forms↓↑·lexical representations·↑ of ↓base64Binary↓↑base64Binary↑↓ because they cannot successfully be decoded by base64 decoders↓.
The ·lexical mapping· for base64Binary is as given in [RFC 2045] and [RFC 3548].
The canonical ↓lexical form↓↑·lexical representation·↑ of a ↓base64Binary↓↑base64Binary↑ data value is the ↓b↓↑B↑ase64 encoding of the value which matches the Canonicalbase64Binary production in the following grammar:
Canonicalbase64Binary ::= (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.
The length of a ↓base64Binary↓↑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 pseudocode 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↓s↓ USutf8 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 1.0]↓↑[XML]↑.
↓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·:
[Definition:] anyURI represents ↓a Uniform Resource Identifier Reference (URI)↓↑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 ↓a URI↓↑an IRI↑ Reference). This type should be used ↓to specify the intention that↓↑when↑ the value fulfills the role of ↓a URI as defined by [RFC 2396], as amended by [RFC 2732]↓↑an IRI, as defined in [RFC 3987] or its successor(s) in the IETF Standards Track↑.
The ·lexical space· of ↓anyURI↓↑anyURI↑ is ↓ finitelength character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732]↓↑the set of finitelength sequences of zero or more characters (as defined in [XML]) that ·match· the Char production from [XML]↑.
%20
').The ·lexical mapping· for anyURI is the identity mapping.
↓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·:
[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 1.0]↓↑[Namespaces in XML]↑.
It is ·implementationdefined· 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).
When QNames appear in an XML context, the bindings to be used in the ·lexical mapping· are those in the [inscope namespaces] property of the relevant element. When this datatype is used in a nonXML host language, the host language must specify what namespace bindings are to be used.
The host language, whether XMLbased or otherwise, may specify whether unqualified names are bound to the default namespace (if any) or not; the host language may also place this under user control. If the host language does not specify otherwise, unqualified names are bound to the default namespace.
↓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·:
The use of ·length·, ·minLength· and ·maxLength· on datatypes ·derived· from QName is deprecated. Future versions of this specification may remove these facets for this datatype.
[Definition:] NOTATION represents the NOTATION attribute type from ↓[XML 1.0]↓↑[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).
The lexical mapping rules for NOTATION are as given for QName in QName (§3.3.19).
For compatibility (see Terminology (§1.6)) ↓NOTATION↓↑NOTATION↑ should be used only on attributes and should only be used in schemas with no target namespace.
↓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·:
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.
This section gives conceptual definitions for all ·builtin· ↓·derived·↓↑·ordinary·↑ datatypes defined by this specification. The XML representation used to define ↓·derived·↓ ↑·ordinary·↑ datatypes (whether ·builtin· or ↓·userderived·↓↑·userdefined·↑) is given in ↓section ↓XML Representation of Simple Type Definition Schema Components (§4.1.2) and the complete definitions of the ·builtin· ↓·derived·↓↑·ordinary·↑ datatypes are provided in ↓Appendix A↓↑the appendix↑ Schema for ↑Schema Documents (Datatypes)↑ ↓Datatype Definitions↓ (normative) (§A).
[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.
↓normalizedString has the following ·constraining facets·:↓
↑normalizedString has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from normalizedString↑ may also specify values for the following↑ ·constraining facets·:↑
normalizedString has the following values for its ·fundamental facets·:
[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.
↓token has the following ·constraining facets·:↓
↑token has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from token↑ may also specify values for the following↑ ·constraining facets·:↑
token has the following values for its ·fundamental facets·:
↑This is the set of strings accepted by the grammar given in [RFC 3066]↑↑, which is now obsolete; the current specification of language codes is more restrictive↑. The ·base type· of ↓language↓↑language↑ is token.
[azAZ]{1,8}([azAZ09]{1,8})*
MN
' and
'mn
' (for
Mongolian)
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
caseinsensitive treatment of language values prescribed by
[BCP 47]
does not follow from the definition of
this datatype given here; applications which require
caseinsensitivity
should make appropriate adjustments.xml:lang
defined by
[XML] is one example; there, the empty string
overrides a value which would otherwise be inherited, but
without specifying a new value.xml:lang
as having a type which is a union
of language and an anonymous type whose
only value is the empty string:<xs:attribute name="lang"> <xs:annotation> <xs:documentation> See RFC 3066 at http://www.ietf.org/rfc/rfc3066.txt and the IANA registry at http://www.iana.org/assignments/langtagapps.htm for further information. The union allows for the 'undeclaration' of xml:lang with the empty string. </xs:documentation> </xs:annotation> <xs:simpleType> <xs:union memberTypes="xs:language"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value=""/> </xs:restriction> </xs:simpleType> </xs:union> </xs:simpleType> </xs:attribute>
↓language has the following ·constraining facets·:↓
↑language has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from language↑ may also specify values for the following↑ ·constraining facets·:↑
language has the following values for its ·fundamental facets·:
[Definition:] NMTOKEN represents the NMTOKEN attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of NMTOKEN is the set of tokens that ·match· the Nmtoken production in ↓[XML 1.0]↓↑[XML]↑. The ·lexical space· of NMTOKEN is the set of strings that ·match· the Nmtoken production in ↓[XML 1.0]↓↑[XML]↑. The ·base type· of NMTOKEN is token.
It is ·implementationdefined· 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↓↑NMTOKEN↑ should be used only on attributes.
↓NMTOKEN has the following ·constraining facets·:↓
↑NMTOKEN has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from NMTOKEN↑ may also specify values for the following↑ ·constraining facets·:↑
NMTOKEN has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·constructed· from NMTOKEN
[Definition:] NMTOKENS represents the NMTOKENS attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of NMTOKENS is the set of finite, nonzerolength sequences of ·NMTOKEN·s. The ·lexical space· of NMTOKENS is the set of spaceseparated lists of tokens, of which each token is in the ·lexical space· of NMTOKEN. The ·item type· of NMTOKENS is NMTOKEN.
For compatibility (see Terminology (§1.6)) ↓NMTOKENS↓↑NMTOKENS↑ should be used only on attributes.
↓NMTOKENS has the following ·constraining facets·:↓
↑NMTOKENS has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from NMTOKENS↑ may also specify values for the following↑ ·constraining facets·:↑
NMTOKENS has the following values for its ·fundamental facets·:
[Definition:] Name represents XML Names. The ·value space· of Name is the set of all strings which ·match· the Name production of ↓[XML 1.0]↓↑[XML]↑. The ·lexical space· of Name is the set of all strings which ·match· the Name production of ↓[XML 1.0]↓↑[XML]↑. The ·base type· of Name is token.
It is ·implementationdefined· 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).
↓Name has the following ·constraining facets·:↓
↑Name has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from Name↑ may also specify values for the following↑ ·constraining facets·:↑
Name has the following values for its ·fundamental facets·:
[Definition:] NCName represents XML "noncolonized" Names. The ·value space· of NCName is the set of all strings which ·match· the NCName production of ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·lexical space· of NCName is the set of all strings which ·match· the NCName production of ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·base type· of NCName is Name.
It is ·implementationdefined· 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).
↓NCName has the following ·constraining facets·:↓
↑NCName has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from NCName↑ may also specify values for the following↑ ·constraining facets·:↑
NCName has the following values for its ·fundamental facets·:
[Definition:] ID represents the ID attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of ID is the set of all strings that ·match· the NCName production in ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·lexical space· of ID is the set of all strings that ·match· the NCName production in ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·base type· of ID is NCName.
For compatibility (see Terminology (§1.6)), ↓ID↓↑ID↑ should be used only on attributes.
↓ID has the following ·constraining facets·:↓
↑ID has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from ID↑ may also specify values for the following↑ ·constraining facets·:↑
ID has the following values for its ·fundamental facets·:
[Definition:] IDREF represents the IDREF attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of IDREF is the set of all strings that ·match· the NCName production in ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·lexical space· of IDREF is the set of strings that ·match· the NCName production in ↓[Namespaces in XML 1.0]↓↑[Namespaces in XML]↑. The ·base type· of IDREF is NCName.
For compatibility (see Terminology (§1.6)) this datatype should be used only on attributes.
↓IDREF has the following ·constraining facets·:↓
↑IDREF has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from IDREF↑ may also specify values for the following↑ ·constraining facets·:↑
IDREF has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·constructed· from IDREF
[Definition:] IDREFS represents the IDREFS attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of IDREFS is the set of finite, nonzerolength sequences of IDREFs. The ·lexical space· of IDREFS is the set of spaceseparated lists of tokens, of which each token is in the ·lexical space· of IDREF. The ·item type· of IDREFS is ↓IDREFS↓↑IDREF↑.
For compatibility (see Terminology (§1.6)) ↓IDREFS↓↑IDREFS↑ should be used only on attributes.
↓IDREFS has the following ·constraining facets·:↓
↑IDREFS has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from IDREFS↑ may also specify values for the following↑ ·constraining facets·:↑
IDREFS has the following values for its ·fundamental facets·:
[Definition:] ENTITY represents the ENTITY attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of ENTITY is the set of all strings that ·match· the NCName production in ↓[Namespaces in XML 1.0]↓↑[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 1.0]↓↑[Namespaces in XML]↑. The ·base type· of ENTITY is NCName.
For compatibility (see Terminology (§1.6)) ↓ENTITY↓↑ENTITY↑ should be used only on attributes.
↓ENTITY has the following ·constraining facets·:↓
↑ENTITY has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from ENTITY↑ may also specify values for the following↑ ·constraining facets·:↑
ENTITY has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·constructed· from ENTITY
[Definition:] ENTITIES represents the ENTITIES attribute type from ↓[XML 1.0]↓↑[XML]↑. The ·value space· of ENTITIES is the set of finite, nonzerolength sequences of ·ENTITY·↑ values↑s that have been declared as unparsed entities in a document type definition. The ·lexical space· of ENTITIES is the set of spaceseparated lists of tokens, of which each token is in the ·lexical space· of ENTITY. The ·item type· of ENTITIES is ↓↓↑ENTITY↑.
For compatibility (see Terminology (§1.6)) ↓ENTITIES↓↑ENTITIES↑ should be used only on attributes.
↓ENTITIES has the following ·constraining facets·:↓
↑ENTITIES has the following ·constraining facets·↑↑ with the values shown; these facets may be specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from ENTITIES↑ may also specify values for the following↑ ·constraining facets·:↑
ENTITIES has the following values for its ·fundamental facets·:
[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.
↓integer↓↑integer↑ has a lexical representation consisting of a finitelength sequence of ↑one or more↑ decimal digits (#x30#x39) with an optional leading sign. If the sign is omitted, "+" is assumed. For example: 1, 0, 12678967543233, +100000.
The ·canonical representation· for ↓integer↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from integer↑ may also specify values for the following↑ ·constraining facets·:↑
integer has the following values for its ·fundamental facets·:
The following ·builtin· datatypes are ·derived· from integer
[Definition:] nonPositiveInteger is ·derived· from integer by setting the value of ·maxInclusive· to be 0. This results in the standard mathematical concept of the nonpositive integers. The ·value space· of nonPositiveInteger is the infinite set {...,2,1,0}. The ·base type· of nonPositiveInteger is integer.
↓nonPositiveInteger↓↑nonPositiveInteger↑
has a lexical representation consisting of
an optional preceding sign
followed by a ↑nonempty↑
finitelength sequence of decimal digits (#x30#x39).
The sign may be "+" or may be omitted only for
lexical forms denoting zero; in all other lexical forms, the negative
sign ('
') must be present.
For example: 1, 0, 12678967543233, 100000.
The ·canonical representation· for ↓nonPositiveInteger↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from nonPositiveInteger↑ may also specify values for the following↑ ·constraining facets·:↑
nonPositiveInteger has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from nonPositiveInteger
[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.
↓negativeInteger↓↑negativeInteger↑
has a lexical representation consisting
of a negative sign ('
') followed by a ↑nonempty↑ finitelength sequence of
decimal digits (#x30#x39)↑,
at least one of which must be a digit other than '0
'↑.
For example: 1, 12678967543233,
100000.
The ·canonical representation· for ↓negativeInteger↓↑negativeInteger↑ is defined by prohibiting certain options from the Lexical representation (§3.4.15.1). Specifically, leading zeroes are prohibited.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from negativeInteger↑ may also specify values for the following↑ ·constraining facets·:↑
negativeInteger has the following values for its ·fundamental facets·:
[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.
↓long↓↑long↑ has a lexical representation consisting of an optional sign followed by a ↑nonempty↑ finitelength sequence of decimal digits (#x30#x39). If the sign is omitted, "+" is assumed. For example: 1, 0, 12678967543233, +100000.
The ·canonical representation· for ↓long↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from long↑ may also specify values for the following↑ ·constraining facets·:↑
long has the following values for its ·fundamental facets·:
[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.
↓int↓↑int↑ has a lexical representation consisting of an optional sign followed by a ↑nonempty↑ finitelength sequence of decimal digits (#x30#x39). If the sign is omitted, "+" is assumed. For example: 1, 0, 126789675, +100000.
The ·canonical representation· for ↓int↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from int↑ may also specify values for the following↑ ·constraining facets·:↑
int has the following values for its ·fundamental facets·:
[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.
↓short↓↑short↑ has a lexical representation consisting of an optional sign followed by a ↑nonempty↑ finitelength sequence of decimal digits (#x30#x39). If the sign is omitted, "+" is assumed. For example: 1, 0, 12678, +10000.
The ·canonical representation· for ↓short↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from short↑ may also specify values for the following↑ ·constraining facets·:↑
short has the following values for its ·fundamental facets·:
[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.
↓byte↓↑byte↑ has a lexical representation consisting of an optional sign followed by a ↑nonempty↑ finitelength sequence of decimal digits (#x30#x39). If the sign is omitted, "+" is assumed. For example: 1, 0, 126, +100.
The ·canonical representation· for ↓byte↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from byte↑ may also specify values for the following↑ ·constraining facets·:↑
byte has the following values for its ·fundamental facets·:
[Definition:] nonNegativeInteger is ·derived· from integer by setting the value of ·minInclusive· to be 0. This results in the standard mathematical concept of the nonnegative integers. The ·value space· of nonNegativeInteger is the infinite set {0,1,2,...}. The ·base type· of nonNegativeInteger is integer.
↓nonNegativeInteger↓↑nonNegativeInteger↑
has a lexical representation consisting of
an optional sign followed by a ↑nonempty↑ finitelength
sequence of decimal digits (#x30#x39). If the sign is omitted,
the positive sign ('+
') is assumed.
If the sign is present, it must be "+" except for lexical forms
denoting zero, which may be preceded by a positive ('+
') or a negative ('
') sign.
For example:
1, 0, 12678967543233, +100000.
The ·canonical representation· for ↓nonNegativeInteger↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from nonNegativeInteger↑ may also specify values for the following↑ ·constraining facets·:↑
nonNegativeInteger has the following values for its ·fundamental facets·:
The following ·builtin· datatypes are ·derived· from nonNegativeInteger
[Definition:] unsignedLong is ·derived· from nonNegativeInteger by setting the value of ·maxInclusive· to be 18446744073709551615. The ·base type· of unsignedLong is nonNegativeInteger.
↓unsignedLong↓↑unsignedLong↑
has a lexical representation consisting of
↑an optional sign followed by↑ a
↑nonempty↑
finitelength sequence of decimal digits (#x30#x39).
↑If the sign is omitted, the positive sign
('+
') is assumed. If the sign is present, it must be
'+
' except for lexical forms denoting zero, which may
be preceded by a positive ('+
') or a negative
('
') sign.↑ For example: 0, 12678967543233,
100000.
The ·canonical representation· for ↓unsignedLong↓↑unsignedLong↑ is defined by prohibiting certain options from the Lexical representation (§3.4.21.1). Specifically, leading zeroes are prohibited.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from unsignedLong↑ may also specify values for the following↑ ·constraining facets·:↑
unsignedLong has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from unsignedLong
[Definition:] unsignedInt is ·derived· from unsignedLong by setting the value of ·maxInclusive· to be 4294967295. The ·base type· of unsignedInt is unsignedLong.
↓unsignedInt↓↑unsignedInt↑
has a lexical representation consisting
of ↑an optional sign followed by↑ a
↑nonempty↑
finitelength sequence of decimal digits (#x30#x39).
↑If the sign is omitted, the positive sign
('+
') is assumed. If the sign is present, it must be
'+
' except for lexical forms denoting zero, which may
be preceded by a positive ('+
') or a negative
('
') sign.↑ For example: 0,
1267896754, 100000.
The ·canonical representation· for ↓unsignedInt↓↑unsignedInt↑ is defined by prohibiting certain options from the Lexical representation (§3.4.22.1). Specifically, leading zeroes are prohibited.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from unsignedInt↑ may also specify values for the following↑ ·constraining facets·:↑
unsignedInt has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from unsignedInt
[Definition:] unsignedShort is ·derived· from unsignedInt by setting the value of ·maxInclusive· to be 65535. The ·base type· of unsignedShort is unsignedInt.
↓unsignedShort↓↑unsignedShort↑
has a lexical representation consisting of
↑an optional sign followed by↑ a
↑nonempty↑ finitelength
sequence of decimal digits (#x30#x39). ↑If the sign is omitted, the positive sign
('+
') is assumed. If the sign is present, it must be
'+
' except for lexical forms denoting zero, which may
be preceded by a positive ('+
') or a negative
('
') sign.↑ For example: 0, 12678, 10000.
The ·canonical representation· for ↓unsignedShort↓↑unsignedShort↑ is defined by prohibiting certain options from the Lexical representation (§3.4.23.1). Specifically, the leading zeroes are prohibited.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from unsignedShort↑ may also specify values for the following↑ ·constraining facets·:↑
unsignedShort has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from unsignedShort
[Definition:] unsignedByte is ·derived· from unsignedShort by setting the value of ·maxInclusive· to be 255. The ·base type· of unsignedByte is unsignedShort.
↓unsignedByte↓↑unsignedByte↑
has a lexical representation consisting of
↑an optional sign followed by↑ a
↑nonempty↑ finitelength
sequence of decimal digits (#x30#x39). ↑If the sign is omitted, the positive sign
('+
') is assumed. If the sign is present, it must be
'+
' except for lexical forms denoting zero, which may
be preceded by a positive ('+
') or a negative
('
') sign.↑ For example: 0, 126, 100.
The ·canonical representation· for ↓unsignedByte↓↑unsignedByte↑ is defined by prohibiting certain options from the Lexical representation (§3.4.24.1). Specifically, leading zeroes are prohibited.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from unsignedByte↑ may also specify values for the following↑ ·constraining facets·:↑
unsignedByte has the following values for its ·fundamental facets·:
[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.
↓positiveInteger↓↑positiveInteger↑
has a lexical representation consisting
of an optional positive sign ('+
') followed by a
↑nonempty↑ finitelength
sequence of decimal digits (#x30#x39)↑,
at least one of which must be a digit other than '0
'↑.
For example: 1, 12678967543233, +100000.
The ·canonical representation· for ↓positiveInteger↓↑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.
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from positiveInteger↑ may also specify values for the following↑ ·constraining facets·:↑
positiveInteger has the following values for its ·fundamental facets·:
[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.
The lexical
space of yearMonthDuration consists of
strings which match the regular expression
'?P((([09]+Y)([09]+M)?)([09]+M))
' or the
expression '?P[09]+(Y([09]+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).
PT0S
')
is not in the
·lexical space· of yearMonthDuration.↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from yearMonthDuration↑ may also specify values for the following↑ ·constraining facets·:↑
yearMonthDuration has the following values for its ·fundamental facets·:
[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.
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 dayTimeDuration value space).
↓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 specified in the derivation of new types, if the value given is at least as restrictive as the one shown:↑
↑Datatypes derived by restriction from dayTimeDuration↑ may also specify values for the following↑ ·constraining facets·:↑
dayTimeDuration has the following values for its ·fundamental facets·:
[Definition:] The dateTimeStamp datatype is ·derived· from dateTime by giving the value required to its explicitTimezone facet. The result is that all values of dateTimeStamp are required to have explicit time zone offsets and the datatype is totally ordered.
As a consequence of requiring an explicit time zone offset, the lexical space of dateTimeStamp is reduced from that of dateTime by requiring a timezoneFrag fragment in the ·lexical representations·.

' monthFrag '
' dayFrag 'T
' ((hourFrag ':
' minuteFrag ':
' secondFrag) 
endOfDayFrag) timezoneFrag Constraint: Dayofmonth RepresentationsIn other words, the lexical space of dateTimeStamp consists of strings which are in the
·lexical space· of dateTime and which
also match the regular expression
'.*(Z(\+)[09][09]:[09][09])
'.
The ·lexical mapping· is that of dateTime restricted to the dateTimeStamp lexical space.
The ·canonical mapping· is that of dateTime restricted to the dateTimeStamp value space.
↓dateTimeStamp has the following ·constraining facets·:↓
↑dateTimeStamp 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 dateTimeStamp↑ may also specify values for the following↑ ·constraining facets·:↑
dateTimeStamp has the following values for its ·fundamental facets·:
The preceding sections of this specification have described datatypes in a way largely independent of their use in the particular context of schemaaware processing as defined in [XSD 1.1 Part 1: Structures].
This section presents the mechanisms necessary to integrate datatypes into the context of [XSD 1.1 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 facetbased 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 [XSD 1.1 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 ↓datatype (↓schema↓)↓ components, see Schema Component Details of [XSD 1.1 Part 1: Structures].
↑[Definition:] A component may be referred to as the owner of its properties, and of the values of those properties.↑
Simple Type Definitions provide for:
The Simple Type Definition schema component has the following properties:
Either an Attribute Declaration, an Element Declaration, a Complex Type Definition or a Simple Type Definition.
If the datatype has been ·derived· by ·restriction· then the Simple Type Definition component from which it is ·derived·, otherwise the Simple Type Definition for anySimpleType (§4.1.6).
With one exception, the {base type definition} of any Simple Type Definition is a Simple Type Definition. The exception is ·anySimpleType·, which has anyType, a Complex Type Definition, as its {base type definition}.
If not absent, must be a ·primitive· builtin definition.
Must be present (but may be empty) if {variety} is union, otherwise must be absent.
↓Datatypes↓↑Simple type definitions↑ are identified by their {name} and {target namespace}. Except for anonymous ↓datatypes↓↑Simple Type Definitions↑ (those with no {name}), ↓datatype definitions↓↑Simple Type Definitions↑ ↓·must·↓↑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 ↑(possibly empty)↑ finitelength sequence↑s↑ 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 ↓datatype↓↑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 ↓datatype definitions↓↑Simple Type Definitions↑.
The value of {facets} consists of the set of ·facet·s specified directly in the datatype definition unioned with the possibly empty set of {facets} of {base type definition}.
The value of {fundamental facets} consists of the set of ·fundamental facet·s and their values.
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 ↓·restriction·↓↑·facetbased 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}.
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:
simpleType
Element Information Item et al.<simpleType
final =
(#all  List of (list  union  restriction  extension))
id = ID
name = NCName
{any attributes with nonschema namespace . . .}>
Content: (annotation?, (restriction  list  union))
</simpleType>
<restriction
base = QName
id = ID
{any attributes with nonschema namespace . . .}>
Content: (annotation?, (simpleType?, (minExclusive  minInclusive  maxExclusive  maxInclusive  totalDigits  fractionDigits↑  maxScale↑↑  minScale↑  length  minLength  maxLength  enumeration  whiteSpace  pattern↑  assertion↑↑  explicitTimezone↑↑  {any with namespace: ##other}↑)*))
</restriction>
<list
id = ID
itemType = QName
{any attributes with nonschema namespace . . .}>
Content: (annotation?, simpleType?)
</list>
<union
id = ID
memberTypes = List of QName
{any attributes with nonschema namespace . . .}>
Content: (annotation?, simpleType*)
</union>
name
↓↑name
↑ [attribute], if
present↑ on the <simpleType> element↑,
otherwise ↓null↓↑absent↑
targetNamespace
↓↑targetNamespace
↑ [attribute]
of the parent ↓schema
↓↑schema
↑ element information
item↑, if present,
otherwise absent↑.base
[attribute] of <restriction>,
if present, otherwise the
type definition corresponding to the <simpleType> among
the [children] of <restriction>.final
[attribute],
if present, otherwise the actual value of the
finalDefault
[attribute] of the ancestor
schema
element information item,
if present,
otherwise the empty string, as follows:
#all
finalDefault
[attribute] of
schema may include
values other than
restriction, list or union, those values
are ignored in the determination of {final}
{
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:
SKU
'
(the barcode number that appears on products) from the
·builtin· datatype string by
supplying a value for the ·pattern· facet.
<simpleType name='SKU'> <restriction base='string'> <pattern value='\d{3}[AZ]{2}'/> </restriction> </simpleType>
SKU
' is the name of the new
·userdefined· datatype, string is
its ·base type·
and
·pattern· is the facet.
itemType
[attribute] of <list>,
or (b)
corresponding to the <simpleType> among
the [children] of <list>, whichever is present.
itemType
[attribute] or a <simpleType> [child], but not both.<simpleType name='listOfFloat'> <list itemType='float'/> </simpleType>
memberTypes
[attribute] of <union>, if
any, and (b) those corresponding to the <simpleType>s
among the [children] of <union>, if any, in order.
memberTypes
[attribute] or one or more <simpleType> [children],
or both.<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 ↓·derived·↓ datatype can be ↓·derived·↓↑·constructed·↑ from a ·primitive· datatype or ↓another ·derived·↓↑an ·ordinary·↑ datatype by one of three means: by ↓restriction↓↑·facetbased restriction·↑, by ↓list↓↑·list·↑ or by ↓union↓↑·union·↑.
delrestriction
Element Information Itembase
[attribute]
or the <simpleType> [children],
whichever is present.
<simpleType name='Sku'> <restriction base='string'> <pattern value='\d{3}[AZ]{2}'/> </restriction> </simpleType>
oldlist
Element Information ItemitemType
[attribute]
or the <simpleType> [children],
whichever is present.
A ·list· datatype must be ·derived· from an ·atomic· or a ·union· datatype, known as the ·item type· of the ·list· datatype. This yields a datatype whose ·value space· is composed of finitelength sequences of values from the ·value space· of the ·item type· and whose ·lexical space· is composed of spaceseparated lists of literals of the ·item type·.
<simpleType name='listOfFloat'> <list itemType='float'/> </simpleType>
As mentioned in List Datatypes (§2.6.1.2), when a datatype is ·derived· from a ·list· datatype, the following ·constraining facets· can be used:
regardless of the ·constraining facets· that are applicable to the ·atomic· datatype that serves as the ·item type· of the ·list·.
For each of ·length·, ·maxLength· and ·minLength·, the unit of length is measured in number of list items. The value of ·whiteSpace· is fixed to the value collapse.
oldunion
Element Information ItemmemberTypes
[attribute], if any,
in order, followed by the Simple Type Definition components
resolved to by the
<simpleType> [children], if any, in order.
If {variety} is union for
any Simple Type Definition components resolved
to above, then
the Simple Type Definition is replaced by its
{member type definitions}.
A ·union· datatype can be ·derived· from one or more ·atomic·, ·list· or other ·union· datatypes, known as the ·member types· of that ·union· datatype.
<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>
regardless of the ·constraining facets· that are applicable to the datatypes that participate in the ·union·
itemType
[attribute] or the
<simpleType> [child] of the <list> element
must be present, but not both.
base
[attribute] or the
simpleType
[child] of the <restriction>
element must be present, but not both.
memberTypes
[attribute] of the <union>
element must be nonempty or
there must be at least one simpleType
[child].
If {variety} is absent, then no facets are applicable. (This is true for anySimpleType.)
If {variety} is list, then the applicable facets are ↑↑assertions↑, ↑length, minLength, maxLength, pattern, enumeration, and whiteSpace.
If {variety} is union, then the applicable facets are ↓pattern and enumeration. ↓↑pattern, enumeration, and ↑assertions↑. ↑
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.
There is a simple type definition nearly equivalent to the simple version of the urtype definition present in every schema by definition. It has the following properties:
The Simple Type Definition of anySimpleType is present in every schema. It has the following properties:
anySimpleType
'http://www.w3.org/2001/XMLSchema
'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:
anyAtomicType
'http://www.w3.org/2001/XMLSchema
'Simple type definitions for all the builtin 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 {primitive type definition} (which is selfreferential), the {fundamental facets}, and in one case the {facets} varying from one to the next:
http://www.w3.org/2001/XMLSchema
'http://www.w3.org/2001/XMLSchema
' for the
{target namespace}
property. That namespace is controlled by the W3C and
datatypes will be added to it only by W3C or its designees.
Similarly, Simple Type Definitions for all the builtin ·ordinary· datatypes are present by definition in every schema, with properties as specified in ↓Derived datatypes↓↑Other Builtin Datatypes↑ (§3.4) and as represented in XML in ↑Illustrative XML representations for the builtin ordinary type definitions↑ (§C.2).
http://www.w3.org/2001/XMLSchema
'[Definition:] Each fundamental facet is a schema component that provides a limited piece of information about some aspect of each datatype. All ·fundamental facet· components are defined in this section. 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·.
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.
Every ·value space· supports the notion of equality, with the following rules:
On every datatype, the operation Equal is defined in terms of the equality property of the ·value space·: for any values a, b drawn from the ·value space·, Equal(a,b) is true if a = b, and false otherwise.
Note that in consequence of the above:
[Definition:] An order relation on a ·value space· is a mathematical relation that imposes a ·total order· or a ·partial order· on the members of the ·value space·.
[Definition:] A ·value space·, and hence a datatype, is said to be ordered if there exists an ·orderrelation· defined for that ·value space·.
[Definition:] A partial order is an ·orderrelation· that is irreflexive, asymmetric and transitive.
A ·partial order· has the following properties:
The notation a <> b is used to indicate the case when a != b and neither a < b nor b < a. For any values a and b from different ·primitive· ·value spaces·, a <> b.
[Definition:] When a <> b, a and b are incomparable,[Definition:] otherwise they are comparable.
[Definition:] A total order is an ·partial order· such that for no a and b is it the case that a <> b.
A ·total order· has all of the properties specified above for ·partial order·, plus the following property:
·ordered· provides for:
For some datatypes, this document specifies an order relation for their value spaces (see Order (§2.2.3)); the ordered facet reflects this. It takes the values total, partial, and false, with the meanings described below. For the ·primitive· datatypes, the value of the ordered facet is specified in Fundamental Facets (§F.1). For ·ordinary· datatypes, the value is inherited without change from the ·base type·. For a ·list·, the value is always false; for a ·union·, the value 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.
[Definition:] A ·value space·, and hence a datatype, is said to be ordered if some members of the ·value space· are drawn from a ·primitive· datatype for which the table in Fundamental Facets (§F.1) specifies the value total or partial for the ordered facet.
{value} depends on {variety}, {facets} and {member type definitions} in the Simple Type Definition component in which a ·ordered· component appears as a member of {fundamental facets}.
When {variety} is ·atomic·, {value} is inherited from {value} of {base type definition}. For all ·primitive· types {value} is as specified in the table in Fundamental Facets (§F.1).
[Definition:] A value u in an ·ordered· ·value space· U is said to be an inclusive upper bound of a ·value space· V (where V is a subset of U) if for all v in V, u >= v.
[Definition:] A value u in an ·ordered· ·value space· U is said to be an exclusive upper bound of a ·value space· V (where V is a subset of U) if for all v in V, u > v.
[Definition:] A value l in an ·ordered· ·value space· L is said to be an inclusive lower bound of a ·value space· V (where V is a subset of L) if for all v in V, l <= v.
[Definition:] A value l in an ·ordered· ·value space· L is said to be an exclusive lower bound of a ·value space· V (where V is a subset of L) if for all v in V, l < v.
[Definition:] A datatype is bounded if its ·value space· has either an ·inclusive upper bound· or an ·exclusive upper bound· and either an ·inclusive lower bound· or an ·exclusive lower bound·.
·bounded· provides for:
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.
{value} depends on ↑the ·owner's·↑ {variety}, {facets} and {member type definitions}↓ in the Simple Type Definition component in which a bounded component appears as a member of {fundamental facets}↓.
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 ↓among {facets}↓↑members of the ·owner's· {facets} set↑, then {value} is true; ↓else↓↑otherwise↑ {value} is false.
When ↑the ·owner's· ↑{variety} is list, ↓if ·length· or both of ·minLength· and ·maxLength· are among {facets}, then {value} is true; else↓ {value} is false.
When the ↑·owner's· ↑{variety} is union, if {value} is true for every member of ↓{member type definitions}and all members of {member type definitions}↓↑the ·owner's· {member type definitions} set and ↑↓ share a common ancestor↓↑all of the ·owner's· ·basic members· have the same {primitive type definition}↑, then {value} is true; ↓else↓↑otherwise↑ {value} is false.
[Definition:] Every ·value space· has associated with it the concept of cardinality. Some ·value spaces· are finite, some are countably infinite while still others could conceivably be uncountably infinite (although no ·value space· defined by this specification is uncountable infinite). A datatype is said to have the cardinality of its ·value space·.
It is sometimes useful to categorize ·value spaces· (and hence, datatypes) as to their cardinality. There are two significant cases:
·cardinality· provides for: