Please refer to the errata for this document, which may include some normative corrections.
See also translations.
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, Independent copy of the DTD for schema documents, and List of translations.
Copyright © 2009 © 2012 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, provides a superset of the capabilities found in XML 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
W3C CandidateRecommendation
specifies
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.
This version of this document was created on 30 April 2009.Changes since the previous public Working Draft include the following:
For those primarily interested in the changes since version 1.0,
the appendix Changes since version 1.0 (§I) 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.
Comments on this document should be made in W3C's public
installation of Bugzilla, specifying "XML Schema" as the major changes since version 1.0 include: Support forproduct.
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 1.1Schema 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.
This document has been added.reviewed by W3C
Members, by software developers, and by other W3C groups and
interested parties, and is endorsed by the Director as a W3C
Recommendation. It is now implementation defined whether datatypes dependent on definitions in [XML]a stable document and [Namespaces in XML] use the definitionsmay be used as
found in version 1.1reference material or version 1.0 of those specifications. A new primitive decimal type has been defined, which retains information about the precision ofcited from another document. W3C's role in
making the value. This typeRecommendation is aligned withto draw attention to the floatingpoint decimal types which are included in [IEEE 7542008] . In orderspecification
and to alignpromote its widespread deployment. This specification with those being prepared byenhances the
XSLfunctionality and XML Query Working Groups, a new datatype named anyAtomicType which serves asinteroperability of the base type definitionWeb.
An implementation report for all primitive atomic datatypes has been introduced.XSD
1.1 was prepared and used in the
conceptual modelDirector's decision to publish the previous version of this specification
as a Proposed Recommendation. The date and timerelated types has been defined more formally.Director's decision to publish
this document as a more formal treatmentW3C Recommendation is based on consideration
of reviews of the fundamental facetsProposed Recommendation by the public and by
the members of the primitive datatypesW3C Advisory committee.
The W3C XML Schema Working Group intends to process comments made about this recommendation, with any approved changes being handled as errata to be published separately.
This document has been adopted. More formal definitions ofproduced by the lexical space of most types have been provided, with detailed descriptionsW3C XML Schema Working
Group as part of the mappings from lexical representation to value and from value to · canonical representation ·W3C XML Activity. The
validation rule Datatype Valid (§4.1.4) has been recast in more declarative form. A paraphrasegoals of the constraint in procedural terms, which corrects some errorsXML Schema language version 1.1 are discussed in the
previous versionsRequirements
for XML Schema 1.1 document. The authors of this document, has been added as a note.document
are the rules governing partial implementationsmembers of infinite datatypes have been clarified. Various changes have been made in order to alignthe relevantXML Schema Working Group. Different parts
of this specification more closely with other relevant specifications, including especially the corresponding sections of [XSD 1.1 Part 1: Structures] . Changes since the previous public Working Draft include the following: To reduce confusion and averthave different editors.
This document was produced by a widespread misunderstanding,group operating under the normative references to various5
February 2004 W3C specifications now state explicitly that while the reference describes the particular edition ofPatent Policy. W3C maintains a specification current at the time this specification is published, conforming implementations of this specification are not required to ignore later editionspublic
list of any patent disclosures made in connection with the
other specification but instead may support later editions, thus allowing usersdeliverables of this specification to benefit from corrections to other specifications on which this one depends. Schema Component Constraint enumeration facet value required for NOTATION (§3.3.20) , which restrictsthe use of NOTATION to validate · literals · without first enumeratinggroup; that page also includes instructions
for disclosing a set of values, has been clarified. The use of the namespace whose URI is http://www.w3.org/2001/XMLSchemadatatypes continues to be defined.patent. An earlier draft of this specification had introduced text deprecating that use; that textindividual who has been deleted. This change resolves issue 6522 Please undeprecate the the namespace http://www.w3.org/2001/XMLSchemadatatypes , raised by John Cowan. The discussion of whitespace handling in whiteSpace (§4.3.6) makes clearer that when the value is collapse , · literals · consisting solelyactual knowledge
of whitespace characters are reduced to the empty string;a patent which the earlier formulation has been misunderstood by some implementors.individual believes contains Essential
Claim(s) must disclose the value spaceinformation in
accordance with section
6 of anyURI is now explicitly identified; this resolves issue 3264 xs:anyURI definition , raised bythe W3C XML Query and XSL working groups. References to IEEE 7541985 have been updated to refer to 7542000 (resolves issue 6664 ).Patent Policy.
The descriptionEnglish version of this specification is the value spaceonly normative
version. Information about translations of precisionDecimal has been revised for better clarity;this resolves issue 3248document is
available at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
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] 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 (§K).
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 (§G)), 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 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 datatype 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 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.
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:] 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 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.
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 in
conjunction with identity when
making ·facetbased restrictions· by enumeration,
when checking identity constraints (in the context of
[XSD 1.1 Part 1: Structures] ),)
and when checking value
constraints, andconstraints. It is used in
conjunction with order when making
·facetbased restrictions· involving order, withorder. The
following exception: equality relation used in the evaluation of XPath expressions
may differ. 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,either
equality or identity,
not for identity.identity alone.
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.
[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)
It is useful to categorize the datatypes defined in this specification along various dimensions, defining terms which can be used to characterize datatypes and the Simple Type Definitions which define them.
First, we distinguish ·atomic·, ·list·, and ·union· datatypes.
[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] is in the value space of the ·atomic· datatype NMTOKEN, while a sequence of such tokens is in the value space of the ·list· datatype NMTOKENS.
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·.
·List· datatypes are always ·constructed· from some other type; they are never ·primitive·. The ·value space· of a ·list· datatype is 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· each of which is a spaceseparated sequence of ·literals· of the ·item type·.
[Definition:] The ·atomic· or ·union· datatype that participates in the definition of a ·list· datatype is the item type of that ·list· datatype. If the ·item type· is a ·union·, each of its ·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 ·constructed· from an ordinary or ·primitive· ·atomic· datatype whose ·lexical space· allows whitespace (such as string or anyURI) or a ·union· datatype any of whose {member type definitions}'s ·lexical space· allows space. Since ·list· items are separated at whitespace before the ·lexical representations· of the items are mapped to values, no whitespace will ever occur in the ·lexical representation· of a ·list· item, even when the item type would in principle allow it. For the same reason, when every possible ·lexical representation· of a given value in the ·value space· of the ·item type· includes whitespace, that value can never occur as an item in any value of the ·list· datatype.
<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 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· of the ·item type·. Any ·pattern· specified when a new datatype is ·derived· from a ·list· datatype applies to the members of the ·list· datatype's ·lexical space·, not to the members of the ·lexical space· of the ·item type·. 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 or identical to an atomic value V2 if and only if V1 is equal or identical 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 ·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·.
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· 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 union type is defined by ·restricting· another ·union·, its ·value space·, ·lexical space·, and ·lexical mapping· are subsets of the ·value spaces·, ·lexical spaces·, and ·lexical mappings· of its ·base type·.
·Union· datatypes are always ·constructed· from other datatypes; they are never ·primitive·. Currently, there are no ·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 (zero or more) of ordinary or ·primitive· ·datatypes· can participate in a ·union· type.
[Definition:] The datatypes that participate in the definition of a ·union· datatype are known as the member types of that ·union· datatype.
[Definition:] The transitive membership of a ·union· is the set of its own ·member types·, and the ·member types· of its members, and so on. More formally, if U is a ·union·, then (a) its ·member types· are in the transitive membership of U, and (b) for any datatypes T1 and T2, if T1 is in the transitive membership of U and T2 is one of the ·member types· of T1, then T2 is also in the transitive membership of U.
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
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. As noted above,
the evaluation order can be overridden with the use of
xsi:type.
<xsd:element<xs:element name='size'><xsd:simpleType><xsd:union><xsd:simpleType><xsd:restriction<xs:simpleType> <xs:union> <xs:simpleType> <xs:restriction base='integer'/></xsd:simpleType><xsd:simpleType><xsd:restriction</xs:simpleType> <xs:simpleType> <xs:restriction base='string'/></xsd:simpleType></xsd:union></xsd:simpleType></xsd:element></xs:simpleType> </xs:union> </xs:simpleType> </xs:element>
<size>1</size> <size>large</size> <sizexsi:type='xsd:string'>1</size>xsi:type='xs:string'>1</size>
The ·canonical mapping· of a ·union· datatype maps each value onto the ·canonical representation· of that value obtained using the ·canonical mapping· of the first ·member type· in whose value space it lies.
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 and not defined in terms of other datatypes, while integer is ·constructed· from the more general datatype decimal.
[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.
A ·list· datatype can be ·constructed· from another datatype (its ·item type·) by creating a ·value space· that consists of finitelength sequences 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 ·constructed· from one or more datatypes by unioning their ·lexical mappings· and, consequently, their ·value spaces· and ·lexical spaces·. Datatypes so ·constructed· also have anySimpleType as their ·base type·. Note that since the ·value space· and ·lexical space· of any ·union· datatype are necessarily subsets of the ·value space· and ·lexical space· of anySimpleType, any datatype ·constructed· as a ·union· is a ·restriction· of its base type.
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· datatypes included in this specification and the ·userdefined· datatypes which will be created by individual schema designers. The ·builtin· ·constructed· datatypes are those which are believed to be so common that if they were not defined in this specification many schema designers would end up reinventing them. Furthermore, including these ·constructed· datatypes in this specification serves to demonstrate the mechanics and utility of the datatype generation facilities of this specification.
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:
Each ·userdefined· datatype may also be associated with a target namespace. 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.
ItsThe
·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.6).
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.6).
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; the ·lexical space· is defined using an extended Backus Naur Format grammar (and in most cases also a regular expression using the regular expression language of Regular Expressions (§G)); ·constraining facets· which apply to the datatype are listed; and any datatypes ·constructed· from this datatype are specified.
Conforming processors must support the ·primitive· datatypes defined in this specification; it is ·implementationdefined· whether they support others. ·Primitive· datatypes 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 zero or more characters (as defined in [XML]) that ·match· the Char production from [XML]. A character is an atomic unit of communication; it is not further specified except to note that every character has a corresponding Universal Character Set (UCS) code point, which is an integer.
It is ·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.
The string datatype 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·:
The string datatype has the following values for its ·fundamental facets·:
The following ·builtin· datatype is ·derived· from string
[Definition:] boolean represents the values of twovalued logic.
boolean has the ·value space· of twovalued logic: {true, false}.
The ·lexical mapping· for boolean is ·booleanLexicalMap·; the ·canonical mapping· is ·booleanCanonicalMap·.
The boolean datatype 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·:
The boolean datatype 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
dividing
an integer by a nonnegative
power of ten, i.e., expressible as
i / 10^{n}
where i and n are integers
and
n ≥ 0.
Precision is not reflected in this value space;
the number 2.0 is not distinct from the number 2.00.
(The datatype precisionDecimal may be used for values in which precision is significant.)The order relation on decimal
is the order relation on real numbers, restricted
to this subset.
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
'.
(\+)?([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 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 decimal datatype 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·:
The decimal datatype 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". Thisfloat datatype
is
introduced to provide a variant of decimal that closely corresponds topatterned after the floatingpoint decimal datatypes described by [IEEE 7542008] . Precision of values is retained and values are included for two zeroes, two infinities, and notanumber. Note: Users wishing to implement useful operations for thisIEEE
singleprecision 32bit floating point datatype
(beyond the equality and order specified herein) are urged to consult[IEEE 7542008]. Informally, the precision of a
Its
value space is denoted by the numbera subset of decimal digits afterthe
decimalrational numbers. Floating point in itsnumbers are often used to
approximate arbitrary real numbers.
The · lexical representationsvalue space· . of float contains the
numbersnonzero numbers m × 2^{e} ,
where m is an integer whose absolute value is less than 2^{24},
and 2.00, although numerically equal, have different precision (0e is an integer between −149 and 2 respectively). 104, inclusive. In addition to
these values, the precision of a·value is derived fromspace· 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. NaN
INF
', '+INF
',
'INF
',
and 'NaN
(\+)?([09]+(\.[09]*)?\.[09]+)([Ee](\+)?[09]+)?
(\+)?INFNaN
The · lexical mapping · for precisionDecimalfloat datatype is · precisionDecimalLexicalMap · . designed to implement for schema
processing the singleprecision floatingpoint datatype of
[IEEE 7542008]. That specification does not specify specific
· canonicallexical representations·,
but does prescribe requirements on any ·lexical mapping·
isused. Any · precisionDecimalCanonicalMaplexical mapping·
. For example, each ofthat maps the ·lexical representationsspace· shown below is followed by its corresponding value triple (just described onto the
· numericalValuevalue space·, · arithmeticPrecision ·is a function,
satisfies the requirements of
[IEEE 7542008], and correctly handles the
mapping of the literals
'INF
', 'NaN
', etc., to the
· signspecial values· ) and,
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
· canonical representationlexical mappings· : ' 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 ' Note that.
The last three examples not only show different·lexical representationsmapping· ·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 same value, but aresimple rounding
algorithm used in ·floatLexicalMap· may be more efficiently
implemented using the algorithms of particular interest because values with negative precision can only have[Clinger, WD (1990)].
The · lexicalcanonical mapping· ·floatCanonicalMap· is
provided as an example of a mapping that does not produce unnecessarily long
·canonical representations· in scientific notation..
Other algorithms which do not yield identical results for mapping from float
values to character strings are permitted by [IEEE 7542008].
precisionDecimalThe
float datatype
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 precisionDecimalfloat may also
specify values for the
following ·constraining facets·:
precisionDecimalThe
float
datatype
has the following values for its
·fundamental facets·:
[Definition:] The floatdouble
datatype is
patterned after the
IEEE singleprecision 32bitdoubleprecision 64bit floating point datatype
[IEEE 7542008].
ItsEach 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.
The ·value space· of floatdouble contains the
nonzero numbers m × 2^{e} ,
where m is an integer whose absolute value is less than 2^{ 2453},
and e is an integer between −149−1074 and 104,971, inclusive. In addition to
these values, the ·value space· of floatdouble 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
').INF
', '+INF
',
'INF
', and 'NaN
'
(\+)?([09]+(\.[09]*)?\.[09]+)([Ee](\+)?[09]+)? (\+)?INFNaN
The floatdouble datatype is designed to implement for schema
processing the singleprecisiondoubleprecision 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· · floatLexicalMapdoubleLexicalMap· 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 · floatLexicalMapdoubleLexicalMap· may be more efficiently
implemented using the algorithms of [Clinger, WD (1990)].
The ·canonical mapping· · floatCanonicalMapdoubleCanonicalMap· 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].
floatThe
double datatype
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 floatdouble may also
specify values for the
following ·constraining facets·:
floatThe
double
datatype
has the following values for its
·fundamental facets·:
[Definition:] The double datatypeduration
is patterned after the IEEE doubleprecision 64bit floating pointa datatype [IEEE 7542008] . Each floating point datatype has a value spacethat is a subsetrepresents
durations of time. The rational numbers. Floating point numbers are often used to approximate arbitrary real numbers. Note: The only significant differences between floatconcept 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 double"15 days ending 12 July 1995" are
the three defining constants 53 (vs 24), −1074 (vs −149),not duration
values. duration can provide addition and
971 (vs 104). 3.3.6.1subtraction operations between duration values and
between duration/dateTime value Spacepairs,
and can be the · value space ·result of double contains the nonzero numbers m × 2 e , where m is an integer whose absolute valuesubtracting dateTime
values. However, only addition to dateTime
is less than 2 53 ,required for XML Schema processing and eis
an integer between −1074 and 971, inclusive. defined in
addition to these values,the function ·dateTimePlusDuration·.
Under the Schema 1.0 version of this datatype did not differentiate between 0definition just given,
two duration values are equal if and −0only if they are identical.
T
' ((duHourFrag duMinuteFrag? duSecondFrag?) 
(duMinuteFrag duSecondFrag?) 
duSecondFrag)
'? 'P
' ((duYearMonthFrag duDayTimeFrag?)  duDayTimeFrag)Thus, a durationLexicalRep consists of [IEEE 7542008] . That specification does not specify specific · lexical representations ·one or more of a duYearFrag,
but does prescribe requirements on any · lexical mapping · used. Any · lexical mapping · that mapsduMonthFrag, duDayFrag, duHourFrag,
duMinuteFrag, and/or duSecondFrag, in order, with letters
'P
' and 'T
' (and perhaps a '
')
where appropriate.
matches only strings in which the
?P[09]+Y?([09]+M)?([09]+D)?(T([09]+H)?([09]+M)?([09]+(\.[09]+)?S)?)?
.*[YMDHS].*
' matches only
strings in .*[^T]
' matches
only strings in which 'T
' is T
' appears, something follows it. The T
' will be ?P( ( ( [09]+Y([09]+M)?([09]+D)?  ([09]+M)([09]+D)?  ([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
· canonicallexical mapping· for duration is · doubleCanonicalMapdurationMap· is provided as an example of a mapping that does not produce unnecessarily long.
·The canonical
representationsmapping· . Other algorithms which do not yield identical resultsfor mapping from float values to character strings are permitted by [IEEE 7542008]duration
is ·durationCanonicalMap·.
doubleThe
duration datatype
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 doubleduration may also
specify values for the
following ·constraining facets·:
doubleThe
duration
datatype
has the following values for its
·fundamental facets·:
The following ·builtin· datatypes are ·derived· from duration
dateTime represents
durationsinstants of time. time, optionally marked
with a particular time zone offset. Values representing
the concept of duration being captured is drawn from those of [ISO 8601]same instant but having
different time zone offsets are equal but not
identical.
dateTime uses the
date/timeSevenPropertyModel, 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 additionwith no properties
except ·timezoneOffset·
permitted
to dateTime is required for XML Schema processing and is defined inbe absent. The function· dateTimePlusDurationtimezoneOffset· property remains
·optional·.
Equality and order are orderedas prescribed
in The same way when added to each of these fourSevenproperty Model (§D.2.1).
dateTime values, they will retainvalues are ordered
by their ·timeOnTimeline· value.
Y ' duMonthFrag ::= unsignedNoDecimalPtNumeral
' monthFrag ' M ' duDayFrag ::= unsignedNoDecimalPtNumeral ' D ' duHourFrag ::= unsignedNoDecimalPtNumeral ' H ' duMinuteFrag ::= unsignedNoDecimalPtNumeral
' dayFrag ' M ' duSecondFrag ::= ( unsignedNoDecimalPtNumeral  unsignedDecimalPtNumeral ) ' S ' duYearMonthFrag ::= ( duYearFrag duMonthFrag ?)  duMonthFrag duTimeFrag ::= 'T
' (( :
' minuteFrag ':
' secondFrag) 
endOfDayFrag) and3
' (and perhaps a29
'
T0
' 
', 'T
', and
' will be an hour, minute, or second field. The intersection of these three regular expressions is equivalent to:
', separate the 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
The · yearlexical mapping·
for dateTime is permitted to have the value zero. Second,·dateTimeLexicalMap·.
The interpretation of· yearcanonical mapping· valuesis changed accordingly: a· yeardateTimeCanonicalMap· value of zero represents 1 BCE, −1 represents 2 BCE, etc. This representation simplifies interval arithmetic and leapyear calculation for dates before.
The
common era (which may be why astronomersdateTime datatype
and others interested in such calculations with the proleptic Gregorian calendarall datatypes derived from it by restriction have adopted it), and is consistentthe
following ·constraining facets· with fixed values; these
facets must not be changed from the current edition of [ISO 8601] . Note that 1 BCE, 5 BCE, and so on (years 0000, 0004, etc. invalues shown:
The lexical representation defined here) are leap years indateTime datatype
has the proleptic Gregorian calendar used forfollowing
·constraining facets· with the date/time datatypes defined here. Version 1.0 of this specification was unclear aboutvalues shown; these
facets may be specified
in the treatmentderivation of leap years beforenew types, if the
common era. If existing schemas or datavalue given is at least as restrictive as the one shown:
Datatypes derived by
restriction from dateTime may also
specify dates of 29 Februaryvalues for any years beforethe
common era, then some values giving a date of 29 February which were valid under a plausible interpretation of XSD 1.0 will be invalid under this specification, and some which were invalid will be valid. With that possible exception, schemas and data valid underfollowing ·constraining facets·:
The
old interpretation remain valid underdateTime
datatype
has the new. Constraint: Dayofmonthfollowing values Thefor its
· dayfundamental facets· value must be no more than 30 if:
The following · monthbuiltin·
datatype is
one·derived·
from
dateTime
time
represents instants of 4, 6, 9,time that recur at the same point in each
calendar day, or 11; no more than 28 ifthat occur in some arbitrary calendar day.
time uses the date/timeSevenPropertyModel, with
·year·, ·month· is 2,
and · yearday· is not divisible 4, or is divisible by 100 but not by 400; and no more than 29 ifrequired
to be absent. · monthtimezoneOffset· is 2 andremains
· yearoptional· is divisible by 400, or by 4 but not by 100..
Equality and order are as prescribed in
The Sevenproperty Model (§D.2.1). dateTimetime values
(points in time in an "arbitrary" day) are ordered
bytaking into account their · timeOnTimelinetimezoneOffset· value. Note:.
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 order oftime zone offsets allowed spread over 28 hours,
it is
possible for the period denoted by a dateTime value havinggiven calendar day with one
time zone offset to be completely disjoint from the period denoted by
the same calendar day with a · timezoneOffset · relativedifferent 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 another value whosethe
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
23:00:0003:00
' and '02:00:00Z
',
now denote unequal values :
' minuteFrag ':
' secondFrag) 
endOfDayFrag) timezoneFrag Note that neither the timeLexicalRep production nor this regular expression alone enforce the
(([01][09]2[03]):[05][09]:[05][09](\.[09]+)?(24:00:00(\.0+)?))(Z(\+)((0[09]1[03]):[05][09]14:00))?
In such representations: yearFragThe ·lexical mapping·
for time is
a numeral consisting of at least four decimal digits, optionally preceded by a minus sign; leading ' 0 ' digits are prohibited except to bring·timeLexicalMap·; the digit count up to four. It represents·canonical mapping· is
·timeCanonicalMap·.
 ',00:00:00
' : ', separate the various numerals. monthFrag , dayFrag , hourFrag , and minuteFrag are numerals consisting of exactly two decimal digits. They represent24:00:00
' to the same value, namely midnight
(· The
time datatype
and all datatypes derived from it by restriction have the
following · minuteconstraining facets· with fixed values; these
facets must not be changed from the values respectively. secondFrag is a numeral consisting of exactly two decimal digits, or two decimal digits, a decimal point, and one or more trailing digits. It representsshown:
The time datatype
has the following
· secondconstraining facets· value. Alternatively, endOfDayFrag combines the hourFrag , minuteFrag , minuteFrag , and their separators to represent midnight ofwith the day, which isvalues shown; these
facets may be specified
in the first momentderivation of the next day. timezoneFrag ,new types, if present, specifies an offset between UTC and local time. Time zone offsets are a count of minutes (expressed in timezoneFragthe
value given is at least as a count of hours and minutes) that are added or subtractedrestrictive as the one shown:
Datatypes derived by
restriction from UTCtime to get the "local" time. ' Z ' is an alternative representation of the time zone offset ' 00:00 ', which is, of course, zero minutes from UTC. For example, 20021010T12:00:00−05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is equal to 20021010T17:00:00Z, five hours later than 20021010T12:00:00Z. Note: For the most part, this specification adopts the distinction between 'timezone' and 'timezone offset' laid out in [Timezones] . Version 1.0 of this specification did not make this distinction, but used the term 'timezone' for the time zone offset information associated with date and timerelated datatypes. Some traces of the earlier usage remain visible in this and other specifications. The names timezoneFrag and explicitTimezone are such traces ; others will be found in the names of functions defined in [XQuery 1.0 and XPath 2.0 Functions and Operators] , or in references in this specification to "timezoned" and "untimezoned" values. The dateTimeLexicalRep production is equivalent to this regular expression once whitespace is removed. ?([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 · . 3.3.8.3 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: whiteSpace = collapse (fixed) 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: explicitTimezone = optional Datatypes derived by restriction from dateTime may also specify values formay also
specify values for the
following ·constraining facets·:
dateTimeThe
time
datatype
has the following values for its
·fundamental facets·:
[Definition:]
date
represents instantstopopen intervals of time that recur at the same pointexactly one day in length on the timelines of
dateTime, beginning on the beginning moment of each
calendarday, or that occur in some arbitrary calendar day.up to but not including the beginning
moment of the next day). For nontimezoned values, the topopen
intervals disjointly cover the nontimezoned timeline,
one per day. For timezoned
values, the intervals begin at every minute and therefore overlap.
timedate uses the date/timeSevenPropertyModel, with
· yearhour·, · monthminute·,
and · daysecond· 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 ·.
:
' :
' 3
' 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
?([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 timedate is · timeLexicalMapdateLexicalMap· ;.
The ·canonical mapping· is · timeCanonicalMapdateCanonicalMap·.
timeThe
date datatype
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:
timeThe date datatype
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 timedate may also
specify values for the
following ·constraining facets·:
timeThe
date
datatype
has the following values for its
·fundamental facets·:
gYearMonth
represents topopen intervals of exactlyspecific whole Gregorian months in specific
Gregorian years.
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).

' monthFrag
?([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))?NotethatneitherthedateLexicalRepproductionnorthisregularexpressionaloneenforcetheconstraintondateLexicalRepgivenabove.?([19][09]{3,}0[09]{3})(0[19]1[02])(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping·
for dategYearMonth is · dateLexicalMapgYearMonthLexicalMap·.
The ·canonical mapping· is · dateCanonicalMapgYearMonthCanonicalMap·.
dateThe
gYearMonth datatype
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:
dateThe gYearMonth datatype
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 dategYearMonth may also
specify values for the
following ·constraining facets·:
dateThe
gYearMonth
datatype
has the following values for its
·fundamental facets·:
gYear
represents specific whole Gregorian months in specificGregorian calendar years.
gYearMonthgYear 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).
?([19][09]{3,}0[09]{3})(0[19]1[02])(Z(\+)((0[09]1[03]):[05][09]14:00))??([19][09]{3,}0[09]{3})(Z(\+)((0[09]1[03]):[05][09]14:00))?
The ·lexical mapping·
for gYearMonthgYear is · gYearMonthLexicalMapgYearLexicalMap·.
The ·canonical mapping·
is · gYearMonthCanonicalMapgYearCanonicalMap·.
gYearMonthThe
gYear datatype
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:
gYearMonthThe gYear datatype
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 gYearMonthgYear may also
specify values for the
following ·constraining facets·:
gYearMonthThe
gYear
datatype
has the following values for its
·fundamental facets·:
gMonthDay represents Gregorianwhole calendar
years.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.
gYeargMonthDay uses the date/timeSevenPropertyModel, with
· month · , · dayyear·, ·hour·, ·minute·, and ·second· required
to be absent. ·timezoneOffset· remains
·optional·.
Equality and order are as prescribed in The Sevenproperty Model (§D.2.1).

' 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))?
The ·lexical mapping· for gMonthDay is ·gMonthDayLexicalMap·. The ·canonical mapping· is ·gMonthDayCanonicalMap·.
The gMonthDay datatype 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:
The gMonthDay datatype 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·:
The gMonthDay datatype has the following values for its ·fundamental facets·:
[Definition:] gDay represents whole days within an arbitrary month—days that recur at the same point in each (Gregorian) month. This datatype is used to represent a specific day of the month. To indicate, for example, that an employee gets a paycheck on the 15th of each month. (Obviously, days beyond 28 cannot occur in all months; they are nonetheless permitted, up to 31.)
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.)
(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·.
The gDay datatype 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:
The gDay datatype 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·:
The gDay datatype has the following values for its ·fundamental facets·:
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).
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).
(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·.
The gMonth datatype 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:
The gMonth datatype 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·:
The gMonth datatype has the following values for its ·fundamental facets·:
[Definition:] hexBinary represents arbitrary hexencoded binary data.
The ·value space· of hexBinary is the set of finitelength sequences of zero or more binary octets. The length of a value is the number of octets.
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 mapping· of hexBinary is given formally in ·hexBinaryCanonical·.
The hexBinary datatype 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·:
The hexBinary datatype has the following values for its ·fundamental facets·:
[Definition:] base64Binary represents arbitrary Base64encoded binary data. For base64Binary data the entire binary stream is encoded using the Base64 Encoding defined in [RFC 3548], which is derived from the encoding described in [RFC 2045].
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 representations· of
base64Binary
values are limited to the 65 characters of the Base64 Alphabet defined in
[RFC 3548],
i.e., az
, AZ
,
09
, the plus sign (+), the forward slash (/) and the
equal sign (=), together with
the space character
(#x20). No other characters are allowed.
For compatibility with older mail gateways, [RFC 2045] suggests that Base64 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 representations· of base64Binary data. It must not be enforced by XML Schema processors.
The ·lexical space· of base64Binary is the set of literals which ·match· the base64Binaryproduction.
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 representation· to be a multiple of four, and for equals signs to appear only at the end of the ·lexical representation·; literals which do not meet these constraints are not legal ·lexical representations· of base64Binary.
The ·lexical mapping· for base64Binary is as given in [RFC 2045] and [RFC 3548].
The canonical ·lexical representation· of a base64Binary data value is the Base64 encoding of the value which matches the Canonicalbase64Binary production in the following grammar:
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 value may be calculated from the ·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 USutf8USASCII 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].
The base64Binary datatype 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·:
The base64Binary datatype has the following values for its ·fundamental facets·:
[Definition:] anyURI represents an Internationalized Resource Identifier Reference (IRI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be an IRI Reference). This type should be used when the value fulfills the role of an IRI, as defined in [RFC 3987] or its successor(s) in the IETF Standards Track.
The value space of anyURI is the set of finitelength sequences of zero or more characters (as defined in [XML]) that ·match· the Char production from [XML].
The ·lexical space· of anyURI is 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.
The anyURI datatype 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·:
The anyURI datatype 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].
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).
The mapping from lexical space to value space for a particular QName ·literal· depends on the namespace bindings in scope where the literal occurs.
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.
The QName datatype 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·:
The QName datatype has the following values for its ·fundamental facets·:
[Definition:] NOTATION represents the NOTATION attribute type from [XML]. The ·value space· of NOTATION is the set of QNames of notations declared in the current schema. The ·lexical space· of NOTATION is the set of all names of notations declared in the current schema (in the form of QNames).
The lexical mapping rules for NOTATION are as given for
QName in
QName (§3.3.19)(§3.3.18).
For compatibility (see Terminology (§1.6)) NOTATION should be used only on attributes and should only be used in schemas with no target namespace.
The NOTATION datatype 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·:
The NOTATION datatype 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· ·ordinary· datatypes defined by this specification. The XML representation used to define ·ordinary· datatypes (whether ·builtin· or ·userdefined·) is given in XML Representation of Simple Type Definition Schema Components (§4.1.2) and the complete definitions of the ·builtin· ·ordinary· datatypes are provided in the appendix Schema for Schema Documents (Datatypes) (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.
The normalizedString datatype 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·:
The normalizedString datatype 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.
The token datatype 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·:
The token datatype 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 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>
The language datatype 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·:
The language datatype has the following values for its ·fundamental facets·:
[Definition:] NMTOKEN represents the NMTOKEN attribute type from [XML]. The ·value space· of NMTOKEN is the set of tokens that ·match· the Nmtoken production in [XML]. The ·lexical space· of NMTOKEN is the set of strings that ·match· the Nmtoken production in [XML]. The ·base type· of NMTOKEN is token.
It is ·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 should be used only on attributes.
The NMTOKEN datatype 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·:
The NMTOKEN datatype has the following values for its ·fundamental facets·:
[Definition:] NMTOKENS
represents the NMTOKENS attribute
type from [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 should be used only on attributes. 3.4.5.1 FacetsNMTOKENS has the followingis derived
from ·anySimpleType
· in two steps: an anonymous list type
is defined, whose ·item type· is NMTOKEN; this is
the ·base type· of NMTOKENS, which restricts
its value space to lists with at least one item.
For compatibility (see Terminology (§1.6)) NMTOKENS should be used only on attributes.
The NMTOKENS datatype 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·:
The NMTOKENS datatype 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]. The ·lexical space· of Name is the set of all strings which ·match· the Name production of [XML]. The ·base type· of Name is token.
It is ·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).
The Name datatype 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·:
The Name datatype 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]. The ·lexical space· of NCName is the set of all strings which ·match· the NCName production of [Namespaces in XML]. The ·base type· of NCName is Name.
It is ·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).
The NCName datatype 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·:
The NCName datatype has the following values for its ·fundamental facets·:
[Definition:] ID represents the ID attribute type from [XML]. The ·value space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·lexical space· of ID is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ID is NCName.
For compatibility (see Terminology (§1.6)), ID should be used only on attributes.
The ID datatype 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·:
The ID datatype has the following values for its ·fundamental facets·:
[Definition:] IDREF represents the IDREF attribute type from [XML]. The ·value space· of IDREF is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·lexical space· of IDREF is the set of strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of IDREF is NCName.
For compatibility (see Terminology (§1.6)) this datatype should be used only on attributes.
The IDREF datatype 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·:
The IDREF datatype has the following values for its ·fundamental facets·:
[Definition:]
IDREFS represents the
IDREFS attribute type from
[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 IDREF.
IDREFS is derived
from ·anySimpleType
· in two steps: an anonymous list type
is defined, whose ·item type· is IDREF; this is
the ·base type· of IDREFS, which restricts
its value space to lists with at least one item.
For compatibility (see Terminology (§1.6)) IDREFS should be used only on attributes.
The IDREFS datatype 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·:
The IDREFS datatype has the following values for its ·fundamental facets·:
[Definition:] ENTITY represents the ENTITY attribute type from [XML]. The ·value space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML] and have been declared as an unparsed entity in a document type definition. The ·lexical space· of ENTITY is the set of all strings that ·match· the NCName production in [Namespaces in XML]. The ·base type· of ENTITY is NCName.
For compatibility (see Terminology (§1.6)) ENTITY should be used only on attributes.
The ENTITY datatype 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·:
The ENTITY datatype has the following values for its ·fundamental facets·:
[Definition:] ENTITIES
represents the ENTITIES attribute
type from [XML]. The ·value space·
of ENTITIES is the set of finite, nonzerolength sequences of
·ENTITY· valuessvalues 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.
ENTITIES is derived
from ·anySimpleType
· in two steps: an anonymous list type
is defined, whose ·item type· is ENTITY; this is
the ·base type· of ENTITIES, which restricts
its value space to lists with at least one item.
For compatibility (see Terminology (§1.6)) ENTITIES should be used only on attributes.
The ENTITIES datatype 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·:
The ENTITIES datatype 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 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 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.
The integer datatype 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:
The integer datatype 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·:
The integer datatype 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
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 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.
The nonPositiveInteger datatype 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:
The nonPositiveInteger datatype 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·:
The nonPositiveInteger datatype 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
has a lexical representation consisting
of a negative sign ('
') followed by a nonempty finitelength sequence of
decimal digits (#x30#x39). (#x30#x39),
at least one of which must be a digit other than '0
'.
For example: 1, 12678967543233,
100000.
The ·canonical representation· for negativeInteger is defined by prohibiting certain options from the Lexical representation (§3.4.15.1). Specifically, leading zeroes are prohibited.
The negativeInteger datatype 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:
The negativeInteger datatype 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·:
The negativeInteger datatype 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 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 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.
The long datatype 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:
The long datatype 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·:
The long datatype 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 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 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.
The int datatype 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:
The int datatype 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·:
The int datatype 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 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 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.
The short datatype 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:
The short datatype 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·:
The short datatype 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 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 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.
The byte datatype 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:
The byte datatype 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·:
The byte datatype 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
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 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.
The nonNegativeInteger datatype 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:
The nonNegativeInteger datatype 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·:
The nonNegativeInteger datatype 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
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 is defined by prohibiting certain options from the Lexical representation (§3.4.21.1). Specifically, leading zeroes are prohibited.
The unsignedLong datatype 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:
The unsignedLong datatype 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·:
The unsignedLong datatype 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
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 is defined by prohibiting certain options from the Lexical representation (§3.4.22.1). Specifically, leading zeroes are prohibited.
The unsignedInt datatype 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:
The unsignedInt datatype 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·:
The unsignedInt datatype 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
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 is defined by prohibiting certain options from the Lexical representation (§3.4.23.1). Specifically, the leading zeroes are prohibited.
The unsignedShort datatype 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:
The unsignedShort datatype 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·:
The unsignedShort datatype 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
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 is defined by prohibiting certain options from the Lexical representation (§3.4.24.1). Specifically, leading zeroes are prohibited.
The unsignedByte datatype 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:
The unsignedByte datatype 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·:
The unsignedByte datatype 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
has a lexical representation consisting
of an optional positive sign ('+
') followed by a
nonempty finitelength
sequence of decimal digits (#x30#x39). (#x30#x39),
at least one of which must be a digit other than '0
'.
For example: 1, 12678967543233, +100000.
The ·canonical representation· for positiveInteger is defined by prohibiting certain options from the Lexical representation (§3.4.25.1). Specifically, the optional "+" sign is prohibited and leading zeroes are prohibited.
The positiveInteger datatype 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:
The positiveInteger datatype 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·:
The positiveInteger datatype 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.The yearMonthDuration datatype 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:
The yearMonthDuration datatype 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·:
The yearMonthDuration datatype 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).
The dayTimeDuration datatype 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:
The dayTimeDuration datatype 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·:
The dayTimeDuration datatype 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.
The dateTimeStamp datatype 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·:
The dateTimeStamp datatype 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 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.
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.
The value of this property must be a primitive or ordinary simple type definition with {variety} = atomic, or an ordinary simple type definition with {variety} = union whose basic members are all atomic; the value must not itself be a list type (have {variety} = list) or have any basic members which are list types.
Must be present (but may be empty) if {variety} is union, otherwise must be absent.
The sequence may contain any primitive or ordinary simple type definition, but must not contain any special type definitions.
Simple type definitions are identified by their {name} and {target namespace}. Except for anonymous Simple Type Definitions (those with no {name}), Simple Type Definitions must be uniquely identified within a schema. Within a valid schema, each Simple Type Definition uniquely determines one datatype. The ·value space·, ·lexical space·, ·lexical mapping·, etc., of a Simple Type Definition are the ·value space·, ·lexical space·, etc., of the datatype uniquely determined (or "defined") by that Simple Type Definition.
If {variety} is ·atomic· then the ·value space· of the datatype defined will be a subset of the ·value space· of {base type definition} (which is a subset of the ·value space· of {primitive type definition}). If {variety} is ·list· then the ·value space· of the datatype defined will be the set of (possibly empty) finitelength sequences of values from the ·value space· of {item type definition}. If {variety} is ·union· then the ·value space· of the datatype defined will be a subset (possibly an improper subset) of the union of the ·value spaces· of each Simple Type Definition in {member type definitions}.
If {variety} is ·atomic· then the {variety} of {base type definition} must be ·atomic·, unless the {base type definition} is anySimpleType. If {variety} is ·list· then the {variety} of {item type definition} must be either ·atomic· or ·union·, and if {item type definition} is ·union· then all its ·basic members· must be ·atomic·. If {variety} is ·union· then {member type definitions} must be a list of Simple Type Definitions.
The {facets} property
determines the ·value space· and ·lexical space· of the datatype
being defined by imposing constraints which
mustare to be satisfied by all valid
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 ·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.targetNamespace
[attribute]
of the parent schema
element information
item, if present,
otherwise absent.