Movatterモバイル変換


[0]ホーム

URL:


W3C

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes

W3C Recommendation 5 April 2012

This version:
http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/
Latest version:
http://www.w3.org/TR/xmlschema11-2/
Previous version:
http://www.w3.org/TR/2012/PR-xmlschema11-2-20120119/
Editors (Version 1.1):
David Peterson, invited expert (SGMLWorks!)<davep@iit.edu>
Shudi (Sandy) Gao 高殊镝, IBM<sandygao@ca.ibm.com>
Ashok Malhotra, Oracle Corporation<ashokmalhotra@alum.mit.edu>
C. M. Sperberg-McQueen, Black Mesa Technologies LLC<cmsmcq@blackmesatech.com>
Henry S. Thompson, University of Edinburgh<ht@inf.ed.ac.uk>
Editors (Version 1.0):
Paul V. Biron, Kaiser Permanente, for Health Level Seven<paul@sparrow-hawk.org>
Ashok Malhotra, Oracle Corporation<ashokmalhotra@alum.mit.edu>

Please refer to theerrata for this document, which may include some normative corrections.

See alsotranslations.

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

Copyright © 2012 W3C® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark anddocument use rules apply.


Abstract

XML Schema: Datatypes is part 2 of the specification ofthe XML Schema language. It defines facilities for defining datatypesto be used in XML Schemas as well as other XML specifications. Thedatatype language, which is itself represented in XML, provides a superset of thecapabilities found in XMLdocument type definitions (DTDs) for specifying datatypes on elementsand attributes.

Status of this Document

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

This W3C Recommendation 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.

Changes since the previous public Working Draft include the following:

For those primarily interested in the changes since version 1.0, the appendixChanges since version 1.0 (§I) 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 product. Instructions can be found athttp://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list,www-xml-schema-comments@w3.org (archive) 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 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 a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

Animplementation report for XSD 1.1 was prepared and used in the Director's decision to publish the previous version of this specification as a Proposed Recommendation. The Director's decision to publish this document as a W3C Recommendation is based on consideration of reviews of the Proposed Recommendation by the public and by the members of the W3C 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 produced by theW3C XML Schema Working Group as part of the W3CXML Activity. The goals of the XML Schema language version 1.1 are discussed in theRequirements for XML Schema 1.1 document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced by a group operating under the5 February 2004 W3C Patent Policy. W3C maintains apublic list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes containsEssential Claim(s) must disclose the information in accordance withsection 6 of the W3C Patent Policy.

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

Table of Contents

1Introduction
    1.1Introduction to Version 1.1
    1.2Purpose
    1.3Dependencies on Other Specifications
    1.4Requirements
    1.5Scope
    1.6Terminology
    1.7Constraints and Contributions
2Datatype System
    2.1Datatype
    2.2Value space
Identity ·Equality ·Order
    2.3The Lexical Space and Lexical Mapping
Canonical Mapping
    2.4DatatypeDistinctions
Atomic vs. List vs. Union Datatypes ·Special vs. Primitive vs.OrdinaryDatatypes ·Definition, Derivation, Restriction, and Construction ·Built-in vs. User-Defined Datatypes
3Built-in Datatypes and Their Definitions
    3.1Namespace considerations
    3.2Special Built-in Datatypes
anySimpleType ·anyAtomicType
    3.3Primitive Datatypes
string ·boolean ·decimal ·float ·double ·duration ·dateTime ·time ·date ·gYearMonth ·gYear ·gMonthDay ·gDay ·gMonth ·hexBinary ·base64Binary ·anyURI ·QName ·NOTATION
    3.4Other Built-in Datatypes
normalizedString ·token ·language ·NMTOKEN ·NMTOKENS ·Name ·NCName ·ID ·IDREF ·IDREFS ·ENTITY ·ENTITIES ·integer ·nonPositiveInteger ·negativeInteger ·long ·int ·short ·byte ·nonNegativeInteger ·unsignedLong ·unsignedInt ·unsignedShort ·unsignedByte ·positiveInteger ·yearMonthDuration ·dayTimeDuration ·dateTimeStamp
4Datatype components
    4.1Simple Type Definition
The Simple Type Definition Schema Component ·XML Representation of Simple Type Definition Schema Components ·Constraints on XML Representation of Simple Type Definition ·Simple Type Definition Validation Rules ·Constraints on Simple Type Definition Schema Components ·Built-in Simple Type Definitions
    4.2Fundamental Facets
ordered ·bounded ·cardinality ·numeric
    4.3Constraining Facets
length ·minLength ·maxLength ·pattern ·enumeration ·whiteSpace ·maxInclusive ·maxExclusive ·minExclusive ·minInclusive ·totalDigits ·fractionDigits ·Assertions ·explicitTimezone
5Conformance
    5.1Host Languages
    5.2Independent implementations
    5.3Conformance of data
    5.4Partial Implementation of Infinite Datatypes

Appendices

ASchema for Schema Documents (Datatypes) (normative)
BDTD for Datatype Definitions (non-normative)
CIllustrative XML representations for the built-in simple type definitions
    C.1Illustrative XML representations for the built-in primitive type definitions
    C.2Illustrative XML representations for the built-in ordinary type definitions
DBuilt-up Value Spaces
    D.1Numerical Values
Exact Lexical Mappings
    D.2Date/time Values
The Seven-property Model ·Lexical Mappings
EFunctionDefinitions
    E.1Generic Number-related Functions
    E.2Duration-related Definitions
    E.3Date/time-related Definitions
Normalization of property values ·Auxiliary Functions ·Adding durations to dateTimes ·Time on timeline ·Lexical mappings ·Canonical Mappings
    E.4Lexical and Canonical Mappings for Other Datatypes
Lexical and canonical mappings for
FDatatypes and Facets
    F.1Fundamental Facets
GRegular Expressions
    G.1Regular expressions and branches
    G.2Pieces, atoms, quantifiers
    G.3Characters and metacharacters
    G.4Character Classes
Character class expressions ·Character Class Escapes
HImplementation-defined and implementation-dependent features (normative)
    H.1Implementation-defined features
    H.2Implementation-dependent features
IChanges since version 1.0
    I.1Datatypes and Facets
    I.2Numerical Datatypes
    I.3Date/time Datatypes
    I.4Other changes
JGlossary (non-normative)
KReferences
    K.1Normative
    K.2Non-normative
LAcknowledgements (non-normative)

1 Introduction

next sub-section1.1 Introduction to Version 1.1

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

  • Significant improvements in simplicity of design and clarityof expositionwithout loss of backwardorforward compatibility;
  • Provision of support for versioning of XML languages definedusing the XML Schema specification, including the XML transfer syntaxfor schemas itself.

These goals are slightly in tension with one another -- thefollowing summarizes the Working Group's strategic guidelines forchanges between versions 1.0 and 1.1:

  1. Add support for versioning (acknowledging that thismay be slightly disruptive to the XML transfer syntax atthe margins)
  2. Allow bug fixes (unless in specific cases we decide that thefix is too disruptive for a point release)
  3. Allow editorial changes
  4. Allow design cleanup to change behavior in edgecases
  5. Allow relatively non-disruptive changes to type hierarchy (tobetter support current and forthcoming international standards and W3Crecommendations)
  6. Allow design cleanup to change component structure (changesto functionality restricted to edge cases)
  7. Do not allow any significant changes in functionality
  8. Do not allow any changes to XML transfer syntax except thoserequired by version control hooks and bug fixes

The overall aim as regards compatibility is that

  • All schema documents conformant to version 1.0 of thisspecification should also conform to version 1.1, and should have thesame validation behavior across 1.0 and 1.1 implementations (exceptpossibly in edge cases and in the details of the resultingPSVI);
  • The vast majority of schema documents conformant to version1.1 of this specification should also conform to version 1.0, leavingaside any incompatibilities arising from support for versioning, andwhen they are conformant to version 1.0 (or are made conformant by theremoval of versioning information), should have the same validationbehavior across 1.0 and 1.1 implementations (again except possibly inedge cases and in the details of the resulting PSVI);

previous sub-sectionnext sub-section1.2 Purpose

The[XML] specification defines limitedfacilities for applying datatypes to document content in that documentsmay contain or refer to DTDs that assign types to elements and attributes.However, document authors, including authors of traditionaldocuments and those transportingdata in XML,often require a higher degree of type checking to ensure robustness indocument understanding and data interchange.

The table below offers two typical examples of XML instancesin which datatypes are implicit: the instance on the leftrepresents a billing invoice, the instance on theright a memo or perhaps an email message in XML.

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

The invoice contains several dates and telephone numbers, the postalabbreviation for a state (which comes from an enumerated list ofsanctioned values), and a ZIP code (which takes a definable regularform).  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 exceptionsif something that was supposed to be a date or telephone number doesnot conform to the rules for valid dates or telephone numbers.

In both cases, validity constraints exist on the content of theinstances that are not expressible in XML DTDs.  The limiteddatatyping facilities in XML have prevented validating XML processorsfrom supplying the rigorous type checking required in thesesituations.  The result has been that individual applicationswriters have had to implement type checking in an ad hoc manner. This specification addresses the need of both document authors andapplications writers for a robust, extensible datatype system for XMLwhich could be incorporated into XML processors.  As discussedbelow, these datatypes could be used in other XML-related standards aswell.

previous sub-sectionnext sub-section1.3 Dependencies on Other Specifications

Other specifications on which this one dependsare listed inReferences (§K).

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

Conforming implementations of this specification may provide eitherthe 1.1-based datatypes or the 1.0-based datatypes, or both. If bothare supported, the choice of which datatypes to use in a particularassessment episodeshould be under user control.

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

This specificationmakes use of the EBNF notation used in the[XML] specification. Notethat some constructs of the EBNF notation used hereresemble the regular-expression syntax defined in this specification(Regular Expressions (§G)), but that they are notidentical: there are differences. For a fuller description of the EBNF notation, seeSection6. Notation of the[XML] specification.

previous sub-sectionnext sub-section1.4 Requirements

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

  1. provide for primitive data typing, including byte, date,integer, sequence, SQL and Java primitive datatypes, etc.;
  2. define a type system that is adequate for import/exportfrom database systems (e.g., relational, object, OLAP);
  3. distinguish requirements relating to lexical data representationvs. those governing an underlying information set;
  4. allow creation of user-defined datatypes, such asdatatypes that are derived from existing datatypes and whichmay constrain certain of its properties (e.g., range,precision, length, format).

previous sub-sectionnext sub-section1.5 Scope

This specificationdefines datatypes that can be used in an XML Schema. These datatypes can be specified for element content that would bespecified as#PCDATAand attribute values ofvarious types in aDTD.  It is the intention of this specification that it be usableoutside of the context of XML Schemas for a wide range of otherXML-related activities such as[XSL] and[RDF Schema].

previous sub-sectionnext sub-section1.6 Terminology

The terminology used to describe XML Schema Datatypes is defined inthe body of this specification. The terms defined in the followinglist are used in building those definitions and in describing theactions of a datatype processor:

[Definition:]  for compatibility
A feature of this specification included solely to ensure thatschemas which use this feature remain compatible with[XML].
(Of strings or names:) Two strings or names being compared must beidentical. Characters with multiple possible representations inISO/IEC 10646 (e.g. characters with both precomposed andbase+diacritic forms) match only if they have the same representationin both strings. No case folding is performed.
(Of strings and rules in the grammar:) A string matches a grammatical production if and only if it belongs to the languagegenerated by that production.
Schemas, schema documents, and processorsare permitted to but neednot behave as described.
It is recommended that schemas, schema documents, andprocessors behave as described, but therecan be valid reasons for them not to; it is important that thefull implications be understood and carefully weighed beforeadopting behavior at variance with the recommendation.
(Of schemas and schema documents:) Schemas and documentsare required to behave as described; otherwise they are in·error·.
(Of processors:)Processors are required to behave as described.
Schemas, schema documentsand processors are forbidden to behave asdescribed; schemas and documents which neverthelessdo so are in·error·.
A failure of a schema or schema document to conform to the rules of this specification.
Except as otherwise specified, processorsmust distinguisherror-free (conforming) schemas and schema documentsfrom those with errors;if a schema used in type-validation or a schema document used in constructing a schema is in error, processorsmust report the fact; if more than one is in error, it is·implementation-dependent· whether more than one is reported as being in error. If more than one of the constraints given in this specification is violated, it is·implementation-dependent· how many of the violations, and which, are reported.
Note: Failure of an XML element or attribute to be datatype-valid against a particular datatype in a particular schema is not in itself a failure to conform to this specification and thus, for purposes of this specification, not an error.
A choice left under the control of the user of a processor,rather than being fixed for all users or uses of the processor.
Statements in this specification that "Processorsmay at user option" behave in a certain way mean thatprocessorsmay provide mechanisms to allow users(i.e. invokers of the processor) to enable or disable thebehavior indicated. Processors which do not provide suchuser-operable controlsmust not behave in the way indicated.Processors which do provide such user-operable controlsmust make it possible for the user to disable the optional behavior.
Note: The normal expectation is that the default setting for such options will be to disable the optional behavior in question, enabling it only when the user explicitly requests it. This is not, however, a requirement of conformance: if the processor's documentation makes clear that the user can disable the optional behavior, then invoking the processor without requesting that it be disabled can be taken as equivalent to a request that it be enabled. It is required, however, that it in fact be possible for the user to disable the optional behavior.
Note: Nothing in this specification constrains the manner in which processors allow users to control user options. Command-line options, menu choices in a graphical user interface, environment variables, alternative call patterns in an application programming interface, and other mechanisms may all be taken as providing user options.

previous sub-section1.7 Constraints and Contributions

This specification provides three different kinds of normativestatements about schema components, their representations in XML andtheir contribution to the schema-validation of information items:

[Definition:]  Constraint on Schemas
Constraints on the schema components themselves, i.e. conditionscomponentsmust satisfy to be components at all.Largely to be found inDatatype components (§4).
[Definition:]  Schema Representation Constraint
Constraints on the representation of schema components in XML. Some but not all of these are expressed inSchema for Schema Documents (Datatypes) (normative) (§A) andDTD for Datatype Definitions (non-normative) (§B).
[Definition:]  Validation Rule
Constraints expressed by schema components which information itemsmust satisfy to be schema-valid.  Largely tobe found inDatatype components (§4).

2 Datatype System

This section describes the conceptual framework behind the datatype system defined in thisspecification.  The framework has been influenced by the[ISO 11404] standard on language-independent datatypes aswell as the datatypes for[SQL] and for programminglanguages such as Java.

The datatypes discussed in this specification are for the most part well known abstractconcepts such asinteger anddate. It is notthe place of this specification to thoroughly define these abstract concepts; manyother publications provide excellent definitions. However, this specification will attempt to describe theabstract concepts well enough that they can be readily recognized anddistinguished from other abstractions with which they may beconfused.

Note: Only those operations and relations needed for schema processingare defined in this specification. Applications using these datatypesare generally expected to implement appropriate additional functionsand/or relations to make the datatype generally useful.  Forexample, the description herein of thefloat datatypedoes not define addition or multiplication, much less all of theoperations defined for that datatype in[IEEE 754-2008] onwhich it is based. For some datatypes (e.g.language oranyURI) defined in part byreference to other specifications which impose constraints not part ofthe datatypes as defined here, applications may also wish to checkthat values conform to the requirements given in the current versionof the relevant external specification.

next sub-section2.1 Datatype

[Definition:]  Inthis specification, adatatype hasthree properties:
Note: This specification only defines the operations and relations neededfor schema processing.  The choice of terminology fordescribing/naming the datatypes is selected to guide users andimplementers in how to expand the datatype to be generallyuseful—i.e., how to recognize the "real world"datatypes and their variants for which the datatypes defined hereinare meant to be used for data interchange.

Along with the·lexical mapping· it isoften useful to have an inverse which provides a standard·lexical representation· for each value.  Sucha·canonical mapping· is not required forschema processing, but is described herein for the benefit of users ofthis specification, and other specifications which might find ituseful to reference these descriptions normatively.For some datatypes, notablyQName andNOTATION, the mapping fromlexical representations to values is context-dependent; for thesetypes, no·canonical mapping· is defined.

Note: Where·canonical mappings· are defined in this specification, they aredefined for·primitive· datatypes. When a datatype is derived using facets which directlyconstrain the·value space·, then for each value eliminated from the·value space·, the corresponding lexical representations are droppedfrom the lexical space. The·canonical mapping· for such a datatype isa subset of the·canonical mapping· for its·primitive· type andprovides a·canonical representation· for each value remaining in the·value space·.
The·pattern·facet, on the other hand, andany other (·implementation-defined·)·lexical· facets,restrictthe·lexical space· directly. When more than one lexicalrepresentation is provided for a given value, such facetsmay remove the·canonical representation· whilepermitting a different lexical representation; in this case, the valueremains in the·value space· but has no·canonical representation·.This specification provides no recourse in such situations.Applications are free to deal with it as they see fit.
Note: This specification sometimes uses the shorter form "type"where one might strictly speaking expect the longer form"datatype" (e.g. in the phrases "union type", "list type", "base type", "item type", etc.No systematic distinction is intended betweenthe forms of these phrase with "type" andthose with "datatype";the two forms are used interchangeably.
The distinction between "datatype"and "simple type definition", by contrast,carries more information: the datatype is characterized by its·value space·,·lexical space·,·lexical mapping·, etc., asjust described, independently of the specific facets orother definitional mechanisms used in the simple type definition to describe that particular·value space·or·lexical space·. Different simple type definitionswith different selections of facets can describe thesame datatype.

previous sub-sectionnext sub-section2.2 Value space

        2.2.1Identity
        2.2.2Equality
        2.2.3Order

[Definition:]  Thevalue spaceof adatatype is the set of values for thatdatatype.  Associated with each value space areselected operations and relations necessary to permit proper schemaprocessing.  Each value in the value space of a·primitive· or·ordinary·datatype isdenoted by one or more character strings in its·lexical space·,according to·the lexicalmapping·;·special·datatypes, by contrast, may include "ineffable"values not mapped to by any lexical representation. (If the mapping is restricted during aderivation in such a way that a value has no denotation, that value isdropped from the value space.)

The value spaces of datatypes are abstractions,and are defined inBuilt-in Datatypes and Their Definitions (§3) to the extent needed to clarify them for readers.  For example,in defining the numerical datatypes, we assume some general numericalconcepts such as number and integer are known.  In many cases weprovide references to other documents providing more completedefinitions.

Note:The value spaces and the values therein areabstractions.  This specification does not prescribe anyparticular internal representations that must be used whenimplementing these datatypes.  In some cases, there arereferences to other specifications which do prescribe specificinternal representations; these specific internal representations mustbe used to comply with those other specifications, but need not beused to comply with this specification.
In addition, other applications are expected to define additionalappropriate operations and/or relations on these value spaces (e.g.,addition and multiplication on the various numerical datatypes'value spaces), and are permitted where appropriate to even redefinethe operations and relations defined within this specification,provided thatfor schema processing the relations and operationsused are those defined herein.
The·value space· of a datatype canbe defined in one of the following ways:
  • defined elsewhereaxiomatically from fundamental notions (intensional definition) [see·primitive·]
  • enumerated outright from valuesof an already defined datatype (extensional definition) [see·enumeration·]
  • defined by restricting the·value space· of an alreadydefined datatype to a particular subset with a given set of properties[see·derived·]
  • defined as a combination of values from one or more alreadydefined·value space·(s) by a specific construction procedure [see·list· and·union·]

The relations ofidentityandequality are required for eachvalue space. An order relation is specified for some value spaces, but not all.A very few datatypes have other relations oroperations prescribed for the purposes of this specification.

2.2.1 Identity

The identity relation is always defined. Every value spaceinherently has an identity relation. Two things areidentical if and onlyif they are actually the same thing: i.e., if there is no waywhatever to tell them apart. 

Note: This does not preclude implementing datatypes by using more thanoneinternal representation for a given value, providedno mechanism inherent in the datatype implementation (i.e., other thanbit-string-preserving "casting" of the datum to a differentdatatype) will distinguish between the two representations.

In the identity relation defined herein, values from different·primitive· datatypes'·value spaces· are made artificiallydistinct if they might otherwise be considered identical.  Forexample, there is a numbertwo in thedecimal datatype and a numbertwo in thefloat datatype.  In the identity relation defined herein,these two values are considered distinct.  Other applicationsmaking use of these datatypes may choose to consider values such asthese identical, but for the view of·primitive· datatypes'·value spaces· used herein, they are distinct.

WARNING:  Care must be taken when identifyingvalues across distinct primitive datatypes.  The·literals· '0.1' and '0.10000000009' mapto the same value infloat (neither 0.1 nor 0.10000000009 is in the value space, andeach literal is mapped to thenearest value, namely 0.100000001490116119384765625), but map todistinct values indecimal.

Note: Datatypes·constructed· by·facet-based restriction· do not create newvalues; they define subsets of some·primitive· datatype's·value space·. A consequence of this fact is that the·literals·'+2', treated as adecimal,'+2', treated as aninteger, and'+2', treated as abyte, all denote thesame value. They are not only equal but identical.

Given a listA and a listB,A andBare the same list if they are the same sequence of atomic values.The necessary and sufficient conditions for this identity arethatA andB have the same length and that the items ofAare pairwise identical to the items ofB.

Note: It is a consequence of the rule just given for list identitythat there is only one empty list. An empty list declared ashaving·item type·decimal and an emptylist declared as having·item type·string are not only equal but identical.

2.2.2 Equality

Each·primitive· datatype has prescribed an equality relation forits value space.  The equality relation for most datatypes is theidentity relation.  In the few cases where it is not, equality has been carefully defined so that formost operations ofinterest to the datatype, iftwo values are equal and one is substituted for the other as anargument to any of the operations, the results will always also beequal.

On the other hand, equality need not cover the entire value spaceof the datatype (though it usually does). In particular, NaNis not equal to itself in thefloat anddouble datatypes.

Thisequality relation is used inconjunction with identity whenmaking·facet-based restrictions· byenumeration, when checking identity constraints (in the context of[XSD 1.1 Part 1: Structures])and when checking value constraints. It is used in conjunction with order when making·facet-based restrictions· involving order. The equality relation used in the evaluation of XPath expressionsmay differ.  WhenprocessingXPath expressions as part of XML schema-validityassessment orotherwise testing membership in the·value space·of a datatype whose derivation involves·assertions·,equality (like all other relations) within those expressions is interpretedusing the rules of XPath ([XPath 2.0]).  All comparisons for"sameness" prescribed by this specificationtest for either equality or identity, not for identity alone.

Note: In the prior version of this specification (1.0), equality wasalways identity.  This has been changed to permit the datatypesdefined herein to more closely match the "real world"datatypes for which they are intended to be used as transmissionformats.
For example, thefloat datatype has an equalitywhich is not the identity ( −0 = +0 , butthey are not identical—although theywere identicalin the 1.0 version of this specification), and whose domain excludesone value, NaN, so that  NaN ≠ NaN .
For another example, thedateTime datatypepreviously lost any time-zone offset information in the·lexical representation· as the value was converted to·UTC·;now the time zone offsetis retained and two values representing the same "moment intime" but with different remembered time zone offsets are nowequal but notidentical.

In the equality relation defined herein, values from differentprimitive data spaces are made artificially unequal even if they mightotherwise be considered equal.  For example, there is a numbertwo in thedecimal datatype and a numbertwo in thefloat datatype.  In theequality relation defined herein, these two values are consideredunequal.  Other applications making use of these datatypes maychoose to consider values such as these equal;nonetheless, in the equality relation defined herein, they are unequal.

Two listsA andB are equal if andonly if they have the same length and their items are pairwise equal.A list of length one containing a valueV1 and an atomic valueV2 are equal if and only ifV1 is equal toV2.

For the purposes of this specification, there is one equalityrelation for all values of all datatypes (the union of the variousdatatype's individual equalities, if one consider relations to besets of ordered pairs).  Theequality relation isdenoted by '=' and its negation by'≠', each used asa binary infix predicate: x = y  and x ≠ y .  On the otherhand,identity relationships are always described inwords.

2.2.3 Order

For some datatypes, an order relation is prescribed for use in checkingupper and lower bounds of the·value space·.  This order may beapartial order, which means that there may be values inthe·value space· which are neither equal, less-than, norgreater-than.  Such value pairs areincomparable.  In many cases, no orderis prescribed; each pair of values is eitherequal or·incomparable·.[Definition:]  Twovalues that are neither equal, less-than, nor greater-than areincomparable. Two valuesthat are not·incomparable· arecomparable.

The order relation is usedin conjunction with equality when making·facet-based restrictions·involving order.  This is the only use ofthisorder relation for schemaprocessing.  Of course, whenprocessingXPath expressions as part of XML schema-validityassessment orotherwise testing membership in the·value space·of a datatype whose derivation involves·assertions·,order (like all other relations) within those expressions is interpretedusing the rules of XPath ([XPath 2.0]).

In this specification, this less-than order relation is denoted by'<' (and its inverse by '>'),the weak order by '≤' (and its inverse by'≥'), and the resulting·incomparable· relation by'<>', each used as a binary infix predicate: x < y , x ≤ y , x > y , x ≥ y , and x <> y .

Note: The weak order "less-than-or-equal" means"less-than" or "equal"and onecan tell which.  For example, theduration P1M (one month) isnotless-than-or-equal P31D (thirty-one days) because P1M is not less thanP31D, nor is P1M equal to P31D.  Instead, P1M is·incomparable· with P31D.)  The formaldefinition of order forduration (duration (§3.3.6)) ensures that this is true.

Forpurposes of this specification, the value spaces of primitive datatypes aredisjoint, even in cases where theabstractions they represent might be thought of as having values in common.  In the order relations defined in this specification, values fromdifferent value spaces are·incomparable·.  For example, the numbers twoand three are values in both thedecimaldatatype and the float datatype.  In the order relation definedhere,the two in the decimal datatypeisnot less than the three in the float datatype;the two values areincomparable.  Otherapplications making use of thesedatatypes may choose to consider values such as these comparable.

Note: Comparison of values from different·primitive· datatypescan sometimes be an error and sometimes not, depending on context.
When made for purposes of checking an enumeration constraint,such a comparison is not in itself an error, but sincenotwo values from different·primitive··value spaces· are equal, any comparison of·incomparable· values will invariably be false.
Specifying an upper or lower bound which is of the wrong primitivedatatype (and therefore·incomparable· with the values of the datatypeit is supposed to restrict) is, by contrast, always an error.It is a consequence of the rules for·facet-based restriction· that in conforming simple type definitions, thevalues of upper and lower bounds, and enumerated values,must bedrawn from the value space of the·base type·, which necessarily meansfrom the same·primitive· datatype.
Comparison of·incomparable· values in the context of an XPathexpression (e.g. in an assertion or in the rules for conditional typeassignment) can raise a dynamic error in the evaluation of the XPathexpression; see[XQuery 1.0 and XPath 2.0 Functions and Operators] for details.

previous sub-sectionnext sub-section2.3 The Lexical Space and Lexical Mapping

[Definition:]  Thelexical mapping for a datatype is a prescribed relationwhich maps from the·lexical space· of the datatypeinto its·value space·.

[Definition:]  Thelexical space of a datatype is the prescribed set of stringswhich·the lexicalmapping· for that datatypemaps to values of that datatype.

[Definition:]  The members of the·lexical space· arelexical representations of the values to which they aremapped.

Note: For the·special· datatypes, the·lexical mappings· definedhere map from the·lexical space· into, but not onto, the·value space·.The·value spaces· of the·special· datatypesinclude "ineffable" values for which the·lexical mappings· definedin this specification provide no lexical representation.
For the·primitive· and·ordinary· atomic datatypes, the·lexical mapping· is a (total)function on the entire·lexical space·onto (not merelyinto) the·value space·: every member of the·lexical space· maps into the·value space·, and every value is mappedto by some member of the·lexical space·.
For·union· datatypes, the·lexical mapping·is not necessarily a function, since the same·literal· may map todifferent values in different member types. For·list· datatypes,the·lexical mapping· is a function if and only if the·lexical mapping·of the list's·item type· is a function.

[Definition:]  A sequence of zero or morecharacters in the Universal Character Set (UCS) which may or may notprove upon inspection to be a member of the·lexical space· of a givendatatype and thus a·lexical representation· of a given value in that datatype's·value space·, is referred to as aliteral. Theterm is used indifferently both for character sequences which aremembers of a particular·lexical space· and for those which arenot.

If a derivation introduces a·pre-lexical· facet value (a new value forwhiteSpace or an implementation-defined·pre-lexical· facet), the corresponding·pre-lexical· transformation of a character string,if indeed it changed that string, could prevent that string from everhaving the·lexical mapping· of the derived datatypeapplied to it.  Character strings that a·pre-lexical· transformation blocks in this way(i.e., they are not in the range of the·pre-lexical·facet's transformation) are always dropped from the derived datatype's·lexical space·.

Note: One should be aware that in the context of XMLschema-validityassessment,there are·pre-lexical· transformations of theinput character string (controlled by thewhiteSpace facet and any implementation-defined·pre-lexical·facets)which result in the intended·literal·. Systems other thanXML schema-validityassessmentutilizing this specification may or may not implement thesetransformations.  If they do not, then input character stringsthat would have been transformed into correct·lexical representations·,when taken "raw", may not becorrect·lexicalrepresentations·.

Should a derivation be made using a derivation mechanism thatremoves·lexical representations· from the·lexical space· to theextent that one or more values cease to have any·lexical representation·, then those values are dropped from the·value space·.

Note: This could happen by means of apatternor other·lexical·facet, or by a·pre-lexical· facet as described above.

Conversely, should a derivation remove values then their·lexical representations· are dropped from the·lexical space· unlessthere is a facet value whose impact is defined to cause theotherwise-dropped·lexical representation· to be mapped to anothervalue instead.

Note: There are currently no facets with such an impact.  There maybe in the future.

For example, '100' and '1.0E2' are twodifferent·lexical representations· from thefloatdatatype whichboth denote the same value.  The datatype system defined in thisspecification provides mechanisms for schema designers to control the·value space· and the corresponding set of acceptable·lexical representations· of those values for a datatype.

2.3.1 Canonical Mapping

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

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

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

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

Note:·Canonicalrepresentations· are provided where feasible for the use ofother applications; they are not required for schema processingitself. A conforming schema processor implementation isnot required to implement·canonicalmappings·.

previous sub-section2.4 DatatypeDistinctions

        2.4.1Atomic vs. List vs. Union Datatypes
            2.4.1.1Atomic Datatypes
            2.4.1.2List Datatypes
            2.4.1.3Union datatypes
        2.4.2Special vs. Primitive vs.OrdinaryDatatypes
            2.4.2.1Facet-based Restriction
            2.4.2.2Construction by List
            2.4.2.3Construction by Union
        2.4.3Definition, Derivation, Restriction, and Construction
        2.4.4Built-in vs. User-Defined Datatypes

It is useful to categorize the datatypes defined in thisspecification along various dimensions, defining terms whichcan be used to characterize datatypes and theSimple Type Definitionswhich define them.

2.4.1 Atomic vs. List vs. Union Datatypes

First, we distinguish·atomic·,·list·, and·union· datatypes.

[Definition:]  Anatomic value is an elementary value, notconstructed from simpler values by any user-accessiblemeans defined by this specification.

For example, a single token which·matches·Nmtoken from[XML] is in the valuespace of the·atomic· datatypeNMTOKEN, while a sequence of such tokens is in the value space of the·list·datatypeNMTOKENS.

2.4.1.1 Atomic Datatypes

An·atomic· datatype has a·value space·consisting of a set of "atomic" or elementary values.

Note: Atomic values are sometimes regarded, and described, as "notdecomposable", but in fact the values in several datatypesdefined here are described with internal structure, which is appealedto in checking whether particular values satisfy various constraints(e.g. upper and lower bounds on a datatype). Other specificationswhich use the datatypes defined here may define operations whichattribute internal structure to values and expose or act upon thatstructure.

The·lexical space· of an·atomic· datatype is a set of·literals·whose internal structure is specific to the datatype inquestion.

There is one·special··atomic· datatype(anyAtomicType), and a number of·primitive··atomic·datatypes which haveanyAtomicType as their·base type·.  All other·atomic· datatypes are·derived· eitherfrom one of the·primitive··atomic· datatypes or from another·ordinary··atomic· datatype.  No·user-defined· datatypemay haveanyAtomicType as its·base type·.

2.4.1.2 List Datatypes

·List· datatypes are always·constructed· from some other type; they are never·primitive·. The·value space· of a·list· datatype isthe set of finite-length sequences ofzero or more·atomic·valueswhere each·atomic· value is drawn from the·value space· of the lists's·item type·and has a·lexical representation· containing nowhitespace. The·lexical space· of a·list· datatype is a set of·literals· eachof which is a space-separated sequence of·literals·of the·item type·.

[Definition:]  The·atomic· or·union·datatype that participates in the definition of a·list· datatypeis theitem type of that·list· datatype.  If the·item type· is a·union·, each of its·basic members·must be·atomic·.

Example
<simpleType name='sizes'>  <list itemType='decimal'/></simpleType>
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>

A·list· datatype can be·constructed·from an ordinary or·primitive··atomic· datatype whose·lexical space· allowswhitespace(such asstring oranyURI) 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 occurin the·lexical representation·of a·list· item, even when the itemtype would in principle allow it.  For the same reason, when every possible·lexical representation· of a givenvalue in the·value space· of the·item type·includes whitespace,that value can never occur as an item in any value of the·list· datatype.

Example
<simpleType name='listOfString'>  <list itemType='string'/></simpleType>
<someElement xsi:type='listOfString'>this is not list item 1this is not list item 2this is not list item 3</someElement>
In the above example, the value of thesomeElement elementis not a·list· of·length· 3;rather, it is a·list· of·length·18.

For each of·length·,·maxLength·and·minLength·, thelength ismeasured in number of list items.  The value of·whiteSpace·is fixed to the valuecollapse.

For·list· datatypes the·lexical space·is composed of space-separated·literals·of the·item type·.  Any·pattern· specified when a new datatype is·derived· from a·list· datatype appliesto the members of the·list· datatype's·lexical space·, not to the members of the·lexical space·of the·item type·.  Similarly, enumeratedvalues are compared to the entire·list·, not toindividual list items,andassertions apply to the entire·list· too.Lists are identical if and only if they have thesame length and their items are pairwise identical; they areequal if and only if they have the same length and their itemsare pairwise equal. And a list of length one whose item is an atomic valueV1 isequal or identical to an atomic valueV2 if and only ifV1 is equal or identical toV2.

Example
<xs:simpleType name='myList'><xs:list itemType='xs:integer'/></xs:simpleType><xs:simpleType name='myRestrictedList'><xs:restriction base='myList'><xs:pattern value='123 (\d+\s)*456'/></xs:restriction></xs:simpleType><someElement xsi:type='myRestrictedList'>123 456</someElement><someElement xsi:type='myRestrictedList'>123 987 456</someElement><someElement xsi:type='myRestrictedList'>123 987 567 456</someElement>

The·canonical mapping· of a·list· datatype maps each value onto the space-separated concatenation of the·canonical representations· of all the items in the value(in order), using the·canonical mapping· of the·item type·.

2.4.1.3 Union datatypes

Union typesmay 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, sodefined, is not necessarily a function: a given·literal· may map toone value or to several values of different·primitive· datatypes, andit may be indeterminate which value is to be preferred in a particularcontext. When the datatypes defined here are used in the context of[XSD 1.1 Part 1: Structures], thexsi:type attribute defined by thatspecification in sectionxsi:type can be used to indicatewhich value a·literal· which is the content of an element should mapto. In other contexts, other rules (such as type coercion rules) maybe 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 otherdatatypes; they are never·primitive·. Currently,there are no·built-in· ·union· datatypes.

Example
A prototypical example of a·union· type is themaxOccurs attribute on theelement elementin XML Schema itself: it is a union of nonNegativeIntegerand an enumeration with the single member, the string "unbounded", as shown below.
  <attributeGroup name="occurs">    <attribute name="minOccurs" type="nonNegativeInteger"    use="optional" default="1"/>    <attribute name="maxOccurs"use="optional" default="1">      <simpleType>        <union>          <simpleType>            <restriction base='nonNegativeInteger'/>          </simpleType>          <simpleType>            <restriction base='string'>              <enumeration value='unbounded'/>            </restriction>          </simpleType>        </union>      </simpleType>    </attribute>  </attributeGroup>

Any number (zero or more) of ordinary or·primitive··datatypes·can participate in a·union· type.

[Definition:]  The datatypes that participate in thedefinition of a·union· datatype are known as themember types of that·union· datatype.

Note: When datatypes are represented using XSD schema components, asdescribed inDatatype components (§4), the member types ofa union are those simple type definitions given in the{member type definitions} property.

[Definition:]  Thetransitive membership ofa·union· is the set of its own·member types·, and the·member types·of its members, and so on. More formally, ifU is a·union·, then (a) its·member types· are in the transitive membershipofU, and (b) for any datatypesT1 andT2, ifT1 is in the transitive membership ofU andT2 is one of the·member types· ofT1, thenT2 is also in the transitive membershipofU.

The·transitive membership·of a·union·must not contain the·union· itself, norany datatype·derived· or·constructed· from the·union·.

[Definition:]  Those members of the·transitive membership·of a·union· datatypeU which are themselves not·union·datatypesare thebasic members ofU.

[Definition:]  If a datatypeM is in the·transitive membership· of a·union·datatypeU, but not one ofU's·member types·,then a sequence of one or more·union· datatypes necessarily exists,such that the first is one of the·member types· ofU, eachis one of the·member types· of its predecessor in the sequence, andM is one of the·member types· of the last in the sequence.The·union· datatypes in this sequence are said tointervene betweenM andU. WhenU andM are given by the context, the datatypesin the sequence are referred to as theintervening unions.WhenM is one of the·member types· ofU,the set ofintervening unions is the empty set.

[Definition:]  In a validinstance of any·union·, the first of its members in order whichaccepts the instance as valid is theactive membertype.[Definition:]  If the·active member type· isitself a·union·, one ofits members will beits·active member type·, and so on, untilfinally a·basic (non-union)member· is reached. That·basic member· istheactive basic member of the union.

The order in which the·member types· are specified in thedefinition (that is, in the case ofdatatypes defined in a schema document, the order of the<simpleType> children of the <union> element, or the orderof theQNames in thememberTypes attribute) issignificant. During validation, an element or attribute's value isvalidated against the·member types· in the order in which they appearin the definition until a match is found.  As noted above,the evaluation order can be overridden with the use ofxsi:type.

Example
For example, given the definition below, the first instance of the <size> elementvalidates correctly as aninteger (§3.4.13), the second and third asstring (§3.3.1).
  <xs:element name='size'>    <xs:simpleType>      <xs:union>        <xs:simpleType>          <xs:restriction base='integer'/>        </xs:simpleType>        <xs:simpleType>          <xs:restriction base='string'/>        </xs:simpleType>      </xs:union>    </xs:simpleType>  </xs:element>
  <size>1</size>  <size>large</size>  <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.

2.4.2 Special vs. Primitive vs.OrdinaryDatatypes

Next, we distinguish·special·,·primitive·, and·ordinary· (or·constructed·) datatypes. Eachdatatype defined by or in accordancewith this specification falls into exactly one of thesecategories.

For example, in this specification,float is a·primitive· datatype based on a well-defined mathematical conceptandnot defined in terms of other datatypes, whileinteger is·constructed·from the more general datatypedecimal.

2.4.2.1 Facet-based Restriction

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

2.4.2.2 Construction by List

A·list· datatype can be·constructed·from another datatype (its·item type·) by creatinga·value space· that consists of finite-length sequencesof zero or more values of its·item type·.Datatypes so·constructed·haveanySimpleType 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· ofanySimpleType, any datatype·constructed· as a·list· is a·restriction· of its base type.

2.4.2.3 Construction by Union

One datatype can be·constructed· from one or more datatypesbyunioningtheir·lexical mappings·and, consequently, their·value spaces· and·lexical spaces·. Datatypes so·constructed·also haveanySimpleType 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· ofanySimpleType, any datatype·constructed· as a·union· is a·restriction· of its base type.

2.4.3 Definition, Derivation, Restriction, and Construction

Definition, derivation, restriction, and constructionare conceptually distinct, although in practicethey are frequently performed by the same mechanisms.

By 'definition' is meant the explicitidentification of the relevant properties of a datatype,in particular its·value space·,·lexical space·, and·lexical mapping·.

The properties of the·special· and thestandard·primitive· datatypes are defined by this specification. ASimple Type Definition is present for each of these datatypes in every valid schema; it serves as a representation of thedatatype, but by itself it does not capture all the relevant information and does not suffice (without knowledgeof this specification) todefine the datatype.

Note: The properties of any·implementation-defined··primitive·datatypes are given not here but in the documentation forthe implementation in question.Alternatively, a primitive datatypenot specified in this document can be specified in a documentof its own not tied to a particular implementation;[Precision Decimal] is an example of such a document.

For all other datatypes, aSimple Type Definition does suffice.The properties of an·ordinary· datatype can be inferredfrom the datatype'sSimple Type Definition and the properties ofthe·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 ofa datatype to its·base type·, or to the·base type· of its·base type·,and so on.

Every datatypeother thananySimpleTypeis associated with another datatype, itsbase type.Base types can be·special·,·primitive·, or·ordinary·.

[Definition:]  A datatypeT isimmediately derived from another datatypeX if and only ifX is the·base type· ofT.

Note: The above does not preclude theSimple Type DefinitionforanySimpleType from having a value forits{base type definition}. (It does, and its value isanyType.)
More generally,
A datatypeR isderived from another datatypeB if and only if one of the following is true:

A datatypemust not be·derived· from itself. That is, thebase type relation must be acyclic.

It is a consequence of the abovethat every datatype other thananySimpleType is·derived·fromanySimpleType.

Since each datatype has exactly one·base type·,and every datatype otherthananySimpleTypeis·derived· directly orindirectly fromanySimpleType, it follows thatthe·base type· relation arranges allsimple types into a tree structure, which is conventionallyreferred to as thederivation hierarchy.

By 'restriction' is meant the definitionof a datatype whose·value space· and·lexical space· are subsets of those of its·base type·.

Formally,A datatypeR is arestriction of another datatypeB when

Note that all three forms of datatype·construction· produce·restrictions· of the·base type·:·facet-based restriction· does so by means of·constraining facets·, while·construction· by·list· or·union· does so because those·constructions· takeanySimpleType as the·base type·. It follows that alldatatypes are·restrictions· ofanySimpleType.This specification provides no means by which a datatype may bedefined so as to have a larger·lexical space· or·value space· than its·base type·.

By 'construction' is meant the creation of adatatype by defining it in terms of another.

[Definition:]  All·ordinary· datatypes are defined in terms of, orconstructed from, other datatypes, either by·restricting· the·value space· or·lexical space· of a·base type· using zero or more·constraining facets·or by specifying the new datatype as a·list· of items of some·item type·,or by defining it as a·union· of some specified sequence of·member types·.These three forms of·construction·are often called "·facet-based restriction·","·construction· by·list·", and "·construction· by·union·", respectively.Datatypes so constructed may be understood fully (forpurposes of a type system) in terms of (a) the propertiesof the datatype(s) from which they are constructed, and(b) theirSimple Type Definition. This distinguishes·ordinary·datatypesfrom the·special· and·primitive· datatypes, which can be understood only in the light of documentation (namely, their descriptions elsewhere in this specification,or, for·implementation-defined··primitives·, in the appropriateimplementation-specific documentation).All·ordinary·datatypes are·constructed·, and all·constructed· datatypes are·ordinary·.

2.4.4 Built-in vs. User-Defined Datatypes

The·built-in· datatypes are intended to beavailable automatically whenever this specification is implemented orused, whether by itself or embedded in a host language. In thelanguage defined by[XSD 1.1 Part 1: Structures], the·built-in· datatypes are automaticallyincluded in every valid schema. Other host languagesshould specifythat all of the datatypes decribed here as built-ins are automaticallyavailable; theymay specify that additional datatypes are also madeavailable automatically.

Note:·Implementation-defined· datatypes, whether·primitive· or·ordinary·,may sometimesbe included automatically in any schemas processedby that implementation; nevertheless, they are not built intoevery schema, and are thus not includedin the term 'built-in', as that term isused in this specification.

The mechanism for making·user-defined·datatypes available for use is not defined in this specification; if·user-defined· datatypes are to be available, some such mechanismmust be specified by the host language.

[Definition:]  Adatatype which is not available for use is said to beunknown.

Note: From the schema author's perspective, a reference toa datatype which proves to be·unknown· might reflectany of the following causes, or others:
1An error has been made in giving the name of the datatype.
2The datatype is a·user-defined· datatype which has not been madeavailable using the means defined by the host language (e.g.because the appropriate schema document has not beenconsulted).
3The datatype is an·implementation-defined··primitive· datatype not supported by the implementation beingused.
4The datatype is an·implementation-defined··ordinary·datatype which is made automatically available by someimplementations, but not by the implementation beingused.
5The datatype is a·user-defined··ordinary· datatypewhose base type is·unknown·
From the point of view of the implementation, these casesare likely to be indistinguishable.
Note: In the terminology of[XSD 1.1 Part 1: Structures],the datatypes here called·unknown· are referred to asabsent.

Conceptually there is no difference between the·ordinary··built-in· datatypes included in this specification and the·user-defined·datatypes which will be created by individual schema designers.The·built-in··constructed· datatypesare those which are believed to be so common that if they were notdefined in this specification many schema designers would end upreinventing them.  Furthermore, including these·constructed· datatypes in this specification serves todemonstrate the mechanics and utility of the datatype generationfacilities of this specification.

3 Built-in Datatypes and Their Definitions

Built-in Datatype Hierarchy diagram

Diagram showing the derivation relations in the built-in type hierarchy. (Along description of the diagram is available separately.)

Each built-in datatype definedin this specification can be uniquely addressed via aURI Reference constructed as follows:
  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of the datatype
For example, to address theint datatype, the URI is:
  • http://www.w3.org/2001/XMLSchema#int
Additionally, each facet definition element can be uniquelyaddressed via a URI constructed as follows:
  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of the facet
For example, to address the maxInclusive facet, the URI is:
  • http://www.w3.org/2001/XMLSchema#maxInclusive
Additionally, each facet usage in a built-inSimple Type Definitioncan be uniquely addressed via a URI constructed as follows:
  1. the base URI is the URI of the XML Schema namespace
  2. the fragment identifier is the name of theSimple Type Definition, followedby a period ('.') followed by the name of the facet
For example, to address the usage of the maxInclusive facet inthe definition of int, the URI is:
  • http://www.w3.org/2001/XMLSchema#int.maxInclusive

next sub-section3.1 Namespace considerations

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

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

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

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

Each·user-defined· datatype may also be associated with atarget namespace.  If it is constructedfrom a schema document, then its namespace is typically thetarget namespace of that schema document. (SeeXML Representation ofSchemas in[XSD 1.1 Part 1: Structures].)

previous sub-sectionnext sub-section3.2 Special Built-in Datatypes

        3.2.1anySimpleType
            3.2.1.1Value space
            3.2.1.2Lexical mapping
            3.2.1.3Facets
        3.2.2anyAtomicType
            3.2.2.1Value space
            3.2.2.2Lexical mapping
            3.2.2.3Facets

The two datatypes at the root of the hierarchy of simpletypes areanySimpleType andanyAtomicType.

3.2.1 anySimpleType

The definition ofanySimpleType is a special·restriction· ofanyType. The·lexical space· ofanySimpleTypeis the set of all sequences of Unicodecharacters, and its·value space· includes all·atomic values·and all finite-length lists of zero or more·atomic values·.

For further details ofanySimpleTypeand its representation as aSimple Type Definition, seeBuilt-in Simple Type Definitions (§4.1.6).

3.2.1.1 Value space

The·value space· ofanySimpleTypeis the set of all·atomic values· and of all finite-lengthlists of zero or more·atomic values·.

Note: It is a consequence of this definition, together with thedefinition of the·lexical mapping· in the next section, that somevalues of this datatype have no·lexical representation· using the·lexical mappings· defined by this specification. That is, the"potential"·value space· and the "effable"or "nameable"·value space· diverge for this datatype.As far as this specification is concerned, there is no operationaldifference between the potential and effable·value spaces· and thedistinction is of mostly formal interest. Since some host languagesfor the type system defined here may allow means of constructionvalues other than mapping from a·lexical representation·, thedifference may have practical importance in some contexts. In thosecontexts, the term·value space· should unless otherwise qualified betaken to mean the potential·value space·.
3.2.1.2 Lexical mapping

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

It is·implementation-defined· whether animplementation of this specification supports theChar production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

The·lexical mapping· ofanySimpleType is the unionof the·lexical mappings· ofall·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 tobe preferred in a particular context. When the datatypes defined hereare used in the context of[XSD 1.1 Part 1: Structures], thexsi:type attribute defined by that specification in sectionxsi:type can be usedto indicate which value a·literal· which is the content of an elementshould map to. In other contexts, other rules (such as type coercionrules) may be employed to determine which value is to be used.

3.2.1.3 Facets

When a new datatype is defined by·facet-based restriction·,anySimpleTypemust not be usedas the·base type·.So no·constraining facets· aredirectly applicable toanySimpleType.

3.2.2 anyAtomicType

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

For further details ofanyAtomicTypeand its representation as aSimple Type Definition, seeBuilt-in Simple Type Definitions (§4.1.6).

3.2.2.1 Value space

The·value space· ofanyAtomicType is the union of the·value spaces· of all the·primitive· datatypes defined hereor supplied as·implementation-defined··primitives·.

3.2.2.2 Lexical mapping

The·lexical space· ofanyAtomicType is the set ofall finite-length sequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML]. This is equivalent to the union of the·lexical spaces· of all·primitive· datatypes.

It is·implementation-defined· whether animplementation of this specification supports theChar production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

The·lexical mapping· ofanyAtomicType is the unionof the·lexical mappings· ofall·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 tobe preferred in a particular context. When the datatypes defined hereare used in the context of[XSD 1.1 Part 1: Structures], thexsi:type attribute defined by that specification in sectionxsi:type can be usedto indicate which value a·literal· which is the content of an elementshould map to. In other contexts, other rules (such as type coercionrules) may be employed to determine which value is to be used.

3.2.2.3 Facets

When a new datatype is defined by·facet-based restriction·,anyAtomicTypemust not be usedas the·base type·.So no·constraining facets· aredirectly applicable toanyAtomicType.

previous sub-sectionnext sub-section3.3 Primitive Datatypes

        3.3.1string
            3.3.1.1Value Space
            3.3.1.2Lexical Mapping
            3.3.1.3Facets
            3.3.1.4Deriveddatatypes
        3.3.2boolean
            3.3.2.1Value Space
            3.3.2.2Lexical Mapping
            3.3.2.3Facets
        3.3.3decimal
            3.3.3.1LexicalMapping
            3.3.3.2Facets
            3.3.3.3Datatypes based on decimal
        3.3.4float
            3.3.4.1Value Space
            3.3.4.2Lexical Mapping
            3.3.4.3Facets
        3.3.5double
            3.3.5.1Value Space
            3.3.5.2Lexical Mapping
            3.3.5.3Facets
        3.3.6duration
            3.3.6.1Value Space
            3.3.6.2Lexical Mapping
            3.3.6.3Facets
            3.3.6.4Related Datatypes
        3.3.7dateTime
            3.3.7.1Value Space
            3.3.7.2Lexical Mapping
            3.3.7.3Facets
            3.3.7.4Related Datatypes
        3.3.8time
            3.3.8.1Value Space
            3.3.8.2Lexical Mappings
            3.3.8.3Facets
        3.3.9date
            3.3.9.1Value Space
            3.3.9.2Lexical Mapping
            3.3.9.3Facets
        3.3.10gYearMonth
            3.3.10.1Value Space
            3.3.10.2LexicalMapping
            3.3.10.3Facets
        3.3.11gYear
            3.3.11.1Value Space
            3.3.11.2Lexical Mapping
            3.3.11.3Facets
        3.3.12gMonthDay
            3.3.12.1Value Space
            3.3.12.2Lexical Mapping
            3.3.12.3Facets
        3.3.13gDay
            3.3.13.1Value Space
            3.3.13.2Lexical Mapping
            3.3.13.3Facets
        3.3.14gMonth
            3.3.14.1Value Space
            3.3.14.2Lexical Mapping
            3.3.14.3Facets
        3.3.15hexBinary
            3.3.15.1Value Space
            3.3.15.2Lexical Mapping
            3.3.15.3Facets
        3.3.16base64Binary
            3.3.16.1Value Space
            3.3.16.2LexicalMapping
            3.3.16.3Facets
        3.3.17anyURI
            3.3.17.1Value Space
            3.3.17.2LexicalMapping
            3.3.17.3Facets
        3.3.18QName
            3.3.18.1Facets
        3.3.19NOTATION
            3.3.19.1Facets

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

Conforming processorsmust supportthe·primitive· datatypes definedin this specification; it is·implementation-defined· whether theysupport others.·Primitive· datatypes may be added by revisions to this specification.

Note: Processorsmay, for example, support thefloating-point decimal datatype specified in[Precision Decimal].

3.3.1 string

[Definition:]  Thestring datatyperepresents character strings in XML.

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

The·value space·ofstring is the set of finite-length sequences ofzero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].Acharacter is an atomic unit ofcommunication; it is not further specified except to note that everycharacter has a correspondingUniversal Character Set (UCS) code point, which is an integer.

It is·implementation-defined· whether animplementation of this specification supports theChar production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

Equality forstring isidentity. No order is prescribed.

Note: As noted inordered, the fact that this specification doesnot specify an order relationfor·string·does not preclude other applications from treating stringsas being ordered.
3.3.1.2 Lexical Mapping
The·lexical space· ofstring is the set of finite-length sequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].
Lexical Space
[1]  stringRep ::=Char
/*(as defined in[XML]) */

It is·implementation-defined· whether animplementation of this specification supports theChar production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

The·lexical mapping· forstring is·stringLexicalMap·, andthe·canonical mapping· is·stringCanonicalMap·;each is a subset of the identity function.

3.3.1.3 Facets

Thestring datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromstringmay alsospecify values for the following·constraining facets·:

Thestring datatype has the following values for its·fundamental facets·:

3.3.1.4 Deriveddatatypes

The following·built-in· datatype is·derived· fromstring

3.3.2 boolean

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

3.3.2.1 Value Space

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

3.3.2.2 Lexical Mapping
boolean's lexical space is a set of four·literals·:
Lexical Space
[2]  booleanRep ::= 'true' | 'false' |'1' | '0'

The·lexical mapping·forboolean is·booleanLexicalMap·;the·canonical mapping· is·booleanCanonicalMap·.

3.3.2.3 Facets

Theboolean datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction frombooleanmay alsospecify values for the following·constraining facets·:

Theboolean datatype has the following values for its·fundamental facets·:

3.3.3 decimal

[Definition:]  decimalrepresentsasubset of the real numbers, whichcan be represented bydecimal numerals.The·value space· ofdecimalis the set of numbers that can be obtained by dividing an integer by a non-negativepower of ten, i.e., expressible asi / 10nwherei andn are integersandn ≥ 0.Precision is not reflected in this value space;the number 2.0 is not distinct from the number 2.00.The order relation ondecimalis the order relation on real numbers, restrictedto this subset.

Note: For a decimal datatype whose values do reflect precision, see[Precision Decimal].
3.3.3.1 LexicalMapping

decimalhasa lexical representationconsisting of anon-empty finite-lengthsequence of decimaldigits (#x30–#x39) separatedby 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) canbe omitted.For example: '-1.23','12678967.543233', '+100000.00','210'.

Thedecimal Lexical Representation
[3]  decimalLexicalRep ::=decimalPtNumeral |noDecimalPtNumeral
The lexical space of decimal is the set oflexical representations which match the grammar given above, or(equivalently) the regular expression

(\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)

The mapping from lexical representations to values is the usualone for decimal numerals; it is given formally in·decimalLexicalMap·.

The definitionof the·canonical representation· has theeffect of prohibiting certain options from theLexicalMapping (§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.  Inall cases, leading andtrailing zeroes are prohibited subject to the following:  theremustbe at least one digit to the right and to the left of the decimalpoint which may be azero.

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

3.3.3.2 Facets

Thedecimal datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromdecimalmay alsospecify values for the following·constraining facets·:

Thedecimal datatype has the following values for its·fundamental facets·:

3.3.3.3 Datatypes based on decimal

The following·built-in· datatype is·derived· fromdecimal

3.3.4 float

[Definition:]  Thefloat datatypeis patterned after the IEEE single-precision 32-bit floating point datatype[IEEE 754-2008]. Its value space is a subset of therational numbers.  Floating point numbers are often used to approximate arbitrary real numbers.

3.3.4.1 Value Space

The·value space· offloat contains thenon-zero numbers m × 2e ,wherem is an integer whose absolute value is less than 224,ande is an integer between −149 and 104, inclusive.  In addition tothese values, the·value space· offloat also containsthe following·special values·positiveZero,negativeZero,positiveInfinity,negativeInfinity, andnotANumber.

Note: As explained below, the·lexical representation·of thefloatvaluenotANumber is 'NaN'.  Accordingly, in Englishtext we generally use 'NaN' to refer to that value.  Similarly,we use 'INF' and '−INF' to refer to the twovaluespositiveInfinity andnegativeInfinity,and '0' and '−0' to refer topositiveZero andnegativeZero.
Equality and order forfloat are defined as follows:
  • Equality is identity, except that  0 = −0  (althoughthey are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).
    0 and −0 are thus equivalentfor purposes of enumerations andidentity constraints, as well as for minimum and maximum values.
  • For the basic values, the order relationon float is the order relation for rational numbers.  INF is greaterthan all other non-NaN values; −INF is less than all other non-NaNvalues.  NaN is·incomparable· with any valuein the·value space· including itself.  0 and −0are greater than all the negative numbers and less than all the positivenumbers.
Note: Any value·incomparable· with the value used for the fourbounding facets (·minInclusive·,·maxInclusive·,·minExclusive·, and·maxExclusive·) will beexcluded from the resulting restricted·value space·. In particular, when NaN is used as a facet value for a bounding facet, since nofloat values are·comparable·with it, the result is a·value space· that is empty. If any other value is used for a bounding facet,NaN will be excluded from the resulting restricted·value space·;to add NaN back in requires union with the NaN-only space (whichmay be derived usingthepattern 'NaN').
Note: The Schema 1.0 version of this datatype did not differentiate between0 and −0 and NaN was equal to itself.  The changes weremade to make the datatype more closely mirror[IEEE 754-2008].
3.3.4.2 Lexical Mapping
The·lexical space· offloat isthe set of all decimal numerals with or without a decimalpoint, numerals in scientific (exponential) notation, andthe·literals· 'INF', '+INF','-INF', and 'NaN'ThefloatRep production is equivalent to this regular expression (after whitespace isremoved from the regular expression):

(\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)?
|(\+|-)?INF|NaN

Thefloat datatype is designed to implement for schemaprocessing the single-precision floating-point datatype of[IEEE 754-2008].  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 754-2008], 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, processorsconforming to this specification may exhibit some variation in their·lexical mappings·.

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

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

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

3.3.4.3 Facets

Thefloat datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromfloatmay alsospecify values for the following·constraining facets·:

Thefloat datatype has the following values for its·fundamental facets·:

3.3.5 double

[Definition:]  Thedoubledatatype is patterned after theIEEE double-precision 64-bit floating point datatype[IEEE 754-2008]. Each floatingpoint datatype has a value space that is a subset of therational numbers.  Floating point numbers are often used to approximate arbitrary real numbers.

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

The·value space· ofdouble contains thenon-zero numbers m × 2e ,wherem is an integer whose absolute value is less than 253,ande is an integer between −1074 and 971, inclusive.  In addition tothese values, the·value space· ofdouble also containsthe following·special values·positiveZero,negativeZero,positiveInfinity,negativeInfinity, andnotANumber.

Note: As explained below, the·lexical representation·of thedoublevaluenotANumber is 'NaN'.  Accordingly, in Englishtext we generally use 'NaN' to refer to that value.  Similarly,we use 'INF' and '−INF' to refer to the twovaluespositiveInfinity andnegativeInfinity,and '0' and '−0' to refer topositiveZero andnegativeZero.
Equality and order fordouble are defined as follows:
  • Equality is identity, except that  0 = −0  (althoughthey are not identical) and  NaN ≠ NaN  (although NaN is of course identical to itself).
    0 and −0 are thus equivalent for purposes of enumerations,identity constraints, and minimum and maximum values.
  • For the basic values, the order relationon double is the order relation for rational numbers.  INF is greaterthan all other non-NaN values; −INF is less than all other non-NaNvalues.  NaN is·incomparable· with any valuein the·value space· including itself.  0 and −0are greater than all the negative numbers and less than all the positivenumbers.
Note: Any value·incomparable· with the value used for the fourbounding facets (·minInclusive·,·maxInclusive·,·minExclusive·, and·maxExclusive·) will beexcluded from the resulting restricted·value space·. In particular, when NaN is used as a facet value for a bounding facet, since nodouble values are·comparable·with it, the result is a·value space· that is empty. If any other value is used for a bounding facet,NaN will be excluded from the resulting restricted·value space·;to add NaN back in requires union with the NaN-only space (whichmay be derived usingthepattern 'NaN').
Note: The Schema 1.0 version of this datatype did not differentiate between0 and −0 and NaN was equal to itself.  The changes weremade to make the datatype more closely mirror[IEEE 754-2008].
3.3.5.2 Lexical Mapping
The·lexical space· ofdouble isthe set of all decimal numerals with or without a decimalpoint, numerals in scientific (exponential) notation, andthe·literals· 'INF', '+INF','-INF', and 'NaN'ThedoubleRep production is equivalent to this regular expression(after whitespace is eliminated from the expression):

(\+|-)?([0-9]+(\.[0-9]*)?|\.[0-9]+)([Ee](\+|-)?[0-9]+)?|(\+|-)?INF|NaN

Thedouble datatype is designed to implement for schemaprocessing the double-precision floating-point datatype of[IEEE 754-2008].  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 754-2008], 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, processorsconforming to this specification may exhibit some variation in their·lexical mappings·.

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

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

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

3.3.5.3 Facets

Thedouble datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromdoublemay alsospecify values for the following·constraining facets·:

Thedouble datatype has the following values for its·fundamental facets·:

3.3.6 duration

[Definition:]  duration is a datatype that representsdurations of time.  The concept of duration being captured isdrawn from those of[ISO 8601], specificallydurations without fixed endpoints.  For example,"15 days" (whose most common lexical representationinduration is "'P15D'") isaduration value; "15 days beginning 12 July1995" and "15 days ending 12 July 1995" arenotduration values. duration can provide addition andsubtraction operations betweenduration values andbetweenduration/dateTime value pairs,and can be the result of subtractingdateTimevalues.  However, only addition todateTimeis required for XML Schema processing and isdefined inthe function·dateTimePlusDuration·.

3.3.6.1 Value Space
Duration values can be modelled astwo-property tuples. Each value consists of an integer number ofmonths and a decimal number of seconds. The·seconds· valuemust not be negative if the·months· value is positive andmust not be positive if the·months· is negative.
Properties ofduration Values
adecimal value;must not be negative if·months· is positive, andmust notbe positive if·months· is negative.
duration is partially ordered.  Equality ofduration is defined in terms of equality ofdateTime; order forduration is defined in terms of the order ofdateTime. Specifically, the equality or order of twoduration values is determined by adding eachduration in the pair to each of the following fourdateTime values:
  • 1696-09-01T00:00:00Z
  • 1697-02-01T00:00:00Z
  • 1903-03-01T00:00:00Z
  • 1903-07-01T00:00:00Z
If all four resultingdateTime value pairs are orderedthe same way (less than, equal, or greater than), then the originalpair ofduration values is ordered the same way;otherwise the original pair is·incomparable·.
Note: These four values are chosen so as to maximize the possible differences in results that could occur, such as the difference when adding P1M and P30D:  1697-02-01T00:00:00Z + P1M < 1697-02-01T00:00:00Z + P30D , but 1903-03-01T00:00:00Z + P1M > 1903-03-01T00:00:00Z + P30D , so that  P1M <> P30D .  If twoduration values are ordered the same way when added to each of these fourdateTime values, they will retain the same order when added toany otherdateTime values.  Therefore, twoduration values are incomparable if and only if they canever result in different orders when added toanydateTime value.

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

Note: Two totally ordered datatypes (yearMonthDuration anddayTimeDuration) are derived fromduration inOther Built-in Datatypes (§3.4).
Note: There are many ways to implementduration,some of which do not base the implementation on the two-componentmodel.  This specification does not prescribe any particularimplementation, as long as the visible results are isomorphic to thosedescribed herein.
Note: See the conformance notes inPartial Implementation of Infinite Datatypes (§5.4), whichapply to this datatype.
3.3.6.2 Lexical Mapping
The·lexical representations·ofduration are more or less based on the pattern:

PnYnMnDTnHnMnS

More precisely, the·lexical space· ofdurationis the set of character strings that satisfydurationLexicalRep as defined by the following productions:
Lexical Representation Fragments
[6]  duYearFrag ::=unsignedNoDecimalPtNumeral 'Y'
[7]  duMonthFrag ::=unsignedNoDecimalPtNumeral 'M'
[8]  duDayFrag ::=unsignedNoDecimalPtNumeral 'D'
[9]  duHourFrag ::=unsignedNoDecimalPtNumeral 'H'
[10]  duMinuteFrag ::=unsignedNoDecimalPtNumeral 'M'
[11]  duSecondFrag ::= (unsignedNoDecimalPtNumeral | unsignedDecimalPtNumeral) 'S'
[12]  duYearMonthFrag ::= (duYearFrag duMonthFrag?) |duMonthFrag
[13]  duTimeFrag ::= 'T' ((duHourFrag duMinuteFragduSecondFrag?) |(duMinuteFrag duSecondFrag?) |duSecondFrag)
[14]  duDayTimeFrag ::= (duDayFrag duTimeFrag?) |duTimeFrag
Lexical Representation
[15]  durationLexicalRep ::= '-'? 'P' ((duYearMonthFrag duDayTimeFrag?) | duDayTimeFrag)

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

The language accepted by thedurationLexicalRep production is the set of strings which satisfy all of the followingthree regular expressions:
  • The expression

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

    matches only strings in which the fields occur in the proper order.
  • The expression '.*[YMDHS].*' matches onlystrings in which at least one field occurs.
  • The expression '.*[^T]' matchesonly strings in which 'T' is not the final character, so thatif 'T' appears, something follows it. The first ruleensures that what follows 'T' will be an hour,minute, or second field.
The intersection of these three regular expressions is equivalent tothe following (after removal of the white space inserted here forlegibility):
-?P( ( ( [0-9]+Y([0-9]+M)?([0-9]+D)?       | ([0-9]+M)([0-9]+D)?       | ([0-9]+D)       )       (T ( ([0-9]+H)([0-9]+M)?([0-9]+(\.[0-9]+)?S)?          | ([0-9]+M)([0-9]+(\.[0-9]+)?S)?          | ([0-9]+(\.[0-9]+)?S)          )       )?    )  | (T ( ([0-9]+H)([0-9]+M)?([0-9]+(\.[0-9]+)?S)?       | ([0-9]+M)([0-9]+(\.[0-9]+)?S)?       | ([0-9]+(\.[0-9]+)?S)       )    )  )

The·lexical mapping· forduration is·durationMap·.

·The canonicalmapping· fordurationis·durationCanonicalMap·.

3.3.6.3 Facets

Theduration datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromdurationmay alsospecify values for the following·constraining facets·:

Theduration datatype has the following values for its·fundamental facets·:

3.3.6.4 Related Datatypes

The following·built-in· datatypes are·derived· fromduration

3.3.7 dateTime

dateTime representsinstants of time, optionally markedwith a particular time zone offset.  Values representingthe same instant but havingdifferent time zone offsets are equal but notidentical.

3.3.7.1 Value Space

dateTime uses thedate/timeSevenPropertyModel, with no properties except·timezoneOffset·permitted to beabsent. The·timezoneOffset· property remains·optional·.

Note: In version 1.0 of this specification, the·year· property was not permitted to have the valuezero. The year before the year 1in the proleptic Gregorian calendar, traditionally referred to as 1 BC or as1 BCE, was represented by a·year· value of −1, 2 BCE by −2, and soforth. Of course, many, perhaps most,references to 1 BCE (or 1 BC) actually refer not to a year in the proleptic Gregorian calendar but to a year in theJulian or "old style" calendar; the two correspondapproximately but not exactly to each other.
In this version of this specification,two changes are made in order to agree with existing usage. First,·year· is permitted to have the value zero.Second, the interpretation of·year· values is changed accordingly: a·year· value of zero represents 1 BCE, −1represents 2 BCE, etc. This representation simplifies intervalarithmetic and leap-year calculation for dates before the common era (which may be why astronomersand others interested in such calculations with the prolepticGregorian calendar have adopted it), and is consistent with thecurrent edition of[ISO 8601].
Note that 1 BCE, 5 BCE, and so on (years 0000, -0004, etc. in thelexical representation defined here) are leap years in the prolepticGregorian calendar used for the date/time datatypes defined here.Version 1.0 of this specification was unclear about the treatment ofleap years before the common era.If existingschemas or data specify dates of 29 February for any years before thecommon era, then some values givinga date of 29 February which were valid under a plausibleinterpretation 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 validunder the old interpretation remain valid under the new.
Constraint: Day-of-month Values
The·day· valuemust beno more than 30 if·month·is one of 4, 6, 9, or 11; no more than 28if·month· is 2 and·year· is not divisible by 4,or is divisible by 100 but not by 400;and no more than 29 if·month·is 2 and·year·is divisible by 400, or by 4 but not by 100.
Note: See the conformance note inPartial Implementation of Infinite Datatypes (§5.4)which applies to the·year· and·second·values of this datatype.

Equality and order are as prescribedinThe Seven-property Model (§D.2.1)dateTime values are orderedby their·timeOnTimeline· value.

Note: Since the order of adateTimevalue having a·timezoneOffset·relative to another value whose·timezoneOffset· isabsent is determinedby imputing time zone offsets of both +14:00and −14:00 to the value with no time zone offset, many suchcombinations will be·incomparable· because the two imputedtime zone offsets yield different orders.
AlthoughdateTime and othertypes related to dates and times have only a partial order, itis possible for datatypes derived fromdateTime to havetotal orders, if they are restricted (e.g. using thepattern facet) to the subset of values with, orthe subset of values without, time zone offsets. Similar restrictionson other date- and time-related types will similarly producetotally ordered subtypes. Note, however, thatsuch restrictions do not affect the value shown, for a givenSimple Type Definition, in theordered facet.
Note: Order and equality are essentially the same fordateTime in this version of this specification asthey were in version 1.0.  However, since valuesnow distinguish time zone offsets, equalvalues with different·timezoneOffset·sare notidentical, and values with extreme·timezoneOffset·s may no longer be equalto any value with a smaller·timezoneOffset·.
3.3.7.2 Lexical Mapping
The lexical representations fordateTime are as follows:
Lexical Space
[16]  dateTimeLexicalRep ::=yearFrag '-monthFrag '-dayFrag 'T' ((hourFrag ':minuteFrag ':secondFrag) |endOfDayFrag)timezoneFrag?  Constraint:  Day-of-month Representations
Constraint: Day-of-month Representations
Within adateTimeLexicalRep, adayFragmust notbegin with the digit '3' or be '29'unless the value towhich it would map would satisfy the value constraint on·day· values("Constraint: Day-of-month Values") given above.
In such representations:
  • yearFrag is a numeral consistingof at least four decimal digits, optionally preceded by a minus sign;leading '0' digits are prohibited except to bring thedigit count up to four. It represents the·year· value.
  • Subsequent '-', 'T', and':', separate the various numerals.
  • monthFrag,dayFrag,hourFrag,andminuteFrag are numerals consistingof exactly two decimal digits. They represent the·month·,·day·,·hour·, and·minute· valuesrespectively.
  • secondFragis a numeral consistingof exactly two decimal digits, or two decimal digits,a decimal point, and one or more trailing digits. It represents the·second· value.
  • Alternatively,endOfDayFrag combines thehourFrag,minuteFrag,minuteFrag, and their separators torepresent midnight of the day, which is the first moment of the nextday.
  • timezoneFrag, if present, specifies anoffset between UTC and local time. Time zone offsets are a count of minutes (expressed intimezoneFrag as a count of hours and minutes) that are addedor subtracted from UTC time 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, 2002-10-10T12:00:00−05:00 (noon on 10 October 2002, Central DaylightSavings Time as well as Eastern Standard Timein the U.S.) is equal to 2002-10-10T17:00:00Z,five hours later than 2002-10-10T12:00:00Z.
    Note: For the most part, this specification adopts the distinction between'timezone' and 'timezone offset' laidout in[Timezones]. Version 1.0 of this specification did not make this distinction,but used the term 'timezone' for the time zoneoffset information associated with date- and time-related datatypes.Some traces of the earlier usage remain visible in this and otherspecifications. The namestimezoneFragandexplicitTimezoneare 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 "non-timezoned"values.
ThedateTimeLexicalRep productionis equivalent to this regular expressiononce whitespace is removed.
-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?
Note that neither thedateTimeLexicalRep productionnor this regularexpression alone enforce the constraintondateTimeLexicalRep given above.

The·lexical mapping·fordateTime is·dateTimeLexicalMap·.The·canonical mapping· is·dateTimeCanonicalMap·.

3.3.7.3 Facets

ThedateTime datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThedateTime datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromdateTimemay alsospecify values for the following·constraining facets·:

ThedateTime datatype has the following values for its·fundamental facets·:

3.3.7.4 Related Datatypes

The following·built-in· datatype is·derived· fromdateTime

3.3.8 time

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

3.3.8.1 Value Space

time uses thedate/timeSevenPropertyModel, with·year·,·month·,and·day· required to beabsent·timezoneOffset· remains·optional·.

Note: See the conformance note inPartial Implementation of Infinite Datatypes (§5.4)which applies to the·second· value of this datatype.

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

A calendar (or "local time") day with a larger positive time zone offset begins earlier than the same calendar day with a smaller (or negative)time zone offset. Since the time zone offsets allowed spread over 28 hours,it ispossible for the period denoted by a given calendar day with onetime zone offset to be completely disjoint from the period denoted bythe same calendar day with a different offset— the earlier day ends before thelater one starts.  The moments in timerepresented by a single calendar day are spread over a 52-hourinterval, from the beginning of the day in the +14:00 time zone offset to theend of that day in the −14:00 time zone offset.

Note: The relativeorder of twotime values, one of which has a·timezoneOffset· ofabsent is determined by imputingtime zone offsets of both +14:00 and −14:00 to the value without an offset. Many such combinations will be·incomparable· because the two imputed time zone offsets yielddifferent orders.  However, for a given non-timezoned value,there will always be timezoned values at one or both ends of the52-hour interval that are·comparable· (because the interval of·incomparability· is only28hours wide).
Some pairs oftime literalswhich in the 1.0 version of this specificationdenoted the same valuenow (in this version) denote distinct values instead,because values now include time zone offset information.Some such pairs, such as '05:00:00-03:00' and '10:00:00+02:00',now denote equal though distinct values (because they identify the same points on the time line); others, such as '23:00:00-03:00' and '02:00:00Z', now denote unequal values (23:00:00−03:00 > 02:00:00Zbecause 23:00:00−03:00 on any given day is equal to02:00:00Z onthe next day).
3.3.8.2 Lexical Mappings
The lexical representations fortimeare "projections" of those ofdateTime, as follows:
Lexical Space
[17]  timeLexicalRep ::= ((hourFrag ':minuteFrag ':secondFrag) |endOfDayFrag)timezoneFrag?
ThetimeLexicalRep productionis equivalent to thisregular expression, once whitespace isremoved:

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

Note that neitherthetimeLexicalRep productionnor this regularexpression alone enforce the constraintontimeLexicalRep given above.

The·lexical mapping·fortime is·timeLexicalMap·; the·canonical mapping· is·timeCanonicalMap·.

Note: The·lexical mapping· maps '00:00:00' and'24:00:00' to the same value, namely midnight(·hour· = 0 ,·minute· = 0 ,·second· = 0).
3.3.8.3 Facets

Thetime datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Thetime datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromtimemay alsospecify values for the following·constraining facets·:

Thetime datatype has the following values for its·fundamental facets·:

3.3.9 date

[Definition:]  daterepresents top-open intervals of exactly one day in length on the timelines ofdateTime, beginning on the beginning moment of each day, up to but not including the beginningmoment of the next day).  For non-timezoned values, the top-openintervals disjointly cover the non-timezoned timeline,one per day.  For timezonedvalues, the intervals begin at every minute and therefore overlap.

3.3.9.1 Value Space

date uses thedate/timeSevenPropertyModel, with·hour·,·minute·,and·second· required to beabsent·timezoneOffset· remains·optional·.

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

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

Note: In version 1.0 of this specification,date values did not retain a time zone offset explicitly, but for offsets not too far from zero their time zone offset could be recovered based ontheir value's first moment on the timeline.  Thedate/timeSevenPropertyModel retains all time zone offsets.
Somedate values withdifferent time zone offsets that were identical in the 1.0 versionof this specification, such as 2000-01-01+13:00and 1999-12-31−11:00, are in this versionof this specification equal (because they beginat the same moment on the time line) but arenot identical (because they have and retain differenttime zone offsets).  This situation will arise fordates only if one has a far-from-zero time zone offset andhence in 1.0 its "recoverable time zone offset"was different from the the time zone offset which is retainedin thedate/timeSevenPropertyModel used in this versionof this specification.
3.3.9.2 Lexical Mapping
The lexical representations fordateare "projections" of those ofdateTime, as follows:
Lexical Space
[18]  dateLexicalRep ::=yearFrag '-monthFrag '-dayFragtimezoneFrag?  Constraint:  Day-of-month Representations
Constraint: Day-of-month Representations
Within adateLexicalRep,adayFragmust notbegin with the digit '3' or be '29'unless the value towhich it would map would satisfy the value constraint on·day· values("Constraint: Day-of-month Values") given above.
ThedateLexicalRep productionis equivalent to thisregular expression:

-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

Note that neitherthedateLexicalRep productionnor this regularexpression alone enforce the constraintondateLexicalRep given above.

The·lexical mapping·fordate is·dateLexicalMap·.The·canonical mapping· is·dateCanonicalMap·.

3.3.9.3 Facets

Thedate datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Thedate datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromdatemay alsospecify values for the following·constraining facets·:

Thedate datatype has the following values for its·fundamental facets·:

3.3.10 gYearMonth

gYearMonth represents specific whole Gregorian months in specific Gregorian years.

Note: Because month/year combinations in one calendar only rarely correspondto month/year combinations in other calendars, values of this typeare not, in general, convertible to simple values corresponding to month/yearcombinations in other calendars.  This type should therefore be usedwith caution in contexts where conversion to other calendars is desired.
3.3.10.1 Value Space

gYearMonth uses thedate/timeSevenPropertyModel, with·day·,·hour·,·minute·, and·second· required to beabsent·timezoneOffset· remains·optional·.

Note: See the conformance note inPartial Implementation of Infinite Datatypes (§5.4)which applies to the·year· value of this datatype.

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

3.3.10.2 LexicalMapping
The lexical representations forgYearMonth are "projections" of those ofdateTime, as follows:
Lexical Space
[19]  gYearMonthLexicalRep ::=yearFrag '-monthFrag timezoneFrag?
ThegYearMonthLexicalRep is equivalent to this regular expression:

-?([1-9][0-9]{3,}|0[0-9]{3})-(0[1-9]|1[0-2])(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

The·lexical mapping·forgYearMonth is·gYearMonthLexicalMap·.The·canonical mapping· is·gYearMonthCanonicalMap·.

3.3.10.3 Facets

ThegYearMonth datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThegYearMonth datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromgYearMonthmay alsospecify values for the following·constraining facets·:

ThegYearMonth datatype has the following values for its·fundamental facets·:

3.3.11 gYear

gYearrepresents Gregorian calendar years.

Note: Because years in one calendar only rarely correspond to yearsin other calendars, values of this typeare not, in general, convertible to simple values corresponding to yearsin other calendars.  This type should therefore be used with cautionin contexts where conversion to other calendars is desired.
3.3.11.1 Value Space

gYear uses thedate/timeSevenPropertyModel, with·month·,·day·,·hour·,·minute·, and·second· required to beabsent·timezoneOffset· remains·optional·.

Note: See the conformance note inPartial Implementation of Infinite Datatypes (§5.4)which applies to the·year· value of this datatype.

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

3.3.11.2 Lexical Mapping
The lexical representations forgYear are "projections" of those ofdateTime, as follows:
Lexical Space
[20]  gYearLexicalRep ::=yearFrag timezoneFrag?
ThegYearLexicalRep is equivalent to this regular expression:

-?([1-9][0-9]{3,}|0[0-9]{3})(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

The·lexical mapping·forgYear is·gYearLexicalMap·.The·canonical mapping·is·gYearCanonicalMap·.

3.3.11.3 Facets

ThegYear datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThegYear datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromgYearmay alsospecify values for the following·constraining facets·:

ThegYear datatype has the following values for its·fundamental facets·:

3.3.12 gMonthDay

gMonthDay represents whole calendar days that recur at the same point in each calendar year, or that occur in some arbitrary calendar year.  (Obviously,days beyond 28 cannot occur in all Februaries; 29 is nonethelesspermitted.)

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

Note: Because day/month combinations in one calendar only rarely correspondto day/month combinations in other calendars, values of this type do not,in general, have any straightforward or intuitive representationin terms of most other calendars. This type should therefore beused with caution in contexts where conversion to other calendarsis desired.
3.3.12.1 Value Space

gMonthDay uses thedate/timeSevenPropertyModel, with·year·,·hour·,·minute·, and·second· required to beabsent·timezoneOffset· remains·optional·.

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

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

Note: In version 1.0 of this specification,gMonthDay values did not retain a time zone offset explicitly, but for time zone offsets not too far from·UTC· their time zone offset could be recovered based ontheir value's first moment on the timeline.  Thedate/timeSevenPropertyModel retains all time zone offsets.
An example that shows the difference from version 1.0 (seeLexical Mapping (§3.3.12.2) for the notations):
  • A day is a calendar (or "local time") day offset from·UTC·by the appropriate interval;this is now true for all·day·values, including those with time zone offsets outside the range+12:00 through -11:59 inclusive:
    --12-12+13:00 < --12-12+11:00 (just as --12-12+12:00 has always been less than--12-12+11:00, but in version 1.0 --12-12+13:00 > --12-12+11:00 , since--12-12+13:00's "recoverabletime zone offset" was −11:00)
3.3.12.2 Lexical Mapping
The lexical representations forgMonthDay are "projections" of those ofdateTime, as follows:
Lexical Space
[21]  gMonthDayLexicalRep ::= '--monthFrag '-dayFragtimezoneFrag?  Constraint:  Day-of-month Representations
Constraint: Day-of-month Representations
Within agMonthDayLexicalRep, adayFragmust notbegin with the digit '3' or be '29'unless the value towhich it would map would satisfy the value constraint on·day· values("Constraint: Day-of-month Values") given above.
ThegMonthDayLexicalRep is equivalent to this regular expression:

--(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

Note that neitherthegMonthDayLexicalRep productionnor this regularexpression alone enforce the constraintongMonthDayLexicalRep given above.

The·lexical mapping·forgMonthDay is·gMonthDayLexicalMap·.The·canonical mapping· is·gMonthDayCanonicalMap·.

3.3.12.3 Facets

ThegMonthDay datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThegMonthDay datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromgMonthDaymay alsospecify values for the following·constraining facets·:

ThegMonthDay datatype has the following values for its·fundamental facets·:

3.3.13 gDay

[Definition:]  gDay represents whole days within an arbitrary month—days that recur at the samepoint 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, daysbeyond 28 cannot occur inall months; they are nonetheless permitted, up to 31.)

Note: Because days in one calendar only rarelycorrespond to days in other calendars,gDayvalues do not, in general, have any straightforward orintuitive representation in terms of most non-Gregorian calendars.gDay should therefore be used with caution in contexts where conversion to other calendars is desired.
3.3.13.1 Value Space

gDay uses thedate/timeSevenPropertyModel, with·year·,·month·,·hour·,·minute·,and·second· required to beabsent·timezoneOffset· remains·optional· and·day·mustbe between 1 and 31 inclusive.

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

Examples that may appear anomalous (seeLexical Mapping (§3.3.13.2) for the notations):
  • ---15 < ---16 , but  ---15−13:00 > ---16+13:00
  • ---15−11:00 = ---16+13:00
  • ---15−13:00 <> ---16 ,because  ---15−13:00 > ---16+14:00 and ---15−13:00 < 16−14:00
Note: Time zone offsets do not cause wrap-around at the end of the month:  the last day of a given month with a time zone offset of −13:00 may start after the first day of thenext month with offset +13:00, as measured on the global timeline,but nonetheless ---01+13:00 < ---31−13:00 .
3.3.13.2 Lexical Mapping
The lexical representations forgDay are "projections" of those ofdateTime, as follows:
Lexical Space
[22]  gDayLexicalRep ::= '---dayFrag timezoneFrag?
ThegDayLexicalRep is equivalent to this regular expression:

---(0[1-9]|[12][0-9]|3[01])(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

The·lexical mapping· forgDay is·gDayLexicalMap·.The·canonical mapping· is·gDayCanonicalMap·.

3.3.13.3 Facets

ThegDay datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThegDay datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromgDaymay alsospecify values for the following·constraining facets·:

ThegDay datatype has the following values for its·fundamental facets·:

3.3.14 gMonth

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

Note: Because months in one calendar only rarely correspondto months in other calendars, values of this type do not,in general, have any straightforward or intuitive representationin terms of most other calendars. This type should therefore beused with caution in contexts where conversion to other calendarsis desired.
3.3.14.1 Value Space

gMonth uses thedate/timeSevenPropertyModel, with·year·,·day·,·hour·,·minute·, and·second· required to beabsent·timezoneOffset· remains·optional·.

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

3.3.14.2 Lexical Mapping
The lexical representations forgMonth are "projections" of those ofdateTime, as follows:
Lexical Space
[23]  gMonthLexicalRep ::= '--monthFrag timezoneFrag?
ThegMonthLexicalRep is equivalent to this regular expression:

--(0[1-9]|1[0-2])(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?

The·lexical mapping· forgMonth is·gMonthLexicalMap·.The·canonical mapping· is·gMonthCanonicalMap·.

3.3.14.3 Facets

ThegMonth datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThegMonth datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromgMonthmay alsospecify values for the following·constraining facets·:

ThegMonth datatype has the following values for its·fundamental facets·:

3.3.15 hexBinary

[Definition:]  hexBinaryrepresents arbitrary hex-encoded binary data. 

3.3.15.1 Value Space

The·value space· ofhexBinaryis the set of finite-length sequences of zero or morebinary octets.  Thelength of a value is the number of octets.

3.3.15.2 Lexical Mapping

hexBinary's·lexical space·consists of strings of hex (hexadecimal) digits, two consecutive digitsrepresenting each octet in the corresponding value (treating the octetas the binary representation of a number between 0 and 255).  Forexample, '0FB7' is a·lexical representation· of thetwo-octet value 00001111 10110111.

More formally, the·lexical space· ofhexBinary is the set of literals matching thehexBinary production.
Lexical space of hexBinary
[24]  hexDigit ::= [0-9a-fA-F]
[25]  hexOctet ::=hexDigithexDigit
[26]  hexBinary ::=hexOctet*

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

The·lexical mapping· ofhexBinary is·hexBinaryMap·.

The·canonical mapping· ofhexBinary is given formally in·hexBinaryCanonical·.

3.3.15.3 Facets

ThehexBinary datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromhexBinarymay alsospecify values for the following·constraining facets·:

ThehexBinary datatype has the following values for its·fundamental facets·:

3.3.16 base64Binary

[Definition:]  base64Binary represents arbitraryBase64-encoded binarydata.  Forbase64Binary data the entire binary stream is encodedusing the Base64 Encodingdefined in[RFC 3548], which is derived from the encodingdescribed in[RFC 2045].

3.3.16.1 Value Space

The·value space· ofbase64Binary is the set of finite-length sequences ofzero or morebinary octets.  Thelength of a value is the number of octets.

3.3.16.2 LexicalMapping

The·lexical representations· ofbase64Binaryvalues are limited to the 65 characters of the Base64 Alphabet defined in[RFC 3548],i.e.,a-z,A-Z,0-9, the plus sign (+), the forward slash (/) and theequal 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 76characters in length.  This line-length limitation is notrequired by[RFC 3548]and is not mandated in the·lexical representations· ofbase64Binarydata.  Itmust notbe enforced by XML Schema processors.

The·lexical space· ofbase64Binaryis theset of literals which·match· thebase64Binaryproduction.

Lexical space of base64Binary
[27]  Base64Binary ::= (B64quad*B64final)?
[28]  B64quad ::= (B64B64B64B64)
/*B64quad represents three octets of binary data. */
[29]  B64final ::=B64finalquad |Padded16 |Padded8
[30]  B64finalquad ::= (B64B64B64B64char)
/*B64finalquad represents three octetsof binary data without trailing space. */
[31]  Padded16 ::=B64B64B16 '='
/*Padded16 represents a two-octetat the end of the data. */
[32]  Padded8 ::=B64B04 '=' #x20? '='
/*Padded8 represents a single octet at the end of the data. */
[33]  B64 ::=B64char #x20?
[34]  B64char ::= [A-Za-z0-9+/]
[35]  B16 ::=B16char #x20?
[36]  B16char ::= [AEIMQUYcgkosw048]
/*Base64 characters whose bit-string value ends in '00' */
[37]  B04 ::=B04char #x20?
[38]  B04char ::= [AQgw]
/*Base64 characters whose bit-string value ends in'0000' */
TheBase64Binary production is equivalent to the following regular expression.

((([A-Za-z0-9+/] ?){4})*(([A-Za-z0-9+/] ?){3}[A-Za-z0-9+/]|([A-Za-z0-9+/] ?){2}[AEIMQUYcgkosw048] ?=|[A-Za-z0-9+/] ?[AQgw] ?= ?=))?

Note that each '?' except the last is preceded by asingle space character.

Note that this grammar requires the number of non-whitespacecharacters in the·lexical representation· to be a multiple of four, andfor equals signs to appear only at the end of the·lexical representation·;literalswhich do not meet these constraintsare not legal·lexical representations· ofbase64Binary.

The·lexical mapping· forbase64Binary is as given in[RFC 2045] and[RFC 3548].

Note: The above definition of the·lexical space· is more restrictive thanthat given in[RFC 2045] as regards whitespace —and less restrictive than[RFC 3548].This isnot an issue in practice.  Any string compatible witheitherRFC can occur in an element or attributevalidated by this type, because the·whiteSpace·facet of this type is fixed tocollapse, which means that allleading and trailing whitespace will be stripped, and all internalwhitespace collapsed to single space characters,beforethe above grammar is enforced. Thepossibility of ignoring whitespace in Base64 data is foreseen inclause 2.3 of[RFC 3548], but for the reasons given therethis specification does not allow implementations to ignorenon-whitespace characters which are not in the Base64Alphabet.

The canonical·lexical representation· of abase64Binarydata value is the Base64 encoding of the value which matches theCanonical-base64Binary production in the following grammar:

Canonical representation of base64Binary
[39]  Canonical-base64Binary ::=CanonicalQuad*CanonicalPadded?
[40]  CanonicalQuad ::=B64charB64charB64charB64char
[41]  CanonicalPadded ::=B64charB64charB16char '='|B64charB04char '=='

That is, the·canonical representation·of abase64Binary value is the·lexical representation·which maps to that value and contains no whitespace. The·canonical mapping· forbase64Binary isthus the encoding algorithm for Base64 data given in[RFC 2045]and[RFC 3548], with the proviso that nocharacters except those in the Base64 Alphabet are to be writtenout.

Note: For some values the·canonical representation· defined above doesnot conform to[RFC 2045], which requires breaking withlinefeeds at appropriate intervals. Itdoes conform with[RFC 3548].

The length of abase64Binaryvalue may be calculated from the·lexical representation· byremoving whitespace and padding characters and performing thecalculation shown in the pseudo-code below:

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

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

3.3.16.3 Facets

Thebase64Binary datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction frombase64Binarymay alsospecify values for the following·constraining facets·:

Thebase64Binary datatype has the following values for its·fundamental facets·:

3.3.17 anyURI

[Definition:]  anyURI represents anInternationalized Resource Identifier Reference(IRI).  AnanyURI value can be absolute or relative, and mayhave an optional fragment identifier (i.e., it may be anIRI 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 IETFStandards Track.

Note: IRIs may be used to locate resourcesor simply to identify them. In the case where they are used to locateresources using a URI, applications should usethe mapping fromanyURIvalues to URIs given by the reference escaping procedure defined in[LEIRI] and inSection 3.1Mappingof IRIs to URIs of[RFC 3987]or its successor(s) in the IETF Standards Track. This means that a wide range of internationalized resource identifierscan be specified when ananyURIis called for, and still be understood as URIs per[RFC 3986]and its successor(s).
3.3.17.1 Value Space

The value space ofanyURI is the set of finite-lengthsequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].

3.3.17.2 LexicalMapping

The·lexical space· ofanyURIis the set of finite-lengthsequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].

Note: For ananyURI value to be usable in practice as an IRI, the result of applying to it the algorithm defined in Section 3.1 of[RFC 3987]should be a string which is a legal URI accordingto[RFC 3986]. (This is true at the time this document is published;if in the future[RFC 3987] and[RFC 3986] are replaced by other specificationsin the IETF Standards Track, the relevant constraints will be thoseimposed by those successor specifications.)
Each URI scheme imposes specialized syntax rulesfor URIs in that scheme, including restrictions on the syntax ofallowed fragment identifiers. Because it is impractical for processorsto check that a value is a context-appropriate URI reference, neither the syntactic constraints defined by the definitions of individualschemes nor the generic syntactic constraints defined by[RFC 3987] and[RFC 3986] and theirsuccessors are part of this datatype as defined here.Applications which depend onanyURI valuesbeing legal according to the rules of the relevant specifications should make arrangements to check values against the appropriate definitions of IRI, URI, and specific schemes.
Note: Spaces are, in principle, allowed in the·lexical space· ofanyURI,however, their use is highly discouraged(unless they are encoded by '%20').

The·lexical mapping· foranyURI isthe identity mapping.

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

TheanyURI datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromanyURImay alsospecify values for the following·constraining facets·:

TheanyURI datatype has the following values for its·fundamental facets·:

3.3.18 QName

[Definition:]  QName representsXML qualifiednames.The·value space· ofQName is the set oftuples {namespace name,local part},wherenamespace nameis ananyURIandlocal part isanNCName.The·lexical space· ofQName is the setof strings that·match· theQName production of[Namespaces in XML].

It is·implementation-defined· whether animplementation of this specification supports theQName production from[Namespaces in XML], or that from[Namespaces in XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

The mapping from lexical space to value space for a particularQName·literal· depends on the namespace bindings in scope where the literal occurs.

WhenQNamesappear in an XML context, the bindings to be used inthe·lexical mapping· are those in the[in-scope namespaces] property of therelevant element.When this datatype is used in a non-XML host language, the host languagemust specify what namespace bindingsare to be used.

The host language, whether XML-based or otherwise,may specify whetherunqualified 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.

Note: The default treatment ofunqualified names parallels that specified in[Namespaces in XML] for element names (as opposed to that specifiedfor attribute names).
Note: The mapping between·literals· in the·lexical space· andvalues in the·value space· ofQNamedepends on the set ofnamespace declarationsin scope for the context in whichQName is used. 
Because the lexical representations available forany value of typeQName vary with context, no·canonical representation· is defined forQNamein this specification.
3.3.18.1 Facets

TheQName datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromQNamemay alsospecify values for the following·constraining facets·:

TheQName datatype has the following values for its·fundamental facets·:

3.3.19 NOTATION

[Definition:]  NOTATIONrepresents theNOTATIONattributetype from[XML].The·value space·ofNOTATION is the set ofQNamesof notations declared in the current schema.The·lexical space· ofNOTATION is the setof all names ofnotationsdeclared in the current schema (in the form ofQNames).

Note: Because its·value space· depends on the notion of a "current schema", as instantiated for example by[XSD 1.1 Part 1: Structures], theNOTATION datatype is unsuitable for use in other contexts which lack the notion of acurrent schema.

The lexical mapping rules forNOTATION are as given forQName inQName (§3.3.18).

Schema Component Constraint: enumeration facet value required for NOTATION
It is (with one exception) an·error· forNOTATION to be useddirectly to validate a literal as described inDatatype Valid (§4.1.4):only datatypes·derived· fromNOTATION by specifyinga value for·enumeration· can be used to validate literals.
The exception is that in the·derivation· of a new type the·literals· used to enumerate the allowed valuesmay be (and inthe context of [XSD 1.1 Part 1: Structures] will be)validated directly againstNOTATION; this amounts toverifying that the value is aQName and that theQName is thename of aNOTATION declared in the current schema.

For compatibility (seeTerminology (§1.6))NOTATIONshould be used only on attributesand should only be used in schemas with notarget namespace.

Note: Because the lexical representations available for any given valueofNOTATION vary with context, this specification definesno·canonical representation· forNOTATION values.
3.3.19.1 Facets

TheNOTATION datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromNOTATIONmay alsospecify values for the following·constraining facets·:

TheNOTATION datatype has the following values for its·fundamental facets·:

The use of·length·,·minLength· and·maxLength·onNOTATION ordatatypes·derived· fromNOTATION isdeprecated.  Future versions of this specification mayremove these facets for this datatype.

previous sub-section3.4 Other Built-in Datatypes

        3.4.1normalizedString
            3.4.1.1Facets
            3.4.1.2Derived datatypes
        3.4.2token
            3.4.2.1Facets
            3.4.2.2Derived datatypes
        3.4.3language
            3.4.3.1Facets
        3.4.4NMTOKEN
            3.4.4.1Facets
            3.4.4.2Related datatypes
        3.4.5NMTOKENS
            3.4.5.1Facets
        3.4.6Name
            3.4.6.1Facets
            3.4.6.2Derived datatypes
        3.4.7NCName
            3.4.7.1Facets
            3.4.7.2Derived datatypes
        3.4.8ID
            3.4.8.1Facets
        3.4.9IDREF
            3.4.9.1Facets
            3.4.9.2Related datatypes
        3.4.10IDREFS
            3.4.10.1Facets
        3.4.11ENTITY
            3.4.11.1Facets
            3.4.11.2Related datatypes
        3.4.12ENTITIES
            3.4.12.1Facets
        3.4.13integer
            3.4.13.1Lexical representation
            3.4.13.2Canonical representation
            3.4.13.3Facets
            3.4.13.4Derived datatypes
        3.4.14nonPositiveInteger
            3.4.14.1Lexical representation
            3.4.14.2Canonical representation
            3.4.14.3Facets
            3.4.14.4Derived datatypes
        3.4.15negativeInteger
            3.4.15.1Lexical representation
            3.4.15.2Canonical representation
            3.4.15.3Facets
        3.4.16long
            3.4.16.1Lexical Representation
            3.4.16.2Canonical Representation
            3.4.16.3Facets
            3.4.16.4Derived datatypes
        3.4.17int
            3.4.17.1Lexical Representation
            3.4.17.2Canonical representation
            3.4.17.3Facets
            3.4.17.4Derived datatypes
        3.4.18short
            3.4.18.1Lexical representation
            3.4.18.2Canonical representation
            3.4.18.3Facets
            3.4.18.4Derived datatypes
        3.4.19byte
            3.4.19.1Lexical representation
            3.4.19.2Canonical representation
            3.4.19.3Facets
        3.4.20nonNegativeInteger
            3.4.20.1Lexical representation
            3.4.20.2Canonical representation
            3.4.20.3Facets
            3.4.20.4Derived datatypes
        3.4.21unsignedLong
            3.4.21.1Lexical representation
            3.4.21.2Canonical representation
            3.4.21.3Facets
            3.4.21.4Derived datatypes
        3.4.22unsignedInt
            3.4.22.1Lexical representation
            3.4.22.2Canonical representation
            3.4.22.3Facets
            3.4.22.4Derived datatypes
        3.4.23unsignedShort
            3.4.23.1Lexical representation
            3.4.23.2Canonical representation
            3.4.23.3Facets
            3.4.23.4Derived datatypes
        3.4.24unsignedByte
            3.4.24.1Lexical representation
            3.4.24.2Canonical representation
            3.4.24.3Facets
        3.4.25positiveInteger
            3.4.25.1Lexical representation
            3.4.25.2Canonical representation
            3.4.25.3Facets
        3.4.26yearMonthDuration
            3.4.26.1The Lexical Mapping
            3.4.26.2Facets
        3.4.27dayTimeDuration
            3.4.27.1The Lexical Space
            3.4.27.2Facets
        3.4.28dateTimeStamp
            3.4.28.1The Lexical Space
            3.4.28.2Facets

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

3.4.1 normalizedString

[Definition:]  normalizedStringrepresents white space normalized strings. The·value space· ofnormalizedString is theset of strings that do notcontain the carriage return (#xD), line feed (#xA) nor tab (#x9) characters. The·lexical space· ofnormalizedString is theset of strings that do notcontain the carriage return (#xD),line feed (#xA)nor tab (#x9) characters. The·base type· ofnormalizedString isstring.

3.4.1.1 Facets

ThenormalizedString datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromnormalizedStringmay alsospecify values for the following·constraining facets·:

ThenormalizedString datatype has the following values for its·fundamental facets·:

3.4.1.2 Derived datatypes

The following·built-in· datatype is·derived· fromnormalizedString

3.4.2 token

[Definition:]  tokenrepresents tokenized strings.The·value space· oftoken is theset of strings that do notcontain thecarriage return (#xD),line feed (#xA) nor tab (#x9) characters, that have noleading or trailing spaces (#x20) and that have no internal sequencesof two or more spaces.The·lexical space· oftoken is theset of strings that do not contain thecarriage return (#xD),line feed (#xA) nor tab (#x9) characters, that have noleading or trailing spaces (#x20) and that have no internal sequencesof two or more spaces.The·base type· oftoken isnormalizedString.

3.4.2.1 Facets

Thetoken datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromtokenmay alsospecify values for the following·constraining facets·:

Thetoken datatype has the following values for its·fundamental facets·:

3.4.2.2 Derived datatypes

The following·built-in· datatypes are·derived· fromtoken

3.4.3 language

[Definition:]  languagerepresents formal natural language identifiers, as defined by[BCP 47] (currently represented by[RFC 4646] and[RFC 4647])or its successor(s).The·value space·and·lexical space· oflanguageare the set of all strings that conform to the pattern

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

This is the set of stringsaccepted by the grammar given in[RFC 3066],which is now obsolete; the current specification of languagecodes is more restrictive.  The·base type· oflanguageistoken.
Note: The regular expression above provides the only normative constraint on the lexical and value spaces of this type. The additional constraints imposed on language identifiers by[BCP 47] and its successor(s), and in particular their requirement that language codes be registered with IANA or ISO if not given in ISO 639, are not part of this datatype as defined here.
Note:[BCP 47] specifies that language codes "are to be treated as case insensitive; thereexist conventions for capitalization of some of thesubtags, but these MUST NOT be taken to carry meaning."Since thelanguage datatype isderived fromstring, it inherits fromstring a one-to-one mapping from lexicalrepresentations to values. The literals 'MN' and'mn' (for Mongolian)therefore correspond to distinct values andhave distinct canonical forms. Users of this specification should beaware of this fact, the consequence of which is that thecase-insensitive treatment of language values prescribed by[BCP 47] does not follow from the definition ofthis datatype given here; applications which requirecase-insensitivity should make appropriate adjustments.
Note: The empty string is not a member of the·value space·oflanguage. Some constructs which normallytake language codes as their values, however, also allow theempty string. The attributexml:lang defined by[XML] is one example; there, the empty stringoverrides a value which would otherwise be inherited, butwithout specifying a new value.
One way to define the desired set of possible values isillustrated by the schema document for the XML namespaceathttp://www.w3.org/2001/xml.xsd, which defines theattributexml:lang as having a type which is a unionoflanguage and an anonymous type whoseonly 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/lang-tag-apps.htm for       further information.       The union allows for the 'un-declaration' 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>
3.4.3.1 Facets

Thelanguage datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromlanguagemay alsospecify values for the following·constraining facets·:

Thelanguage datatype has the following values for its·fundamental facets·:

3.4.4 NMTOKEN

[Definition:]  NMTOKEN representstheNMTOKEN attribute typefrom[XML]. The·value space· ofNMTOKEN is the set of tokens that·match·theNmtoken production in[XML]. The·lexical space· ofNMTOKEN is the set of strings that·match·theNmtoken production in[XML].  The·base type· ofNMTOKEN istoken.

It is·implementation-defined· whether animplementation of this specification supports theNMTOKEN production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

For compatibility (seeTerminology (§1.6)NMTOKENshould be used only on attributes.

3.4.4.1 Facets

TheNMTOKEN datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromNMTOKENmay alsospecify values for the following·constraining facets·:

TheNMTOKEN datatype has the following values for its·fundamental facets·:

3.4.4.2 Related datatypes

The following·built-in· datatype is·constructed· fromNMTOKEN

3.4.5 NMTOKENS

[Definition:]  NMTOKENSrepresents theNMTOKENS attributetype from[XML]. The·value space·ofNMTOKENS is the set of finite, non-zero-length sequences of·NMTOKEN·s.  The·lexical space·ofNMTOKENS is the set of space-separated lists of tokens,of which each token is in the·lexical space· ofNMTOKEN.  The·item type· ofNMTOKENS isNMTOKEN.NMTOKENS is derivedfrom·anySimpleType· in two steps: an anonymous list typeis defined, whose·item type· isNMTOKEN; this isthe·base type· ofNMTOKENS, which restrictsits value space to lists with at least one item.

For compatibility (seeTerminology (§1.6))NMTOKENSshould be used only on attributes.

3.4.5.1 Facets

TheNMTOKENS datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromNMTOKENSmay alsospecify values for the following·constraining facets·:

TheNMTOKENS datatype has the following values for its·fundamental facets·:

3.4.6 Name

[Definition:]  NamerepresentsXML Names.The·value space· ofName isthe set of all strings which·match· theName production of[XML].  The·lexical space· ofName is the set of all strings which·match·theName production of[XML]. The·base type· ofNameistoken.

It is·implementation-defined· whether animplementation of this specification supports theName production from[XML], or that from[XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

3.4.6.1 Facets

TheName datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromNamemay alsospecify values for the following·constraining facets·:

TheName datatype has the following values for its·fundamental facets·:

3.4.6.2 Derived datatypes

The following·built-in· datatype is·derived· fromName

3.4.7 NCName

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

It is·implementation-defined· whether animplementation of this specification supports theNCName production from[Namespaces in XML], or that from[Namespaces in XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

3.4.7.1 Facets

TheNCName datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromNCNamemay alsospecify values for the following·constraining facets·:

TheNCName datatype has the following values for its·fundamental facets·:

3.4.7.2 Derived datatypes

The following·built-in· datatypes are·derived· fromNCName

3.4.8 ID

[Definition:]  IDrepresents theID attribute type from[XML].  The·value space· ofID is the set of all strings that·match·theNCName production in[Namespaces in XML].  The·lexical space· ofID is the set of allstrings that·match· theNCName production in[Namespaces in XML].The·base type· ofID isNCName.

Note: It is·implementation-defined· whether animplementation of this specification supports theNCName production from[Namespaces in XML], or that from[Namespaces in XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

For compatibility (seeTerminology (§1.6)),IDshould be used only on attributes.

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

TheID datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromIDmay alsospecify values for the following·constraining facets·:

TheID datatype has the following values for its·fundamental facets·:

3.4.9 IDREF

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

Note: It is·implementation-defined· whether animplementation of this specification supports theNCName production from[Namespaces in XML], or that from[Namespaces in XML 1.0], or both. SeeDependencies on Other Specifications (§1.3).

For compatibility (seeTerminology (§1.6)) this datatypeshould be used only on attributes.

Note: Existence of referents for items validated asIDREF is not part of thisdatatype as defined here.When this specification is used in conjunction with[XSD 1.1 Part 1: Structures], referential integrity is enforced at adifferent level, not as part of datatype validity;seeValidation Rule: ValidationRoot Valid (ID/IDREF) in[XSD 1.1 Part 1: Structures].
3.4.9.1 Facets

TheIDREF datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromIDREFmay alsospecify values for the following·constraining facets·:

TheIDREF datatype has the following values for its·fundamental facets·:

3.4.9.2 Related datatypes

The following·built-in· datatype is·constructed· fromIDREF

3.4.10 IDREFS

[Definition:]  IDREFS represents theIDREFS attribute type from[XML].  The·value space· ofIDREFS is the set of finite, non-zero-length sequences ofIDREFs.The·lexical space· ofIDREFS is theset of space-separated lists of tokens, of which each token is in the·lexical space· ofIDREF. The·item type· ofIDREFS isIDREF.IDREFS is derivedfrom·anySimpleType· in two steps: an anonymous list typeis defined, whose·item type· isIDREF; this isthe·base type· ofIDREFS, which restrictsits value space to lists with at least one item.

For compatibility (seeTerminology (§1.6))IDREFSshould be used only on attributes.

Note: Existence of referents for items validated asIDREFS is notpart of this datatype as defined here. When this specification is used in conjunction with[XSD 1.1 Part 1: Structures], referential integrity is enforced at adifferent level, not as part of datatype validity;seeValidation Rule: Validation Root Valid (ID/IDREF) in[XSD 1.1 Part 1: Structures].
3.4.10.1 Facets

TheIDREFS datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromIDREFSmay alsospecify values for the following·constraining facets·:

TheIDREFS datatype has the following values for its·fundamental facets·:

3.4.11 ENTITY

[Definition:]  ENTITY represents theENTITY attribute type from[XML].  The·value space· ofENTITY is the set of all strings that·match·theNCName production in[Namespaces in XML] and have been declared as anunparsed entity inadocument type definition.The·lexical space· ofENTITY is the setof all strings that·match· theNCName production in[Namespaces in XML].The·base type· ofENTITY isNCName.

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

For compatibility (seeTerminology (§1.6))ENTITYshould be used only on attributes.

3.4.11.1 Facets

TheENTITY datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromENTITYmay alsospecify values for the following·constraining facets·:

TheENTITY datatype has the following values for its·fundamental facets·:

3.4.11.2 Related datatypes

The following·built-in· datatype is·constructed· fromENTITY

3.4.12 ENTITIES

[Definition:]  ENTITIESrepresents theENTITIES attributetype from[XML].  The·value space·ofENTITIES is the set of finite, non-zero-length sequences of·ENTITY· values that have been declared asunparsed entitiesin adocument type definition. The·lexical space· ofENTITIES is theset of space-separated lists of tokens, of which each token is in the·lexical space· ofENTITY. The·item type· ofENTITIES isENTITY.ENTITIES is derivedfrom·anySimpleType· in two steps: an anonymous list typeis defined, whose·item type· isENTITY; this isthe·base type· ofENTITIES, which restrictsits value space to lists with at least one item.

Note: The·value space· ofENTITIESis scoped to a specific instance document.

For compatibility (seeTerminology (§1.6))ENTITIESshould be used only on attributes.

3.4.12.1 Facets

TheENTITIES datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromENTITIESmay alsospecify values for the following·constraining facets·:

TheENTITIES datatype has the following values for its·fundamental facets·:

3.4.13 integer

[Definition:]  integer is·derived· fromdecimal by fixing thevalue of·fractionDigits· to be 0 anddisallowing the trailing decimal point. This results in the standardmathematical concept of the integer numbers.  The·value space· ofinteger is the infiniteset {...,-2,-1,0,1,2,...}.  The·base type· ofinteger isdecimal.

3.4.13.1 Lexical representation

integerhas a lexical representation consisting of a finite-length sequenceof 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.

3.4.13.2 Canonical representation

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

3.4.13.3 Facets

Theinteger datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Theinteger datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromintegermay alsospecify values for the following·constraining facets·:

Theinteger datatype has the following values for its·fundamental facets·:

3.4.13.4 Derived datatypes

The following·built-in· datatypes are·derived· frominteger

3.4.14 nonPositiveInteger

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

3.4.14.1 Lexical representation

nonPositiveIntegerhas a lexical representation consisting ofan optional preceding signfollowed by a non-emptyfinite-length sequence of decimal digits (#x30-#x39). The sign may be "+" or may be omitted only forlexical forms denoting zero; in all other lexical forms, the negativesign ('-')must be present. For example: -1, 0, -12678967543233, -100000.

3.4.14.2 Canonical representation

The·canonical representation· fornonPositiveIntegeris defined by prohibiting certain options from theLexical representation (§3.4.14.1). In the canonical form for zero, the signmustbeomitted.  Leading zeroes are prohibited.

3.4.14.3 Facets

ThenonPositiveInteger datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThenonPositiveInteger datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromnonPositiveIntegermay alsospecify values for the following·constraining facets·:

ThenonPositiveInteger datatype has the following values for its·fundamental facets·:

3.4.14.4 Derived datatypes

The following·built-in· datatype is·derived· fromnonPositiveInteger

3.4.15 negativeInteger

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

3.4.15.1 Lexical representation

negativeIntegerhas a lexical representation consistingof a negative sign ('-') followed by a non-empty finite-length sequence ofdecimal digits (#x30-#x39),at least one of whichmust be a digit other than '0'.  For example: -1, -12678967543233,-100000.

3.4.15.2 Canonical representation

The·canonical representation· fornegativeIntegeris defined by prohibiting certain options from theLexical representation (§3.4.15.1). Specifically, leading zeroes are prohibited.

3.4.15.3 Facets

ThenegativeInteger datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThenegativeInteger datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromnegativeIntegermay alsospecify values for the following·constraining facets·:

ThenegativeInteger datatype has the following values for its·fundamental facets·:

3.4.16 long

[Definition:]  longis·derived· frominteger by setting thevalue of·maxInclusive· to be 9223372036854775807and·minInclusive· to be -9223372036854775808.The·base type· oflong isinteger.

3.4.16.1 Lexical Representation

longhas a lexical representation consistingof an optional sign followed by a non-empty finite-lengthsequence of decimal digits (#x30-#x39).  Ifthe sign is omitted, "+" is assumed. For example: -1, 0,12678967543233, +100000.

3.4.16.2 Canonical Representation

The·canonical representation· forlongis defined by prohibiting certain options from theLexical Representation (§3.4.16.1).  Specifically, thethe optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.16.3 Facets

Thelong datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Thelong datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromlongmay alsospecify values for the following·constraining facets·:

Thelong datatype has the following values for its·fundamental facets·:

3.4.16.4 Derived datatypes

The following·built-in· datatype is·derived· fromlong

3.4.17 int

[Definition:]  intis·derived· fromlong by setting thevalue of·maxInclusive· to be 2147483647 and·minInclusive· to be -2147483648.  The·base type· ofint islong.

3.4.17.1 Lexical Representation

inthas a lexical representation consistingof an optional sign followed by a non-empty finite-lengthsequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.For example: -1, 0, 126789675, +100000.

3.4.17.2 Canonical representation

The·canonical representation· forintis defined by prohibiting certain options from theLexical Representation (§3.4.17.1).  Specifically, thethe optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.17.3 Facets

Theint datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Theint datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromintmay alsospecify values for the following·constraining facets·:

Theint datatype has the following values for its·fundamental facets·:

3.4.17.4 Derived datatypes

The following·built-in· datatype is·derived· fromint

3.4.18 short

[Definition:]  short is·derived· fromint by setting thevalue of·maxInclusive· to be 32767 and·minInclusive· to be -32768.  The·base type· ofshort isint.

3.4.18.1 Lexical representation

shorthas a lexical representation consistingof an optional sign followed by a non-empty finite-length sequence of decimaldigits (#x30-#x39).  If the sign is omitted, "+" is assumed.For example: -1, 0, 12678, +10000.

3.4.18.2 Canonical representation

The·canonical representation· forshortis defined by prohibiting certain options from theLexical representation (§3.4.18.1).  Specifically, thethe optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.18.3 Facets

Theshort datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Theshort datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromshortmay alsospecify values for the following·constraining facets·:

Theshort datatype has the following values for its·fundamental facets·:

3.4.18.4 Derived datatypes

The following·built-in· datatype is·derived· fromshort

3.4.19 byte

[Definition:]  byteis·derived· fromshortby setting the value of·maxInclusive· to be 127and·minInclusive· to be -128.The·base type· ofbyte isshort.

3.4.19.1 Lexical representation

bytehas a lexical representation consistingof an optional sign followed by a non-empty finite-lengthsequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.For example: -1, 0, 126, +100.

3.4.19.2 Canonical representation

The·canonical representation· forbyteis defined by prohibiting certain options from theLexical representation (§3.4.19.1).  Specifically, thethe optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.19.3 Facets

Thebyte datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Thebyte datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction frombytemay alsospecify values for the following·constraining facets·:

Thebyte datatype has the following values for its·fundamental facets·:

3.4.20 nonNegativeInteger

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

3.4.20.1 Lexical representation

nonNegativeIntegerhas a lexical representation consisting ofan optional sign followed by a non-empty finite-lengthsequence of decimal digits (#x30-#x39).  If the sign is omitted,the positive sign ('+') is assumed.If the sign is present, itmust be "+" except for lexical formsdenoting zero, which may be preceded by a positive ('+') or a negative ('-') sign.For example:1, 0, 12678967543233, +100000.

3.4.20.2 Canonical representation

The·canonical representation· fornonNegativeIntegeris defined by prohibiting certain options from theLexical representation (§3.4.20.1).  Specifically, thethe optional "+" sign is prohibited and leading zeroes are prohibited.

3.4.20.3 Facets

ThenonNegativeInteger datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThenonNegativeInteger datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromnonNegativeIntegermay alsospecify values for the following·constraining facets·:

ThenonNegativeInteger datatype has the following values for its·fundamental facets·:

3.4.20.4 Derived datatypes

The following·built-in· datatypes are·derived· fromnonNegativeInteger

3.4.21 unsignedLong

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

3.4.21.1 Lexical representation

unsignedLonghas a lexical representation consisting ofan optional sign followed by anon-emptyfinite-length sequence of decimal digits (#x30-#x39). If the sign is omitted, the positive sign('+') is assumed.  If the sign is present, itmustbe'+' except for lexical forms denoting zero, which maybe preceded by a positive ('+') or a negative('-') sign. For example: 0, 12678967543233,100000.

3.4.21.2 Canonical representation

The·canonical representation· forunsignedLongis defined by prohibiting certain options from theLexical representation (§3.4.21.1).  Specifically,leading zeroes are prohibited.

3.4.21.3 Facets

TheunsignedLong datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

TheunsignedLong datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromunsignedLongmay alsospecify values for the following·constraining facets·:

TheunsignedLong datatype has the following values for its·fundamental facets·:

3.4.21.4 Derived datatypes

The following·built-in· datatype is·derived· fromunsignedLong

3.4.22 unsignedInt

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

3.4.22.1 Lexical representation

unsignedInthas a lexical representation consistingof an optional sign followed by anon-emptyfinite-length sequence of decimal digits (#x30-#x39). If the sign is omitted, the positive sign('+') is assumed.  If the sign is present, itmustbe'+' except for lexical forms denoting zero, which maybe preceded by a positive ('+') or a negative('-') sign. For example: 0,1267896754, 100000.

3.4.22.2 Canonical representation

The·canonical representation· forunsignedIntis defined by prohibiting certain options from theLexical representation (§3.4.22.1).  Specifically,leading zeroes are prohibited.

3.4.22.3 Facets

TheunsignedInt datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

TheunsignedInt datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromunsignedIntmay alsospecify values for the following·constraining facets·:

TheunsignedInt datatype has the following values for its·fundamental facets·:

3.4.22.4 Derived datatypes

The following·built-in· datatype is·derived· fromunsignedInt

3.4.23 unsignedShort

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

3.4.23.1 Lexical representation

unsignedShorthas a lexical representation consisting ofan optional sign followed by anon-empty finite-lengthsequence of decimal digits (#x30-#x39). If the sign is omitted, the positive sign('+') is assumed.  If the sign is present, itmustbe'+' except for lexical forms denoting zero, which maybe preceded by a positive ('+') or a negative('-') sign.  For example: 0, 12678, 10000.

3.4.23.2 Canonical representation

The·canonical representation· forunsignedShortis defined by prohibiting certain options from theLexical representation (§3.4.23.1). Specifically, the leading zeroes are prohibited.

3.4.23.3 Facets

TheunsignedShort datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

TheunsignedShort datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromunsignedShortmay alsospecify values for the following·constraining facets·:

TheunsignedShort datatype has the following values for its·fundamental facets·:

3.4.23.4 Derived datatypes

The following·built-in· datatype is·derived· fromunsignedShort

3.4.24 unsignedByte

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

3.4.24.1 Lexical representation

unsignedBytehas a lexical representation consisting ofan optional sign followed by anon-empty finite-lengthsequence of decimal digits (#x30-#x39). If the sign is omitted, the positive sign('+') is assumed.  If the sign is present, itmustbe '+' except for lexical forms denoting zero, which maybe preceded by a positive ('+') or a negative('-') sign.  For example: 0, 126, 100.

3.4.24.2 Canonical representation

The·canonical representation· forunsignedByteis defined by prohibiting certain options from theLexical representation (§3.4.24.1).  Specifically,leading zeroes are prohibited.

3.4.24.3 Facets

TheunsignedByte datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

TheunsignedByte datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromunsignedBytemay alsospecify values for the following·constraining facets·:

TheunsignedByte datatype has the following values for its·fundamental facets·:

3.4.25 positiveInteger

[Definition:]  positiveInteger is·derived· fromnonNegativeInteger by setting the value of·minInclusive· to be 1.  This results in the standardmathematical concept of the positive integer numbers. The·value space· ofpositiveIntegeris the infinite set {1,2,...}.  The·base type· ofpositiveInteger isnonNegativeInteger.

3.4.25.1 Lexical representation

positiveIntegerhas a lexical representation consistingof an optional positive sign ('+') followed by a non-empty finite-lengthsequence of decimal digits (#x30-#x39),at least one of whichmust be a digit other than '0'. For example: 1, 12678967543233, +100000.

3.4.25.2 Canonical representation

The·canonical representation· forpositiveIntegeris defined by prohibiting certain options from theLexical representation (§3.4.25.1).  Specifically, theoptional "+" sign is prohibited and leading zeroes are prohibited.

3.4.25.3 Facets

ThepositiveInteger datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThepositiveInteger datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction frompositiveIntegermay alsospecify values for the following·constraining facets·:

ThepositiveInteger datatype has the following values for its·fundamental facets·:

3.4.26 yearMonthDuration

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

Note: The always-zero·seconds· is formally retained in order thatyearMonthDuration's (abstract) value space truly be a subset of that ofduration  An obvious implementation optimization is to ignore the zero and implementyearMonthDuration values simply asinteger values.
3.4.26.1 TheyearMonthDuration Lexical Mapping
The lexical space is reduced from that ofduration bydisallowingduDayFrag andduTimeFragfragments in the·lexical representations·.
TheyearMonthDuration LexicalRepresentation
[42]  yearMonthDurationLexicalRep ::= '-'? 'PduYearMonthFrag

The lexical space ofyearMonthDuration consists ofstrings which match the regular expression'-?P((([0-9]+Y)([0-9]+M)?)|([0-9]+M))' or theexpression '-?P[0-9]+(Y([0-9]+M)?|M)', but theformal definition ofyearMonthDuration uses asimpler 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·ofduration to strings with no day, hour,minute, or seconds fields.

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

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

TheyearMonthDuration datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

TheyearMonthDuration datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromyearMonthDurationmay alsospecify values for the following·constraining facets·:

TheyearMonthDuration datatype has the following values for its·fundamental facets·:

Note: Theordered facet has the valuepartial even though the datatype isin fact totally ordered, because (as explained inordered (§4.2.1)),the value of that facet is unchanged by derivation.

3.4.27 dayTimeDuration

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

3.4.27.1 ThedayTimeDuration Lexical Space

The lexical space is reduced from that ofduration bydisallowingduYearFrag andduMonthFragfragments in the·lexical representations·.

ThedayTimeDuration Lexical Representation
[43]  dayTimeDurationLexicalRep ::= '-'? 'PduDayTimeFrag

The lexical space ofdayTimeDuration consists ofstrings in the·lexical space· ofduration 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 secondsfields.

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

3.4.27.2 Facets

ThedayTimeDuration datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

ThedayTimeDuration datatype has the following·constraining facets· with the values shown; thesefacetsmay be specifiedin the derivation of new types, if thevalue given is at least as restrictive as the one shown:

Datatypes derived byrestriction fromdayTimeDurationmay alsospecify values for the following·constraining facets·:

ThedayTimeDuration datatype has the following values for its·fundamental facets·:

Note: Theordered facet has the valuepartial even though the datatype isin fact totally ordered, because (as explained inordered (§4.2.1)),the value of that facet is unchanged by derivation.

3.4.28 dateTimeStamp

[Definition:]   ThedateTimeStamp datatype is·derived· fromdateTime by giving the valuerequired to itsexplicitTimezone facet. The result is that all values ofdateTimeStamp are required to have explicit time zone offsetsand the datatype is totally ordered.

3.4.28.1 ThedateTimeStamp Lexical Space

As a consequence of requiring an explicit time zone offset, thelexical space ofdateTimeStamp is reduced from thatofdateTime by requiring atimezoneFragfragment in the·lexical representations·.

ThedateTimeStamp Lexical Representation
[44]  dateTimeStampLexicalRep ::=yearFrag '-monthFrag '-dayFrag 'T' ((hourFrag ':minuteFrag ':secondFrag) |endOfDayFrag)timezoneFrag  Constraint:  Day-of-month Representations
Note: For details of theDay-of-month Representations (§3.3.7.2) constraint, seedateTime, from which the constraint is inherited.

In other words, the lexical space ofdateTimeStamp consists of strings which are in the·lexical space· ofdateTime and whichalso match the regular expression'.*(Z|(\+|-)[0-9][0-9]:[0-9][0-9])'.

The·lexical mapping· is that ofdateTime restricted to thedateTimeStamp lexical space.

The·canonical mapping· is that ofdateTime restricted to thedateTimeStamp value space.

3.4.28.2 Facets

ThedateTimeStamp datatype and all datatypes derived from it by restriction have thefollowing·constraining facets· withfixed values; thesefacetsmust not be changed from the values shown:

Datatypes derived byrestriction fromdateTimeStampmay alsospecify values for the following·constraining facets·:

ThedateTimeStamp datatype has the following values for its·fundamental facets·:

Note: Theordered facet has the valuepartial even though the datatype isin fact totally ordered, because (as explained inordered (§4.2.1)),the value of that facet is unchanged by derivation.

4 Datatype components

The preceding sections of thisspecification have described datatypes in a way largely independent of their use in the particular context ofschema-aware 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 oftheschemacomponentabstraction introduced there. The account of datatypes given in thisspecification is also intended to be useful in other contexts.Any specification or other formal system intending to use datatypes asdefined above, particularly if definition of new datatypes viafacet-based restriction is envisaged, will need to provide analogousmechanisms for some, but not necessarily all, of what follows below.For example, the{target namespace} and{final} properties are required because ofparticular aspects of[XSD 1.1 Part 1: Structures] which are notin principle necessary for the use of datatypes as defined here.

The following sections provide full details on the properties andsignificance of each kind of schema component involved in datatypedefinitions. For each property, the kinds of values it is allowed to have isspecified.  Any property not identified as optional is required tobe present; optional properties which are not present haveabsent 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 isnot the same asabsent.Any property value identified as a superset or a subset of some set maybe equal to that set, unless a proper superset or subset is explicitlycalled for.

For more information on the notion of schema components,seeSchema Component Detailsof[XSD 1.1 Part 1: Structures].

[Definition:]  Acomponent may be referred to as theowner of its properties, and of the values ofthose properties.

next sub-section4.1 Simple Type Definition

        4.1.1The Simple Type Definition Schema Component
        4.1.2XML Representation of Simple Type Definition Schema Components
        4.1.3Constraints on XML Representation of Simple Type Definition
        4.1.4Simple Type Definition Validation Rules
        4.1.5Constraints on Simple Type Definition Schema Components
        4.1.6Built-in Simple Type Definitions

Simple Type Definitions provide for:

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

4.1.1 The Simple Type Definition Schema Component

The Simple Type Definition schema component has the following properties:

Schema Component:Simple Type Definition
{annotations}
A sequence ofAnnotation components.
{name}
An xs:NCName value. Optional.
{target namespace}
An xs:anyURI value. Optional.
{final}

A subset of{restriction,extension,list,union}

{context}
Required if{name} isabsent, otherwisemust beabsent
{base type definition}
{facets}
A set ofConstraining Facet components.
{fundamental facets}
A set ofFundamental Facet components.
{variety}
One of {atomic,list,union}. Required for allSimple Type Definitions except·anySimpleType·, in which it isabsent.
{primitive type definition}
ASimple Type Definition component. With one exception, required if{variety} isatomic, otherwisemust beabsent. The exceptionis·anyAtomicType·, whose{primitive type definition} isabsent.

Ifnotabsent,must be a·primitive· built-in definition.

{item type definition}
ASimple Type Definition component. Required if{variety} islist, otherwisemust beabsent.

The value of this propertymust be a primitive or ordinary simple type definitionwith{variety} =atomic,or an ordinary simple type definition with{variety} =unionwhose basic members are all atomic; the valuemust not itself be a list type (have{variety} =list)or have any basic members which are list types.

{member type definitions}
A sequence of primitive or ordinarySimple Type Definition components.

Must be present (butmay be empty) if{variety} isunion, otherwisemust beabsent.

The sequence may contain any primitive or ordinary simple type definition, butmust not contain any special type definitions.

Simple type definitions areidentified by their{name} and{target namespace}.  Except foranonymousSimple Type Definitions (thosewith no{name}),Simple Type Definitionsmust be uniquely identified within aschema.Within a valid schema, eachSimple Type Definition uniquely determinesone datatype. The·value space·,·lexical space·,·lexical mapping·, etc., of aSimple Type Definitionare the·value space·,·lexical space·, etc., of the datatypeuniquely determined (or "defined") by thatSimple 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 subsetof 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)finite-length sequences of values from the·value space· of{item type definition}. If{variety} is·union·then the·value space· of the datatypedefined will be a subset(possibly an improper subset) of the union of the·value spaces· of eachSimple Type Definition in{member type definitions}.

If{variety} is·atomic·then the{variety} of{base type definition}mustbe·atomic·,unless the{base type definition}isanySimpleType.If{variety} is·list·then the{variety} of{item type definition}mustbe 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}mustbe a list ofSimple Type Definitions.

The{facets} propertydetermines the·value space· and·lexical space· of the datatypebeing defined by imposing constraints which are to be satisfied by all valid values and·lexical representations·.

The{fundamental facets} property provides somebasic 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 usedin deriving other types; the explicit valuesrestriction,list andunion prevent further derivations ofSimple Type Definitionsby·facet-based restriction·,·list· and·union· respectively; the explicit valueextension prevents any derivation ofComplex Type Definitions by extension.

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

4.1.2 XML Representation of Simple Type Definition Schema Components

The XML representation for aSimple Type Definition schema componentis a<simpleType> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:simpleType Element Information Item et al.
<simpleType
  final = (#all | List of (list |union |restriction |extension))
  id =ID
  name =NCName
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?, (restriction |list |union))
</simpleType>
<restriction
  base =QName
  id =ID
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?, (simpleType?, (minExclusive |minInclusive |maxExclusive |maxInclusive |totalDigits |fractionDigits |length |minLength |maxLength |enumeration |whiteSpace |pattern |assertion |explicitTimezone |{any with namespace: ##other})*))
</restriction>
<list
  id =ID
  itemType =QName
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?,simpleType?)
</list>
<union
  id =ID
  memberTypes = List ofQName
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?,simpleType*)
</union>
Simple Type DefinitionSchema Component
Property
Representation
 
Theactual value of thename[attribute], if present on the<simpleType> element,otherwiseabsent
 
Theactual value of thetargetNamespace[attribute]of the parentschema element information item, if present,otherwiseabsent.
 
The appropriatecase among the following:
1Ifthe<restriction> alternative is chosen,thenthe type definitionresolved to by theactual value of thebase[attribute] of<restriction>, if present, otherwise thetype definition corresponding to the<simpleType> amongthe[children] of<restriction>.
2Ifthe<list> or<union> alternative is chosen,then·anySimpleType·.
 
A subset of{restriction,extension,list,union}, determined as follows.[Definition:]  LetFS betheactual value of thefinal[attribute], if present, otherwise theactual value of thefinalDefault[attribute] of the ancestorschema element, if present, otherwise the empty string. Then the property value isthe appropriatecase among the following:
1If·FS· is the empty string,thenthe empty set;
2If·FS· is '#all',then{restriction,extension,list,union};
3otherwiseConsider·FS· asa space-separated list, and includerestriction if'restriction' is in that list, and similarly forextension,list andunion.
 
The appropriatecase among the following:
1Ifthename[attribute] is present,thenabsent
2otherwise the appropriatecase among the following:
2.1Ifthe parent element information item is<attribute>,thenthe correspondingAttribute Declaration
2.2Ifthe parent element information item is<element>,thenthe correspondingElement Declaration
2.3Ifthe parent element information item is<list> or<union>,thentheSimple Type Definitioncorresponding to the grandparent<simpleType> element information item
2.4otherwise(the parent element information item is<restriction>), the appropriatecase among the following:
2.4.1Ifthe grandparent element information item is<simpleType>,thentheSimple Type Definitioncorresponding to the grandparent
2.4.2otherwise(the grandparent element information item is<simpleContent>), theSimple Type Definition which is the{content type} of theComplex Type Definitioncorresponding to the great-grandparent<complexType> element information item.
 
If the<list> alternative is chosen,thenlist, otherwise if the<union> alternative ischosen, thenunion, otherwise (the<restriction>alternative is chosen) the{variety}of the{base type definition}.
 
The appropriatecase among the following:
1Ifthe<restriction> alternative is chosen,thenthe set ofConstraining Facet components obtained byoverlayingthe{facets} of the{base type definition} with theset ofConstraining Facet components corresponding to those[children] of<restriction> which specify facets, asdefined inSchema Component Constraint: Simple Type Restriction (Facets).
2Ifthe<list> alternative is chosen,thena set with one member, awhiteSpace facet with{value} =collapse and{fixed} =true.
3otherwisethe empty set
 
 
Theannotation mapping of the set of elements containing the<simpleType>, and the<restriction>, the<list>, or the<union>[child], whichever is present, as defined in sectionXML Representation of Annotation Schema Components of[XSD 1.1 Part 1: Structures].
[Definition:]  Theancestors of atype definition are its{base type definition} and the·ancestors· of its{base type definition}.(The ancestors of aSimple Type DefinitionT in the type hierarchy are themselvestype definitions; they are distinct fromthe XML elements which may be ancestors, in the XML documenthierarchy, of the<simpleType> element which declaresT.)
If the{variety} isatomic, the following additional propertymapping also applies:
Property
Representation
 
From among the·ancestors· of thisSimple Type Definition, thatSimple Type Definition which corresponds to a·primitive· datatype.
Example
An electronic commerce schema might define a datatype called'SKU'(the barcode number that appears on products) from the·built-in· datatypestring bysupplying a value for the·pattern· facet.
<simpleType name='SKU'>    <restriction base='string'>      <pattern value='\d{3}-[A-Z]{2}'/>    </restriction></simpleType>
In this case, 'SKU' is the name of the new·user-defined· datatype,string isits·base type· and·pattern· is the facet.
If the{variety} islist, the followingadditional property mappings also apply:
Property
Representation
 
The appropriatecase among the following:
1Ifthe{base type definition} is·anySimpleType·,thentheSimple Type Definition (a)resolved to by theactual value of theitemType[attribute] of<list>,or (b) corresponding to the<simpleType> amongthe[children] of<list>, whichever is present.
Note: In thiscase, a<list> element will invariably be present; it willinvariably have either anitemType[attribute] or a<simpleType>[child], but not both.
2otherwise(that is, the{base type definition} is not·anySimpleType·), the{item type definition} of the{base type definition}.
Note: In this case, a<restriction> element will invariably be present.
Example
A system might want to store lists of floating point values.
<simpleType name='listOfFloat'>  <list itemType='float'/></simpleType>
In this case,listOfFloat is the name of the new·user-defined· datatype,float is its·item type· and·list· is thederivation method.
If the{variety} isunion, the followingadditional property mappings also apply:
Property
Representation
 
The appropriatecase among the following:
1Ifthe{base type definition} is·anySimpleType·,thenthe sequence of (a) theSimple Type Definitions(a)resolved to by the items in theactual value of thememberTypes[attribute] of<union>, ifany, and (b) those corresponding to the<simpleType>samong the[children] of<union>, if any, in order.
Note: In this case, a<union> element will invariably bepresent; it will invariably have either amemberTypes[attribute] or one or more<simpleType>[children],or both.
2otherwise(that is, the{base type definition} is not·anySimpleType·), the{member type definitions} of the{base type definition}.
Note: In this case, a<restriction> element will invariablybe present.
Example
As an example, taken from a typical display oriented text markup language,one might want to express font sizes as an integer between 8 and 72, or withone of the tokens "small", "medium" or "large".  The·union·Simple Type Definitionbelow would accomplish that.
<xs:attribute name="size">  <xs:simpleType>    <xs:union>      <xs:simpleType>        <xs:restriction base="xs:positiveInteger">          <xs:minInclusive value="8"/>          <xs:maxInclusive value="72"/>        </xs:restriction>      </xs:simpleType>      <xs:simpleType>        <xs:restriction base="xs:NMTOKEN">          <xs:enumeration value="small"/>          <xs:enumeration value="medium"/>          <xs:enumeration value="large"/>        </xs:restriction>      </xs:simpleType>    </xs:union>  </xs:simpleType></xs:attribute>
<p><font size='large'>A header</font></p><p><font size='12'>this is a test</font></p>

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

4.1.3 Constraints on XML Representation of Simple Type Definition

Schema Representation Constraint: itemType attribute or simpleType child
Either theitemType[attribute] or the<simpleType>[child] of the<list> elementmustbe present, but not both.
Schema Representation Constraint: base attribute or simpleType child
Either thebase[attribute] or thesimpleType[child] of the<restriction>elementmustbe present, but not both.
Schema Representation Constraint: memberTypes attribute or simpleType children
Either thememberTypes[attribute] of the<union>elementmustbe non-empty ortheremustbe at least onesimpleType[child].

4.1.4 Simple Type Definition Validation Rules

Validation Rule: Facet Valid
A value in a·value space· is facet-valid withrespect to a·constraining facet· component if and only if:
1the value is facet-valid with respect to the particular·constraining facet· as specified below.
Validation Rule: Datatype Valid
A·literal· is datatype-valid with respect to aSimple Type Definitionif and only if it is a member of the·lexical space· of thecorresponding datatype.
Note: Since every value in the·value space· is denoted by some·literal·, and every·literal· in the·lexical space· maps tosome value, the requirement that the·literal· be in the·lexical space· entails the requirement that the value itmaps to should fulfill all of the constraints imposed by the{facets} of the datatype. Ifthe datatype is a·list·, the Datatype Valid constraint alsoentails that each whitespace-delimited token in the listbe datatype-valid against the·item type· of the list.If the datatype is a·union·, the Datatype Valid constraintentails that the·literal· be datatype-valid against atleast one of the·member types·.
That is, the constraints onSimple Type Definitions and ondatatype·derivation· defined in this specification have as aconsequence that a·literal·L is datatype-valid withrespect to aSimple Type DefinitionT if and only ifeitherT corresponds to a·special· datatype orall of the following are true:
1If there is apattern in{facets}, thenL ispattern valid (§4.3.4.4) with respect to thepattern.If there are other·lexical· facetsin{facets}, thenL is facet-valid with respectto them.
2The appropriate case among the following is true:
2.1If the{variety} ofT is·atomic·,thenL is in the·lexical space· of the{primitive type definition} ofT, as defined in theappropriate documentation. LetV be themember of the·value space· of the{primitive type definition} ofT mapped to byL,as defined in the appropriate documentation.
Note: For·built-in··primitives·, the "appropriate documentation" is the relevantsection of this specification. For·implementation-defined··primitives·,it is the normative specification of the·primitive·, whichwill typically be included in, or referred to from, theimplementation's documentation.
2.2If the{variety} ofT is·list·, theneach space-delimited substring ofL is Datatype Valid withrespect to the{item type definition} ofT. LetV be the sequence consisting of the values identified byDatatype Valid for each of those substrings, in order.
2.3If the{variety} ofT is·union·,thenL is Datatype Valid with respect to at least onemember of the{member type definitions}ofT. LetB be the·active basic member· ofT forL. LetV be the value identified by Datatype Valid forL with respect toB.
3V, as determined by theappropriate sub-clause of clause2 above,isFacet Valid (§4.1.4) with respect to each member of the{facets} ofT which is a·value-based· (and not a·pre-lexical·or·lexical·)facet.
Note thatwhiteSpace facets andother·pre-lexical· facetsdo not take part in checking DatatypeValid. In cases where this specification is used in conjunction withschema-validation of XML documents, such facets are used tonormalize infoset valuesbefore the normalized resultsare checked for datatype validity. In the case of unions the·pre-lexical· facets to use are those associated withB inclause2.3 above.When more than one·pre-lexical· facet applies, thewhiteSpace facet is applied first; the order in which·implementation-defined· facetsare applied is·implementation-defined·.

4.1.5 Constraints on Simple Type Definition Schema Components

Schema Component Constraint: Applicable Facets
The·constraining facets· which are allowed to be members of{facets}depend onthe{variety} and{primitive type definition} of the type, asfollows:

If{variety} isabsent, then no facets are applicable. (This is true foranySimpleType.)

If{variety} islist, then the applicable facets areassertions,length,minLength,maxLength,pattern,enumeration, andwhiteSpace.

If{variety} isunion, then the applicable facets arepattern,enumeration, andassertions.

If{variety} isatomic, and{primitive type definition} isabsent then no facets are applicable. (This is true foranyAtomicType.)

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

{primitive type definition}applicable{facets}
stringlength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
booleanpattern,whiteSpace,assertions
floatpattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions
doublepattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions
decimaltotalDigits,fractionDigits,pattern,whiteSpace,enumeration,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions
durationpattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions
dateTimepattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
timepattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
datepattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
gYearMonthpattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
gYearpattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
gMonthDaypattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
gDaypattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
gMonthpattern,enumeration,whiteSpace,maxInclusive,maxExclusive,minInclusive,minExclusive,assertions,explicitTimezone
hexBinarylength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
base64Binarylength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
anyURIlength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
QNamelength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
NOTATIONlength,minLength,maxLength,pattern,enumeration,whiteSpace,assertions
Note: For any·implementation-defined· primitive types, it is·implementation-defined· which constraining facets areapplicable to them.
Similarly, for any·implementation-defined· constraining facets,it is·implementation-defined· which·primitives· theyapply to.

4.1.6 Built-in Simple Type Definitions

TheSimple Type Definition ofanySimpleType ispresent in every schema.  It has the following properties:

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

The definition ofanySimpleTypeis the root of the Simple Type Definitionhierarchy;as such it mediates between the other simple type definitions, which all eventually trace back to it via their{base type definition} properties, and the definition ofanyType, which isits{base type definition}.

TheSimple Type Definition ofanyAtomicType ispresent in every schema.  It has the following properties:

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

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

Property
Value
[as appropriate]
'http://www.w3.org/2001/XMLSchema'
The empty set
atomic
{awhiteSpace facet with{value} =collapse and{fixed} =true in all cases exceptstring, which has{value} =preserve and{fixed} =false}
[as appropriate]
absent
The empty sequence
·Implementation-defined··primitives·must have aSimple Type Definition withthe values shown above, with the following exceptions.
  1. The{facets} propertymust contain awhiteSpace facet, the value of which is·implementation-defined·. Itmay contain other facets,whether defined in this specification or·implementation-defined·.
  2. The value of{annotations}may be empty, but need not be.
Note: It is a consequence of the rule just given that each·implementation-defined··primitive· will have anexpanded nameby which it can be referred to.
Note:·Implementation-defined· datatypes will normally have a valueother than 'http://www.w3.org/2001/XMLSchema' for the{target namespace}property. That namespace is controlled by the W3C anddatatypes will be added to it only by W3C or its designees.

Similarly,Simple Type Definitions for all the built-in·ordinary·datatypes are present by definition in every schema, with propertiesas specified inOther Built-in Datatypes (§3.4) and as representedin XML inIllustrative XML representations for the built-in ordinary type definitions (§C.2).

Property
Value
[as appropriate]
'http://www.w3.org/2001/XMLSchema'
[as specified in the appropriatesub-section ofOther Built-in Datatypes (§3.4)]
The empty set
[atomic orlist, as specified in the appropriatesub-section ofOther Built-in Datatypes (§3.4)]
[as specified in the appropriatesub-section ofOther Built-in Datatypes (§3.4)]
[as specified in the appropriatesub-section ofOther Built-in Datatypes (§3.4)]
absent
if{variety} isatomic, thenabsent, otherwise as specified in the appropriatesub-section ofOther Built-in Datatypes (§3.4)]
As shown in the XML representationsof the ordinary built-in datatypes inIllustrative XML representations for the built-in ordinary type definitions (§C.2)

previous sub-sectionnext sub-section4.2 Fundamental Facets

        4.2.1ordered
            4.2.1.1The ordered Schema Component
        4.2.2bounded
            4.2.2.1The bounded Schema Component
        4.2.3cardinality
            4.2.3.1The cardinality Schema Component
        4.2.4numeric
            4.2.4.1The numeric Schema Component

[Definition:]  Eachfundamental facet is aschema component that provides a limited piece of information aboutsome aspect of each datatype.  All·fundamentalfacet· components are defined in this section. For example,cardinality is a·fundamental facet·.  Most·fundamental facets· are given a valuefixed with each primitive datatype's definition, and this value is not changed bysubsequent·derivations· (even whenit would perhaps be reasonable to expect an application to give a more accurate value basedon the constraining facets used to define the·derivation·).  Thecardinality andbounded facetsare exceptions to this rule; their values may change as a result of certain·derivations·.

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

A·fundamental facet· can occur onlyin the{fundamental facets} of aSimple Type Definition, and this is theonly place where·fundamental facet· componentsoccur.    Each kind of·fundamental facet·component occurs (once) in eachSimple Type Definition's{fundamental facets} set.

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

4.2.1 ordered

For some datatypes,this document specifies an order relation for their value spaces (seeOrder (§2.2.3)); theordered facet reflectsthis. It takes the valuestotal,partial,andfalse, with the meanings described below.For the·primitive· datatypes, the value of theordered facet isspecified inFundamental Facets (§F.1). For·ordinary· datatypes, the value is inherited without changefrom the·base type·.For a·list·, the value is alwaysfalse;for a·union·, the value is computed as described below.

Afalse value means no order is prescribed; atotal valueassures that the prescribed order is a totalorder; apartial value means that the prescribed order is a partialorder, but not (for the primitive type in question) a total order.

Note: The valuefalse in theordered facet does notmean no partial or total orderingexists for the valuespace, only that none is specified by this document for use inchecking upper and lower bounds. Mathematically, any set of valuespossesses at least onetrivial partial ordering, in which every valuepair that is not equal is incomparable.
Note: When new datatypes are derived from datatypes with partial orders,the constraints imposed can sometimes result in a value spacefor which the ordering is total, or trivial. The value of theordered facet is not, however, changed to reflect this.The valuepartial should therefore be interpreted withappropriate caution.

[Definition:]  A·value space·, and hence a datatype, is said to beordered if somemembers of the·value space· are drawn from a·primitive· datatype for which the table inFundamental Facets (§F.1) specifiesthe valuetotal orpartial for theordered facet.

Note: Some of the "real-world" datatypes which are the basis for those defined hereinare ordered in some applications, even though no order is prescribed for schema-processingpurposes.  For example,boolean is sometimes ordered, andstringand·list· datatypes·constructed· fromordered·atomic· datatypes are sometimes given "lexical"orderings.  They arenot ordered for schema-processing purposes.
4.2.1.1 The ordered Schema Component
Schema Component:ordered, a kind ofFundamental Facet
{value}
One of {false,partial,total}. Required.
{value} depends on the·owner's·{variety},{facets}, and{member type definitions}.The appropriatecase among the followingmust be true:
1Ifthe·owner's·{variety} isatomic,then the appropriatecase among the followingmust be true:
2Ifthe·owner's·{variety} islist,then{value} isfalse.
3otherwisethe·owner's·{variety} isunion;the appropriatecase among the followingmust be true:
3.1Ifevery·basic member· of the·owner·has{variety} atomic and has the same{primitive type definition},then{value} is the same as theordered component's{value} in that primitive type definition's{fundamental facets}.
3.2Ifeach member of the·owner's·{member type definitions} has anorderedcomponent in its{fundamental facets} whose{value} isfalse,then{value} isfalse.
3.3otherwise{value} ispartial.

4.2.2 bounded

Some ordered datatypes have the property thatthere is one value greater than or equal to every other value, andanother that isless than or equal to every other value.  (In the case of·ordinary·datatypes, these two values arenot necessarily in the value space of the derived datatype,but they will always bein the valuespace of the primitive datatype from which they have been derived.)Thebounded facet value isboolean and isgenerallytrue for suchbounded datatypes. However, it will remainfalse when the mechanism for imposingsuch a bound is difficult to detect, as, for example, when theboundedness occurs because of derivation using apatterncomponent.

4.2.2.1 The bounded Schema Component
Schema Component:bounded, a kind ofFundamental Facet
{value}
An xs:boolean value. Required.

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

When the·owner·is·primitive·,{value} is as specified in thetable inFundamental Facets (§F.1).  Otherwise, when the·owner's·{variety} isatomic,if one ofminInclusive orminExclusiveand one ofmaxInclusive ormaxExclusiveare members ofthe·owner's·{facets} set, then{value} istrue;otherwise{value} isfalse.

When the·owner's·{variety} islist,{value} isfalse.

When the·owner's·{variety} isunion, if{value} istrue for everymember of the·owner's·{member type definitions} set and all of the·owner's··basic members· have the same{primitive type definition}, then{value} istrue; otherwise{value} isfalse.

4.2.3 cardinality

Every value space has a specific number of members.  This number can be characterized asfinite orinfinite.  (Currently there are no datatypes with infinitevalue spaces larger thancountable.)  Thecardinality facet value iseitherfinite orcountably infinite and is generallyfinite for datatypes withfinite value spaces.  However, it will remaincountably infinite when the mechanism forcausing finiteness is difficult to detect, as, for example, when finiteness occurs because of aderivation using apattern component.

4.2.3.1 The cardinality Schema Component
Schema Component:cardinality, a kind ofFundamental Facet
{value}
One of {finite,countably infinite}. Required.

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

When the·owner· is·primitive·,{value} is as specified in thetable inFundamental Facets (§F.1).  Otherwise, whenthe·owner's·{variety} isatomic,{value}iscountably infinite unlessany of the followingconditions are true, in which case{value} isfinite:
  1. at least one oflength,maxLength,ortotalDigits is a member of the·owner's·{facets} set,
  2. all of the following are true:
    1. one ofminInclusive orminExclusiveis a member of the·owner's·{facets} set
    2. one ofmaxInclusive ormaxExclusiveis a member of the·owner's·{facets} set
    3. either of the following are true:
      1. fractionDigits is a member of the·owner's·{facets} set

When the·owner's·{variety} islist,iflength or bothminLength andmaxLengthare members of the·owner's·{facets} setand the·owner's·{item type definition}'scardinality{value} isfinitethen{value} isfinite;otherwise{value} iscountably infinite.

When the·owner's·{variety} isunion,ifcardinality's{value} isfinitefor every member of the·owner's·{member type definitions} set then{value} isfinite,otherwise{value}iscountably infinite.

4.2.4 numeric

Some value spaces are made up of things thatare conceptuallynumeric, others arenot. Thenumeric facet value indicates which areconsidered numeric.

4.2.4.1 The numeric Schema Component
Schema Component:numeric, a kind ofFundamental Facet
{value}
An xs:boolean value. Required.

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

When the·owner· is·primitive·,{value} is as specified in thetable inFundamental Facets (§F.1).  Otherwise, when the·owner's·{variety} isatomic,{value} is inherited fromthe·owner's·{base type definition}'snumeric{value}.

When the·owner's·{variety} islist,{value} isfalse.

When the·owner's·{variety} isunion,ifnumeric's{value} istruefor every member of the·owner's·{member type definitions} set then{value} istrue,otherwise{value} isfalse.

previous sub-section4.3 Constraining Facets

        4.3.1length
            4.3.1.1The length Schema Component
            4.3.1.2XML Representation of length Schema Components
            4.3.1.3length Validation Rules
            4.3.1.4Constraints on length Schema Components
        4.3.2minLength
            4.3.2.1The minLength Schema Component
            4.3.2.2XML Representation of minLength Schema Component
            4.3.2.3minLength Validation Rules
            4.3.2.4Constraints on minLength Schema Components
        4.3.3maxLength
            4.3.3.1The maxLength Schema Component
            4.3.3.2XML Representation of maxLength Schema Components
            4.3.3.3maxLength Validation Rules
            4.3.3.4Constraints on maxLength Schema Components
        4.3.4pattern
            4.3.4.1The pattern Schema Component
            4.3.4.2XML Representation of pattern Schema Components
            4.3.4.3Constraints on XML Representation of pattern
            4.3.4.4pattern Validation Rules
            4.3.4.5Constraints on pattern Schema Components
        4.3.5enumeration
            4.3.5.1The enumeration Schema Component
            4.3.5.2XML Representation of enumeration Schema Components
            4.3.5.3Constraints on XML Representation of enumeration
            4.3.5.4enumeration Validation Rules
            4.3.5.5Constraints on enumeration Schema Components
        4.3.6whiteSpace
            4.3.6.1The whiteSpace Schema Component
            4.3.6.2XML Representation of whiteSpace Schema Components
            4.3.6.3whiteSpace Validation Rules
            4.3.6.4Constraints on whiteSpace Schema Components
        4.3.7maxInclusive
            4.3.7.1The maxInclusive Schema Component
            4.3.7.2XML Representation of maxInclusive Schema Components
            4.3.7.3maxInclusive Validation Rules
            4.3.7.4Constraints on maxInclusive Schema Components
        4.3.8maxExclusive
            4.3.8.1The maxExclusive Schema Component
            4.3.8.2XML Representation of maxExclusive Schema Components
            4.3.8.3maxExclusive Validation Rules
            4.3.8.4Constraints on maxExclusive Schema Components
        4.3.9minExclusive
            4.3.9.1The minExclusive Schema Component
            4.3.9.2XML Representation of minExclusive Schema Components
            4.3.9.3minExclusive Validation Rules
            4.3.9.4Constraints on minExclusive Schema Components
        4.3.10minInclusive
            4.3.10.1The minInclusive Schema Component
            4.3.10.2XML Representation of minInclusive Schema Components
            4.3.10.3minInclusive Validation Rules
            4.3.10.4Constraints on minInclusive Schema Components
        4.3.11totalDigits
            4.3.11.1The totalDigits Schema Component
            4.3.11.2XML Representation of totalDigits Schema Components
            4.3.11.3totalDigits Validation Rules
            4.3.11.4Constraints on totalDigits Schema Components
        4.3.12fractionDigits
            4.3.12.1The fractionDigits Schema Component
            4.3.12.2XML Representation of fractionDigits Schema Components
            4.3.12.3fractionDigits Validation Rules
            4.3.12.4Constraints on fractionDigits Schema Components
        4.3.13Assertions
            4.3.13.1The assertions Schema Component
            4.3.13.2XML Representation of assertions Schema Components
            4.3.13.3Assertions Validation Rules
            4.3.13.4Constraints on assertions Schema Components
        4.3.14explicitTimezone
            4.3.14.1The explicitTimezone Schema Component
            4.3.14.2XML Representation of explicitTimezone Schema Components
            4.3.14.3explicitTimezone Validation Rules
            4.3.14.4Constraints on explicitTimezone Schema Components

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

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

Conforming processorsmustsupport all the facets defined in this section.It is·implementation-defined· whether a processor supports otherconstraining facets.[Definition:]  An·constraining facet· which is not supported bythe processor in use isunknown.

Note: A reference to an·unknown· facet might be a reference toan·implementation-defined· facet supported by some other processor,or might be the result of a typographic error, or mighthave some other explanation.

The descriptions of individual facets givenbelow include both constraints onSimple Type Definition componentsand rules for checking the datatype validity of a given literal againsta given datatype. The validation rules typically depend upon havinga full knowledge of the datatype; full knowledge of the datatype,in turn, depends on having a fully instantiatedSimple Type Definition.A full instantiation of theSimple Type Definition, and the checkingof the component constraints, require knowledge of the·base type·.It follows that if a datatype's·base type· is·unknown·, theSimple Type Definition defining the datatype will be incompletelyinstantiated, and the datatype itself will be·unknown·.Similarly, any datatype defined using an·unknown··constraining facet·will be·unknown·. It is not possible to perform datatype validationas defined here using·unknown· datatypes.

Note: The preceding paragraph does not forbid implementations from attemptingto make use of such partial information as they have about·unknown·datatypes. But the exploitation of such partial knowledge is notdatatype validity checking as defined here and is to be distinguishedfrom it in the implementation's documentation and interface.

4.3.1 length

[Definition:]  length is the numberofunits of length, whereunits of lengthvaries depending on the type that is being·derived· from.The value oflengthmust be anonNegativeInteger.

Forstring and datatypes·derived· fromstring,length is measured in units ofcharacters as defined in[XML].ForanyURI,length is measured in units ofcharacters (as forstring).ForhexBinary andbase64Binary and datatypes·derived· from them,length is measured in octets (8 bits) of binary data.For datatypes·constructed· by·list·,length is measured in number of list items.

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

·length· provides for:

Example
The following is the definition of a·user-defined·datatype to represent product codes which must beexactly 8 characters in length.  By fixing the value of thelength facet we ensure that types derived from productCode canchange or set the values of other facets, such aspattern, butcannot change the length.
<simpleType name='productCode'>   <restriction base='string'>     <length value='8' fixed='true'/>   </restriction></simpleType>
4.3.1.1 The length Schema Component
Schema Component:length, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
An xs:nonNegativeInteger value. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forlength other than{value}.

Note: The{fixed} property is defined forparallelism with other facets and for compatibility with version 1.0of this specification. But it is a consequence oflength valid restriction (§4.3.1.4) that the value ofthelength facet cannot be changed, regardless ofwhether{fixed} istrue orfalse.
4.3.1.2 XML Representation of length Schema Components

The XML representation for alength schemacomponent is a<length> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:length Element Information Item
<length
  fixed =boolean : false
  id =ID
  value =nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</length>
lengthSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.1.3 length Validation Rules
Validation Rule: Length Valid
A value in a·value space· is facet-valid withrespect to·length·if and only if:
1 if the{variety} is·atomic· then
1.1if{primitive type definition} isstring oranyURI, then the length of the value,as measured incharactersmust be equal to{value};
1.2if{primitive type definition} ishexBinary orbase64Binary, then the length ofthe value, as measured in octets of the binary data,must be equal to{value};
1.3if{primitive type definition} isQName orNOTATION, then any{value} is facet-valid.
2if the{variety} is·list·,then the length of the value, as measured in list items,must be equal to{value}

The use of·length·onQName,NOTATION, and datatypes·derived· from themis deprecated.  Future versions of thisspecification may remove this facet for these datatypes.

4.3.1.4 Constraints on length Schema Components
Schema Component Constraint: length and minLength or maxLength
Iflength is a member of{facets} then
1 It is an error forminLength to be a member of{facets} unless
1.1the{value} ofminLength <= the{value} oflength and
1.2there is some type definition from which this one is derived by one or more·restriction· steps in whichminLength has the same{value} andlength is not specified.
2 It is an error formaxLength to be a member of{facets} unless
2.1the{value} oflength <= the{value} ofmaxLength and
2.2there is some type definition from which this one is derived by one or more restriction steps in whichmaxLength has the same{value} andlength is not specified.
Schema Component Constraint: length valid restriction
It is an·error· iflengthis among the members of{facets} of{base type definition} and{value} isnot equal to the{value} of the parentlength.

4.3.2 minLength

[Definition:]  minLength isthe minimum number ofunits of length, whereunits of length varies depending on the type that is being·derived· from.The value ofminLength must be anonNegativeInteger.

Forstring and datatypes·derived· fromstring,minLength is measured in units ofcharacters as defined in[XML].ForhexBinary andbase64Binary and datatypes·derived· from them,minLength is measured in octets (8 bits) of binary data.For datatypes·constructed· by·list·,minLength is measured in number of list items.

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

·minLength· provides for:

Example
The following is the definition of a·user-defined·datatype which requires strings to have at least one character (i.e.,the empty string is not in the·value space·of this datatype).
<simpleType name='non-empty-string'>  <restriction base='string'>    <minLength value='1'/>  </restriction></simpleType>
4.3.2.1 The minLength Schema Component
Schema Component:minLength, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
An xs:nonNegativeInteger value. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminLength other than{value}.

4.3.2.2 XML Representation of minLength Schema Component

The XML representation for aminLength schemacomponent is a<minLength> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:minLength Element Information Item
<minLength
  fixed =boolean : false
  id =ID
  value =nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</minLength>
minLengthSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.2.3 minLength Validation Rules
Validation Rule: minLength Valid
A value in a·value space· is facet-valid withrespect to·minLength·, determined as follows:
1 if the{variety} is·atomic· then
1.1if{primitive type definition} isstring oranyURI, then thelength of the value, as measured incharactersmust be greater than or equal to{value};
1.2if{primitive type definition} ishexBinary orbase64Binary, then thelength of the value, as measured in octets of the binary data,must be greater than or equal to{value};
1.3if{primitive type definition} isQName orNOTATION, thenany{value} is facet-valid.
2if the{variety} is·list·,then the length of the value, as measuredin list items,must be greater than or equalto{value}

The use of·minLength·onQName,NOTATION, and datatypes·derived· from themis deprecated.  Future versions of thisspecification may remove this facet for these datatypes.

4.3.2.4 Constraints on minLength Schema Components
Schema Component Constraint: minLength <= maxLength
If bothminLength andmaxLengthare members of{facets}, then the{value} ofminLength must be less than or equal to the{value} ofmaxLength.
Schema Component Constraint: minLength valid restriction
It is an·error· ifminLengthis among the members of{facets} of{base type definition} and{value} isless than the{value} of the parentminLength.

4.3.3 maxLength

[Definition:]  maxLength isthe maximum number ofunits of length, whereunits of length variesdepending on the type that is being·derived· from.The value ofmaxLength must be anonNegativeInteger.

Forstring and datatypes·derived· fromstring,maxLength is measured in units ofcharacters as defined in[XML].ForhexBinary andbase64Binary and datatypes·derived· from them,maxLength is measured in octets (8 bits) of binary data.For datatypes·constructed· by·list·,maxLength is measured in number of list items.

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

·maxLength· provides for:

Example
The following is the definition of a·user-defined·datatype which might be used to accept form input with an upper limitto the number of characters that are acceptable.
<simpleType name='form-input'>  <restriction base='string'>    <maxLength value='50'/>  </restriction></simpleType>
4.3.3.1 The maxLength Schema Component
Schema Component:maxLength, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
An xs:nonNegativeInteger value. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxLength other than{value}.

4.3.3.2 XML Representation of maxLength Schema Components

The XML representation for amaxLength schemacomponent is a<maxLength> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:maxLength Element Information Item
<maxLength
  fixed =boolean : false
  id =ID
  value =nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</maxLength>
maxLengthSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.3.3 maxLength Validation Rules
Validation Rule: maxLength Valid
A value in a·value space· is facet-valid withrespect to·maxLength·, determined as follows:
1 if the{variety} is·atomic· then
1.1if{primitive type definition} isstring oranyURI, then thelength of the value, as measured incharactersmust be less than or equal to{value};
1.2if{primitive type definition} ishexBinary orbase64Binary, then thelength of the value, as measured in octets of the binary data,must be less than or equal to{value};
1.3if{primitive type definition} isQName orNOTATION, thenany{value} is facet-valid.
2if the{variety} is·list·,then the length of the value, as measuredin list items,must be less than or equal to{value}

The use of·maxLength·onQName,NOTATION, and datatypes·derived· from themis deprecated.  Future versions of thisspecification may remove this facet for these datatypes.

4.3.3.4 Constraints on maxLength Schema Components
Schema Component Constraint: maxLength valid restriction
It is an·error· ifmaxLengthis among the members of{facets} of{base type definition} and{value} isgreater than the{value} of the parentmaxLength.

4.3.4 pattern

[Definition:]  pattern is a constraint on the·value space· of a datatype which is achieved byconstraining the·lexical space· to·literals·which matcheachmember of a set of·regularexpressions·. The value ofpattern mustbe a set of·regular expressions·.

Note: An XML<restriction>containing more than one<pattern> element givesrise to a single·regular expression· in the set; this·regular expression· is an "or" ofthe·regular expressions· thatare the content of the<pattern> elements.

·pattern· provides for:

Example
The following is the definition of a·user-defined·datatype which is a better representation of postal codes in theUnited States, by limiting strings to those which are matched bya specific·regular expression·.
<simpleType name='better-us-zipcode'>  <restriction base='string'>    <pattern value='[0-9]{5}(-[0-9]{4})?'/>  </restriction></simpleType>
4.3.4.1 The pattern Schema Component
Schema Component:pattern, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}

A non-empty set of·regular expressions·.

4.3.4.2 XML Representation of pattern Schema Components

The XML representation for apattern schemacomponent is one or more<pattern>element information items. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:pattern Element Information Item
<pattern
  id =ID
  value =string
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</pattern>
patternSchema Component
Property
Representation
 
[Definition:]  LetR be a regularexpression given by the appropriatecase among the following:
1Ifthere is only one<pattern> among the[children] of a<restriction>,thentheactual value of itsvalue[attribute]
2otherwisethe concatenation of theactual values of all the<pattern>[children]'svalue[attributes], in order,separated by '|', so forming a single regular expression with multiple·branches·.
The value is then given by the appropriatecase among the following:
1Ifthe{base type definition} of the·owner· has apattern facet among its{facets},thenthe union of thatpattern facet's{value} and {·R·}
2otherwisejust {·R·}
 
Theannotation mapping of the set containing all of the<pattern> elements among the[children] of the<restriction> element information item, as defined in sectionXML Representation of Annotation Schema Components of[XSD 1.1 Part 1: Structures].
Note: The{value} property will only have more than one member when·facet-based restriction· involves apattern facet at more than one step in a type derivation. During validation, lexical forms will be checked against every member of the resulting{value}, effectively creating a conjunction of patterns.
In summary,·pattern·facets specified on thesame step in a typederivation areORed together, while·pattern·facets specified ondifferent steps of a type derivationareANDed together.
Thus, to impose two·pattern· constraints simultaneously,schema authors may either write a single·pattern· whichexpresses the intersection of the two·pattern·s they wish toimpose, or define each·pattern· on a separate type derivationstep.
4.3.4.3 Constraints on XML Representation of pattern
Schema Representation Constraint: Pattern value
4.3.4.4 pattern Validation Rules
Validation Rule: pattern valid
A·literal· in a·lexical space· is pattern-valid (or: facet-valid withrespect to·pattern·) if and only iffor each·regular expression· in its{value},the·literal· is among the set of character sequences denoted bythe·regular expression·.
Note: As noted inDatatype (§2.1),certain uses of the·pattern· facet mayeliminate from the lexical space the canonical forms of some valuesin the value space; this can be inconvenient for applicationswhich write out the canonical form of a value and rely onbeing able to read it in again as a legal lexical form.This specification provides no recourse in such situations;applications are free to deal with it as they see fit.Caution is advised.
4.3.4.5 Constraints on pattern Schema Components
Schema Component Constraint: Valid restriction of pattern
It is an·error· if there is any member of the{value} of thepattern facet on the{base type definition}which is not also a member of the{value}.
Note: For components constructed from XML representations in schema documents, the satisfaction of this constraint is a consequence of the XML mapping rules:any pattern imposed by a simple type definitionS will always also be imposed by any type derived fromS by·facet-based restriction·.This constraint ensures that components constructed by other means(so-called "born-binary" components) similarly preservepattern facets across·facet-based restriction·.

4.3.5 enumeration

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

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

·enumeration· provides for:

Example
The following example is aSimple Type Definition for a·user-defined· datatype which limits the valuesof dates to the three US holidays enumerated. ThisSimple Type Definition would appear in a schema authored by an "end-user" andshows how to define a datatype by enumerating the values in its·value space·.  The enumerated values must betype-valid·literals· for the·base type·.
<simpleType name='holidays'>    <annotation>        <documentation>some US holidays</documentation>    </annotation>    <restriction base='gMonthDay'>      <enumeration value='--01-01'>        <annotation>            <documentation>New Year's day</documentation>        </annotation>      </enumeration>      <enumeration value='--07-04'>        <annotation>            <documentation>4th of July</documentation>        </annotation>      </enumeration>      <enumeration value='--12-25'>        <annotation>            <documentation>Christmas</documentation>        </annotation>      </enumeration>    </restriction></simpleType>
4.3.5.1 The enumeration Schema Component
Schema Component:enumeration, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}

A set of values from the·value space· of the{base type definition}.

4.3.5.2 XML Representation of enumeration Schema Components

The XML representation for anenumeration schemacomponent is one or more<enumeration>element information items. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:enumeration Element Information Item
<enumeration
  id =ID
  value =anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</enumeration>
enumerationSchema Component
Property
Representation
 
The appropriatecase among the following:
1Ifthere is only one<enumeration> among the[children] of a<restriction>,thena set with one member, theactual value of itsvalue[attribute], interpreted as an instance of the{base type definition}.
2otherwisea set of theactual values of all the<enumeration>[children]'svalue[attributes], interpreted as instances of the{base type definition}.
Note: Thevalue[attribute] is declared as havingtype·anySimpleType·, but the{value} property of theenumeration facetmust be a member of the{base type definition}.So in mapping from the XML representationto theenumeration component, theactual value isidentified by using the·lexical mapping· of the{base type definition}.
 
A (possibly empty) sequence ofAnnotation components, one for each<annotation> among the[children] of the<enumeration>s among the[children] of a<restriction>, in order.
4.3.5.3 Constraints on XML Representation of enumeration
Schema Representation Constraint: Enumeration value
Thenormalized value of thevalue[attribute] must beDatatype Valid (§4.1.4) with respect to the{base type definition} of theSimple Type Definitioncorresponding to the nearest<simpleType> ancestorelement.
4.3.5.4 enumeration Validation Rules
Validation Rule: enumeration valid
A value in a·value space· is facet-valid withrespect to·enumeration· if and only ifthe value is equal or identicaltoone of the values specified in{value}.
Note: As specified normatively elsewhere, for purposes of checkingenumerations, no distinction is made between an atomic valueVand a list of length one containingV as its only item.
In this question, the behavior of this specification is thusthe same as the behavior specified by[XQuery 1.0 and XPath 2.0 Functions and Operators]and related specifications.
4.3.5.5 Constraints on enumeration Schema Components
Schema Component Constraint: enumeration valid restriction
It is an·error· if any member of{value} is not in the·value space·of{base type definition}.

4.3.6 whiteSpace

[Definition:]  whiteSpace constrains the·value space·of types·derived· fromstring such thatthe various behaviorsspecified inAttribute Value Normalizationin[XML] are realized.  The value ofwhiteSpace must be one of {preserve, replace, collapse}.

preserve
No normalization is done, the value is not changed (this is thebehavior required by[XML] for element content)
replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return)are replaced with #x20 (space)
collapse
After the processing implied byreplace, contiguoussequences of #x20's are collapsed to a single #x20, and any #x20at the start or end of the string is then removed.
Note: The notation #xA used here (and elsewhere in this specification)represents the Universal Character Set (UCS) code pointhexadecimal A (line feed), which is denoted byU+000A.  This notation is to be distinguished from&#xA;, which is the XMLcharacter reference to that same UCScode point.

whiteSpace is applicable to all·atomic· and·list· datatypes.  For all·atomic·datatypes other thanstring (and types·derived·by·facet-based restriction· from it) the value ofwhiteSpace iscollapse and cannot be changed by a schema author; forstring the value ofwhiteSpace ispreserve; for any type·derived· by·facet-based restriction· fromstring the value ofwhiteSpace canbe any of the three legal values(as long as the value is at least as restrictive asthe value of the·base type·; seeConstraints on whiteSpace Schema Components (§4.3.6.4)).  For all datatypes·constructed· by·list· thevalue ofwhiteSpace iscollapse and cannotbe changed by a schema author.  For all datatypes·constructed· by·union· whiteSpace does not apply directly; however, thenormalization behavior of·union· types is controlled bythe value ofwhiteSpace on that one of the·basic members· against which the·union·is successfully validated.

Note: For more information onwhiteSpace, see thediscussion on white space normalization inSchema Component Detailsin[XSD 1.1 Part 1: Structures].

·whiteSpace· provides for:

  • Constraining a·value space· according tothe white space normalization rules.
Example
The following example is theSimple Type Definition forthe·built-in·tokendatatype.
<simpleType name='token'>    <restriction base='normalizedString'>      <whiteSpace value='collapse'/>    </restriction></simpleType>
Note: The values "replace" and "collapse" may appear to provide aconvenient way to "unwrap" text (i.e. undo the effects ofpretty-printing and word-wrapping). In some cases, especiallyhighly constrained data consisting of lists of artificial tokenssuch as part numbers or other identifiers, this appearance iscorrect. For natural-language data, however, the whitespaceprocessing prescribed for these values is not only unreliable butwill systematically remove the information needed to performunwrapping correctly. For Asian scripts, for example, a correctunwrapping process will replace line boundaries not with blanks butwith zero-width separators or nothing. In consequence, it isnormally unwise to use these values for natural-language data, orfor any data other than lists of highly constrained tokens.
4.3.6.1 The whiteSpace Schema Component
Schema Component:whiteSpace, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
One of {preserve,replace,collapse}. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forwhiteSpace other than{value}.

4.3.6.2 XML Representation of whiteSpace Schema Components

The XML representation for awhiteSpace schemacomponent is a<whiteSpace> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:whiteSpace Element Information Item
<whiteSpace
  fixed =boolean : false
  id =ID
  value = (collapse |preserve |replace)
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</whiteSpace>
whiteSpaceSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.6.3 whiteSpace Validation Rules
Note: There are no·Validation Rule·s associated with·whiteSpace·.For more information, see thediscussion on white space normalization inSchema Component Detailsin[XSD 1.1 Part 1: Structures], in particularthe section3.1.4 White Space Normalization during Validation.
4.3.6.4 Constraints on whiteSpace Schema Components
Schema Component Constraint: whiteSpace valid restriction
It is an·error· ifwhiteSpaceis among the members of{facets} of{base type definition} and any of the following conditions istrue:
1{value} isreplace orpreserveand the{value} of the parentwhiteSpace iscollapse
2{value} ispreserveand the{value} of the parentwhiteSpace isreplace
Note: In order of increasing restrictiveness, the legal values for thewhiteSpace facet arepreserve,collapse, andreplace. The more restrictive keywordsare more restrictive not in the senseof accepting progressively fewer instance documents butin the sense that each corresponds to a progressively smaller,more tightly restricted value space.

4.3.7 maxInclusive

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

·maxInclusive· provides for:

  • Constraining a·value space· to values with aspecific inclusive upperbound.
Example
The following is the definition of a·user-defined·datatype which limits values to integers less than or equal to100, using·maxInclusive·.
<simpleType name='one-hundred-or-less'>  <restriction base='integer'>    <maxInclusive value='100'/>  </restriction></simpleType>
4.3.7.1 The maxInclusive Schema Component
Schema Component:maxInclusive, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxInclusive other than{value}.

4.3.7.2 XML Representation of maxInclusive Schema Components

The XML representation for amaxInclusive schemacomponent is a<maxInclusive> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:maxInclusive Element Information Item
<maxInclusive
  fixed =boolean : false
  id =ID
  value =anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</maxInclusive>
{value} must be equal to some valuein the·value space· of{base type definition}.
maxInclusiveSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.7.3 maxInclusive Validation Rules
Validation Rule: maxInclusive Valid
A value in an·ordered· ·value space·is facet-valid with respect to·maxInclusive·if and only if the value is less than or equal to{value}, according to thedatatype's order relation.
4.3.7.4 Constraints on maxInclusive Schema Components
Schema Component Constraint: minInclusive <= maxInclusive
It is an·error· for the value specified for·minInclusive· to be greater than the valuespecified for·maxInclusive· for the same datatype.
Schema Component Constraint: maxInclusive valid restriction
It is an·error· if any of the following conditionsis true:
1maxInclusive is among the members of{facets} of{base type definition}and{value} isgreater than the{value} of thatmaxInclusive.
2maxExclusive is among the members of{facets} of{base type definition}and{value} isgreater than or equal to the{value} ofthatmaxExclusive.
3minInclusive is among the members of{facets} of{base type definition}and{value} isless than the{value} of thatminInclusive.
4minExclusive is among the members of{facets} of{base type definition}and{value} isless than or equal to the{value} of thatminExclusive.

4.3.8 maxExclusive

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

·maxExclusive· provides for:

  • Constraining a·value space· to values with aspecific exclusive upperbound.
Example
The following is the definition of a·user-defined·datatype which limits values to integers less than or equal to100, using·maxExclusive·.
<simpleType name='less-than-one-hundred-and-one'>  <restriction base='integer'>    <maxExclusive value='101'/>  </restriction></simpleType>
Note that the·value space· of this datatype is identical tothe previous one (named 'one-hundred-or-less').
4.3.8.1 The maxExclusive Schema Component
Schema Component:maxExclusive, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxExclusive other than{value}.

4.3.8.2 XML Representation of maxExclusive Schema Components

The XML representation for amaxExclusive schemacomponent is a<maxExclusive> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:maxExclusive Element Information Item
<maxExclusive
  fixed =boolean : false
  id =ID
  value =anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</maxExclusive>
{value} must be equal to some valuein the·value space· of{base type definition}.
maxExclusiveSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.8.3 maxExclusive Validation Rules
Validation Rule: maxExclusive Valid
A value in an·ordered··value space·is facet-valid with respect to·maxExclusive·if and only if the value is less than{value}, according to thedatatype's order relation.
4.3.8.4 Constraints on maxExclusive Schema Components
Schema Component Constraint: maxInclusive and maxExclusive
It is an·error· for both·maxInclusive· and·maxExclusive·to be specified in the same derivation step of aSimple Type Definition.
Schema Component Constraint: minExclusive <= maxExclusive
It is an·error· for the value specified for·minExclusive· to be greater than the valuespecified for·maxExclusive· for the same datatype.
Schema Component Constraint: maxExclusive valid restriction
It is an·error· if any of the following conditionsis true:
1maxExclusive is among the members of{facets} of{base type definition}and{value} isgreater than the{value} of thatmaxExclusive.
2maxInclusive is among the members of{facets} of{base type definition}and{value} isgreater than the{value} of thatmaxInclusive.
3minInclusive is among the members of{facets} of{base type definition}and{value} isless than or equal to the{value} of thatminInclusive.
4minExclusive is among the members of{facets} of{base type definition}and{value} isless than or equal to the{value} of thatminExclusive.

4.3.9 minExclusive

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

·minExclusive· provides for:

  • Constraining a·value space· to values with aspecific exclusive lower bound.
Example
The following is the definition of a·user-defined·datatype which limits values to integers greater than or equal to100, using·minExclusive·.
<simpleType name='more-than-ninety-nine'>  <restriction base='integer'>    <minExclusive value='99'/>  </restriction></simpleType>
Note that the·value space· of this datatype is identical to the followingone (named 'one-hundred-or-more').
4.3.9.1 The minExclusive Schema Component
Schema Component:minExclusive, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminExclusive other than{value}.

4.3.9.2 XML Representation of minExclusive Schema Components

The XML representation for aminExclusive schemacomponent is a<minExclusive> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:minExclusive Element Information Item
<minExclusive
  fixed =boolean : false
  id =ID
  value =anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</minExclusive>
{value} must be equal to some valuein the·value space· of{base type definition}.
minExclusiveSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.9.3 minExclusive Validation Rules
Validation Rule: minExclusive Valid
A value in an·ordered· ·value space·is facet-valid with respect to·minExclusive· if and only ifthe value is greater than{value}, according to thedatatype's order relation.
4.3.9.4 Constraints on minExclusive Schema Components
Schema Component Constraint: minInclusive and minExclusive
It is an·error· for both·minInclusive· and·minExclusive· to be specified in the same derivation step of aSimple Type Definition.
Schema Component Constraint: minExclusive < maxInclusive
It is an·error· for the value specified for·minExclusive· to be greater than or equal to the valuespecified for·maxInclusive· for the same datatype.
Schema Component Constraint: minExclusive valid restriction
It is an·error· if any of the following conditions is true:
1minExclusive is among the members of{facets} of{base type definition}and{value} isless than the{value} of thatminExclusive.
2minInclusive is among the members of{facets} of{base type definition}and{value} isless than the{value} of thatminInclusive.
3maxInclusive is among the members of{facets} of{base type definition} and{value} isgreater than or equal to the{value} of thatmaxInclusive.
4maxExclusive is among the members of{facets} of{base type definition}and{value} isgreater than or equal to the{value} of thatmaxExclusive.

4.3.10 minInclusive

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

·minInclusive· provides for:

  • Constraining a·value space· to values with aspecific inclusive lowerbound.
Example
The following is the definition of a·user-defined·datatype which limits values to integers greater than or equal to100, using·minInclusive·.
<simpleType name='one-hundred-or-more'>  <restriction base='integer'>    <minInclusive value='100'/>  </restriction></simpleType>
4.3.10.1 The minInclusive Schema Component
Schema Component:minInclusive, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminInclusive other than{value}.

4.3.10.2 XML Representation of minInclusive Schema Components

The XML representation for aminInclusive schemacomponent is a<minInclusive> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:minInclusive Element Information Item
<minInclusive
  fixed =boolean : false
  id =ID
  value =anySimpleType
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</minInclusive>
{value} must be equal to some value in the·value space· of{base type definition}.
minInclusiveSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.10.3 minInclusive Validation Rules
Validation Rule: minInclusive Valid
A value in an·ordered· ·value space·is facet-valid with respect to·minInclusive· if and only ifthe value is greater than or equal to{value}, according to thedatatype's order relation.
4.3.10.4 Constraints on minInclusive Schema Components
Schema Component Constraint: minInclusive < maxExclusive
It is an·error· for the value specified for·minInclusive· to be greater than or equal to the valuespecified for·maxExclusive· for the same datatype.
Schema Component Constraint: minInclusive valid restriction
It is an·error· if any of the following conditionsis true:
1minInclusive is among the members of{facets} of{base type definition}and{value} isless than the{value} ofthatminInclusive.
2maxInclusive is among the members of{facets} of{base type definition}and{value} isgreater the{value} of thatmaxInclusive.
3minExclusive is among the members of{facets} of{base type definition}and{value} isless than or equal to the{value} of thatminExclusive.
4maxExclusive is among the members of{facets} of{base type definition}and{value} isgreater than or equal to the{value} of thatmaxExclusive.

4.3.11 totalDigits

[Definition:]  totalDigits restricts the magnitude and arithmetic precision of values in the·value spaces· ofdecimal and datatypes derived from it.

Fordecimal,if the{value} oftotalDigits ist, the effect is to require that values be equal toi / 10n, for someintegersi andn, with | i | < 10tand0 ≤ n ≤ t.This has as a consequence that the values are expressibleusing at mostt digits in decimal notation.

The{value} oftotalDigitsmust beapositiveInteger.

The term 'totalDigits' is chosen to reflect the fact thatit restricts the·value space· to those values thatcan be represented lexically using at mosttotalDigits digits indecimal notation, or at mosttotalDigits digitsfor the coefficient, in scientific notation. Note that it does not restrictthe·lexical space· directly; a lexicalrepresentation that adds non-significantleading or trailing zero digits is still permitted.It also has no effect on the values NaN, INF, and -INF.

4.3.11.1 The totalDigits Schema Component
Schema Component:totalDigits, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
An xs:positiveInteger value. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then types for whichthe current type is the{base type definition}must not specify avalue fortotalDigits other than{value}.

4.3.11.2 XML Representation of totalDigits Schema Components

The XML representation for atotalDigits schemacomponent is a<totalDigits> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:totalDigits Element Information Item
<totalDigits
  fixed =boolean : false
  id =ID
  value =positiveInteger
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</totalDigits>
totalDigitsSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.11.3 totalDigits Validation Rules
Validation Rule: totalDigits Valid
A valuevis facet-valid with respect to atotalDigits facet with a{value} oft if and only ifv is adecimal value equal toi / 10n, for someintegersi andn, with | i | < 10tand0 ≤ n ≤ t.
4.3.11.4 Constraints on totalDigits Schema Components
Schema Component Constraint: totalDigits valid restriction
It is an·error· if the·owner·'s{base type definition}has atotalDigits facet among its{facets}and{value} isgreater than the{value} ofthattotalDigits facet.

4.3.12 fractionDigits

[Definition:]  fractionDigitsplaces an upper limit on the arithmetic precision ofdecimal values: if the{value} offractionDigits =f, then the value space isrestricted to values equal toi / 10n for some integersi andn and 0 ≤nf.The value offractionDigits must be anonNegativeInteger

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

Example
The following is the definition of a·user-defined·datatype which could be used to represent the magnitudeof a person's body temperature on the Celsius scale.This definition would appear in a schema authored by an "end-user"and shows how to define a datatype by specifying facet values whichconstrain the range of the·base type·.
<simpleType name='celsiusBodyTemp'>  <restriction base='decimal'>    <fractionDigits value='1'/>    <minInclusive value='32'/> <maxInclusive value='41.7'/>  </restriction></simpleType>
4.3.12.1 The fractionDigits Schema Component
Schema Component:fractionDigits, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
An xs:nonNegativeInteger value. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, thentypes for which the current type is the{base type definition}must notspecify a value forfractionDigits otherthan{value}.

4.3.12.2 XML Representation of fractionDigits Schema Components

The XML representation for afractionDigits schemacomponent is a<fractionDigits> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:fractionDigits Element Information Item
<fractionDigits
  fixed =boolean : false
  id =ID
  value =nonNegativeInteger
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</fractionDigits>
fractionDigitsSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.12.3 fractionDigits Validation Rules
Validation Rule: fractionDigits Valid
A value is facet-valid withrespect to·fractionDigits· if and only ifthat value is equal toi / 10n for integeri andn, with 0 ≤n{value}.
4.3.12.4 Constraints on fractionDigits Schema Components
Schema Component Constraint: fractionDigits less than or equal to totalDigits
It is an·error· for the{value} offractionDigitsto be greater thanthat oftotalDigits.
Schema Component Constraint: fractionDigits valid restriction
It is an·error· if·fractionDigits· is among the members of{facets} of{base type definition} and{value} is greater than the{value} of that·fractionDigits·.

4.3.13 Assertions

[Definition:]  Assertions constrain the·value space· by requiring the values to satisfy specified XPath ([XPath 2.0]) expressions. The value of theassertions facet is a sequence ofAssertion components as defined in[XSD 1.1 Part 1: Structures].

Example

The following is the definition of a·user-defined· datatype which allows all integers but 0 by using an assertion to disallow the value 0.

<simpleType name='nonZeroInteger'>  <restriction base='integer'>    <assertion test='$value ne 0'/>  </restriction></simpleType>
Example

The following example defines the datatype "triple", whose·value space· is the set of integers evenly divisible by three.

<simpleType name='triple'>  <restriction base='integer'>    <assertion test='$value mod 3 eq 0'/>  </restriction></simpleType>

The same datatype can be defined without the use of assertions, but the pattern necessary to represent the set of triples is long and error-prone:

<simpleType name='triple'>  <restriction base='integer'>    <pattern value=    "([0369]|[147][0369]*[258]|(([258]|[147][0369]*[147])([0369]|[258][0369]*[147])*([147]|[258][0369]*[258]))*"/>  </restriction></simpleType>

The assertion used in the first version of "triple" is likely to be clearer for many readers of the schema document.

4.3.13.1 The assertions Schema Component
Schema Component:assertions, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}

A sequence ofAssertion components.

4.3.13.2 XML Representation of assertions Schema Components

The XML representation for anassertions schema component is one or more<assertion> element information items. The correspondences between the properties of the information item and properties of the component are as follows:

XML Representation Summary:assertion Element Information Item
<assertion
  id =ID
  test =an XPath expression
  xpathDefaultNamespace = (anyURI | (##defaultNamespace |##targetNamespace |##local))
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</assertion>
assertionsSchema Component
Property
Representation
 
A sequence whose members areAssertions drawn from the following sources, in order:
1If the{base type definition} of the·owner· has anassertions facet among its{facets}, then theAssertions which appear in the{value} of thatassertions facet.
2Assertions corresponding to the<assertion> element information items among the[children] of<restriction>, if any, in document order. For details of the construction of theAssertion components, seesection 3.13.2 of[XSD 1.1 Part 1: Structures].
 
The empty sequence.
Note: Annotations specified within an<assertion> element are captured by the individualAssertion component to which it maps.
4.3.13.3 Assertions Validation Rules

The following rule refers to"the nearest built-in" datatypeand to the "XDM representation" of a valueunder a datatype.[Definition:]  Forany datatypeT, thenearest built-in datatype toT is the first·built-in· datatype encountered in followingthe chain of links connecting each datatype to its·base type·. IfT is a·built-in· datatype, then thenearest built-in datatype ofT isT itself; otherwise,it is the nearest built-in datatype ofT's·base type·.

[Definition:]  For any valueV and any datatypeT, theXDM representation ofV underT is defined recursively as follows. Call the XDM representationX. Then
1IfT =·xs:anySimpleType· or·xs:anyAtomicType· thenX isV,and thedynamictype ofX isxs:untypedAtomic.
2IfT .{variety} =atomic,then letT2 be the·nearest built-in datatype· toT.IfV is a member of the·value space· ofT2, thenX isV and thedynamic typeofX isT2.Otherwise (i.e. ifV is not a member of the·value space· ofT2),X is the·XDM representation· ofV underT2 .{base type definition}.
3IfT .{variety} =list,thenX is a sequence of atomic values, each atomic value being the·XDM representation· of the correspondingitem in the listV underT .{item type definition}.
4IfT .{variety} =union,thenX is the·XDM representation· ofVunder the·active basic member· ofVwhen validated againstT.If there is no·active basic member·,thenV has no·XDM representation· underT.
Note: If the{item type definition} of a·list· is a·union·, or the·active basic member· isa·list·, then several steps may be necessary before the·atomic·datatype which serves as thedynamictype ofX is found.
Because the{item type definition}of a·list· is required to be an·atomic· or·union· datatype,and the·active basic member· of a·union· which accepts the valueV is by definition not a·union·, the recursive rule given above is guaranteed toterminate in a sequence of one or more·atomic· values,each belonging to an·atomic· datatype.
Validation Rule: Assertions Valid
A valueV is facet-valid with respect to anassertions facet belonging to a simple typeTif and only if the {test}property of eachAssertion in its{value}evaluates totrue under theconditions laid out below, without raising anydynamic error ortype error.
Evaluation of {test} is performed as defined in[XPath 2.0], with the following conditions:
1 The XPath expression {test} is evaluated, following the rules given inXPath Evaluation of[XSD 1.1 Part 1: Structures], with the following modifications.
1.1 Thein-scope variables in thestatic context is a set with a single member. Theexpanded QName of that member has no namespace URI and has 'value' as the local name. The (static)type of the member isanyAtomicType*.
Note: The XDM type labelanyAtomicType* simply says that for static typing purposes the variable$value will have a value consisting of a sequence of zero or more atomic values.
1.2There is nocontext item for the evaluation of the XPath expression.
Note: In the terminology of[XPath 2.0], thecontext item is "undefined".
Note: As a consequence the expression '.', or any implicit or explicit reference to the context item, will raise a dynamic error, which will cause the assertion to be treated as false. If an error is detected statically, then the assertion violates the schema component constraintXPath Valid and causes an error to be flagged in the schema.
The variable "$value" can be used to refer to the value being checked.
1.3There is likewise no value for thecontext size and thecontext position in thedynamic context used for evaluation of the assertion.
1.4 Thevariable values in thedynamic context is a set with a single member. Theexpanded QName of that member has no namespace URI and 'value' as the local name. Thevalue of the member is the·XDM representation· ofV underT.
1.5IfV has no·XDM representation· underT, then the XPath expression cannot usefully be evaluated, andV is not facet-valid against theassertions facet ofT.
2The evaluation result is converted to eithertrue orfalse as if by a call to the XPathfn:boolean function.
4.3.13.4 Constraints on assertions Schema Components
Schema Component Constraint: Valid restriction of assertions
The{value} of theassertions facet on the{base type definition}must be a prefix of the{value}.
Note: For components constructed from XML representations in schema documents, the satisfaction of this constraint is a consequence of the XML mapping rules: any assertion imposed by a simple type definitionS will always also be imposed by any type derived fromS by·facet-based restriction·. This constraint ensures that components constructed by other means (so-called "born-binary" components) similarly preserveassertions facets across·facet-based restriction·.

4.3.14 explicitTimezone

[Definition:]  explicitTimezone is a three-valued facet which can can be used to require or prohibit the time zone offset in date/time datatypes.

Example
The following·user-defined· datatype accepts onlydate values without a time zone offset,using theexplicitTimezone facet.
<simpleType name='bare-date'>  <restriction base='date'>    <explicitTimezone value='prohibited'/>  </restriction></simpleType>
The same effect could also be achieved using thepattern facet, as shown below,but it is somewhat less clear what is going on in this derivation, and it is better practice to usethe more straightforwardexplicitTimezone for this purpose.
<simpleType name='bare-date'>  <restriction base='date'>    <pattern value='[^:Z]*'/>  </restriction></simpleType>
4.3.14.1 The explicitTimezone Schema Component
Schema Component:explicitTimezone, a kind ofConstraining Facet
{annotations}
A sequence ofAnnotation components.
{value}
One of {required,prohibited,optional}. Required.
{fixed}
An xs:boolean value. Required.

If{fixed} istrue, then datatypes for whichthe current type is the{base type definition} cannot specify avalue forexplicitTimezone other than{value}.

Note: It is a consequence oftimezone valid restriction (§4.3.14.4) that the value oftheexplicitTimezone facet cannot be changed unless thatvalue isoptional, regardless ofwhether{fixed} istrue orfalse.  Accordingly,{fixed} is relevant only when{value} isoptional.
4.3.14.2 XML Representation of explicitTimezone Schema Components

The XML representation for anexplicitTimezone schemacomponent is an<explicitTimezone> element information item. Thecorrespondences between the properties of the information item andproperties of the component are as follows:

XML Representation Summary:explicitTimezone Element Information Item
<explicitTimezone
  fixed =boolean : false
  id =ID
  value =NCName
  {any attributes with non-schema namespace . . .}>
  Content:(annotation?)
</explicitTimezone>
explicitTimezoneSchema Component
Property
Representation
 
 
Theactual value of thefixed[attribute], if present, otherwisefalse
 
4.3.14.3 explicitTimezone Validation Rules
Validation Rule: explicitOffset Valid
AdateTime valueVis facet-valid with respect to·explicitTimezone· if and only ifone of the following is true
1The{value} of the facet isrequired andV has a (non-absent)value for the·timezoneOffset·property.
2The{value} of the facet isprohibited and the value for the·timezoneOffset·property inV isabsent.
3The{value} of the facet isoptional.
4.3.14.4 Constraints on explicitTimezone Schema Components
Schema Component Constraint: timezone valid restriction
If theexplicitTimezone faceton the{base type definition} has a{value} other thanoptional,then the{value} of the facet on the·restriction·must be equal to the{value} on the{base type definition}; otherwiseit is an·error·.
Note: The effect of this rule is to allow datatypes withaexplicitTimezone value ofoptional to berestricted by specifying a value ofrequiredorprohibited, and to forbid any other derivationsusing this facet.

5 Conformance

XSD 1.1: Datatypes is intendedto be usable in a variety of contexts.

In the usual case, it will embedded in ahost language such as[XSD 1.1 Part 1: Structures],which refers to this specification normatively to define some part ofthe host language. In some cases,XSD 1.1: Datatypes maybe implemented independently of any host language.

Certain aspects of the behavior of conformingprocessors are described in this specification as·implementation-defined· or·implementation-dependent·.
  • [Definition:]  Somethingwhichmay vary among conforming implementations, but whichmustbe specified by the implementor for each particular implementation,isimplementation-defined.
  • [Definition:]  Somethingwhichmay vary among conforming implementations, is not specified bythis or any W3C specification, and is not required to be specifiedby the implementor for any particular implementation,isimplementation-dependent.
Anything described in this specification as·implementation-defined· or·implementation-dependent·may be further constrained by the specifications of a host language in which the datatypes and other materialspecified here are used.A list of implementation-defined and implementation-dependentfeatures can be found inImplementation-defined and implementation-dependent features (normative) (§H)

next sub-section5.1 Host Languages

WhenXSD 1.1: Datatypes is embedded in a hostlanguage, the definition of conformance is specified by thehost language, not by this specification. That is, when thisspecification is implemented in the context of an implementationof a host language, the question of conformance to this specification (separate from the host language) does not arise.

This specification imposes certain constraints on theembedding ofXSD 1.1: Datatypes by a hostlanguage; these are indicated in the normative text bythe use of the verbs 'must', etc., with the phrase "host language" as the subjectof the verb.

Note: For convenience, the most important of these constraintsare noted here:
  • Host languagesshould specify that all of the datatypes describedhere as built-ins are automatically available.
  • Host languagesmay specify that additional datatypes are alsomade available automatically.
  • If user-defined datatypes are to be supported in the host language,then the host languagemust specify how user-defined datatypes aredefined and made available for use.

In addition, host languagesmust require conforming implementations ofthe host language to obey all of the constraints and rulesspecified here.

previous sub-sectionnext sub-section5.2 Independent implementations

[Definition:]  Implementations claimingminimal conformance to this specificationindependent of any host languagemust doall of the following:
1Support all the·built-in· datatypes defined in this specification.
2Completely and correctly implement all of the·constraints on schemas·defined in this specification.
3Completely and correctly implement all of the·Validation Rules·defined in this specification, when checking thedatatype validity of literals against datatypes.
Implementations claimingschema-document-aware conformance to this specification, independent of any host languagemust beminimally conforming. In addition, they must doall of the following:
1Accept simple type definitions in the form specified inDatatype components (§4).
2Completely and correctly implement all of rules governing the XML representation of simple type definitionsspecified inDatatype components (§4).
3Map the XML representations of simple type definitions tosimple type definition components as specified in the mappingrules given inDatatype components (§4).
Note: The termschema-document aware is used here forparallelism with the corresponding term in[XSD 1.1 Part 1: Structures].The reference to schema documents may be taken as referringto the fact that schema-document-aware implementations acceptthe XML representation of simple type definitions found inXSD schema documents. It doesnot mean thatthe simple type definitions must themselves be free-standingXML documents, nor that they typically will be.

previous sub-sectionnext sub-section5.3 Conformance of data

Abstract representations of simple type definitions conform to thisspecification if and only if they obey all of the·constraints on schemas· defined in thisspecification.

XML representations of simple type definitions conform to thisspecification if they obey all of the applicable rulesdefined in this specification.

Note: Because the conformance of the resulting simple type definitioncomponent depends not only on the XML representation of a givensimple type definition, but on the properties of its·base type·, the conformance of an XML representation of a simple type definition does not guarantee that, in the context of other schema components, it will map to a conforming component.

previous sub-section5.4 Partial Implementation of Infinite Datatypes

Some·primitive· datatypes defined in this specification haveinfinite·value spaces·; no finite implementation can completelyhandle all their possible values. For some such datatypes, minimumimplementation limits are specified below. For other infinite typessuch asstring,hexBinary, andbase64Binary, no minimum implementation limits arespecified.

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

When presented with a literal or value exceeding the capacity ofits partial implementation of a datatype, a minimally conformingimplementation of this specification will sometimes be unable todetermine with certainty whether the value is datatype-valid ornot. Sometimes it will be unable to represent the value correctlythrough its interface to any downstream application.

When either of these is so, a conforming processormust indicateto the user and/or downstream application that it cannot processthe input data with assured correctness (much as it would indicateif it ran out of memory). When the datatype validity of a valueor literal is uncertain because it exceeds the capacity of apartial implementation, the literal or valuemust not be treatedas invalid, and the unsupported valuemust not be quietly changedto a supported value.

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

·Minimallyconforming· processorswhich set an application- or·implementation-defined· limit on the size of the values supportedmust clearly documentthat limit.

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

A Schema for Schema Documents (Datatypes) (normative)

The XML representation of the datatypes-relevantpart of the schema for schema documents is presented hereas a normativepart of the specification.Independent copies of this material areavailable in an undated (mutable) version athttp://www.w3.org/2009/XMLSchema/datatypes.xsdand in a dated (immutable) version athttp://www.w3.org/2012/04/datatypes.xsd— the mutable version will be updated with future revisions of this specification, and the immutable one will not.

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

Schema documents conforming to this specification may be in XML1.0 or XML 1.1. Conforming implementations may accept input inXML 1.0 or XML 1.1 or both. SeeDependencies on Other Specifications (§1.3).

Schema for Schema Documents (Datatypes)
<?xml version='1.0'?><!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XSD 1.1//EN" "XMLSchema.dtd" [<!--        Make sure that processors that do not read the external        subset will know about the various IDs we declare  -->        <!ATTLIST xs:simpleType id ID #IMPLIED>        <!ATTLIST xs:maxExclusive id ID #IMPLIED>        <!ATTLIST xs:minExclusive id ID #IMPLIED>        <!ATTLIST xs:maxInclusive id ID #IMPLIED>        <!ATTLIST xs:minInclusive id ID #IMPLIED>        <!ATTLIST xs:totalDigits id ID #IMPLIED>        <!ATTLIST xs:fractionDigits id ID #IMPLIED>        <!ATTLIST xs:length id ID #IMPLIED>        <!ATTLIST xs:minLength id ID #IMPLIED>        <!ATTLIST xs:maxLength id ID #IMPLIED>        <!ATTLIST xs:enumeration id ID #IMPLIED>        <!ATTLIST xs:pattern id ID #IMPLIED>        <!ATTLIST xs:assertion id ID #IMPLIED>        <!ATTLIST xs:explicitTimezone id ID #IMPLIED>        <!ATTLIST xs:appinfo id ID #IMPLIED>        <!ATTLIST xs:documentation id ID #IMPLIED>        <!ATTLIST xs:list id ID #IMPLIED>        <!ATTLIST xs:union id ID #IMPLIED>        ]><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"           elementFormDefault="qualified"            xml:lang="en"           targetNamespace="http://www.w3.org/2001/XMLSchema"           version="datatypes.xsd (rec-20120405)">  <xs:annotation>    <xs:documentation source="../datatypes/datatypes.html">      The schema corresponding to this document is normative,      with respect to the syntactic constraints it expresses in the      XML Schema language.  The documentation (within 'documentation'      elements) below, is not normative, but rather highlights important      aspects of the W3C Recommendation of which this is a part.      See below (at the bottom of this document) for information about      the revision and namespace-versioning policy governing this      schema document.    </xs:documentation>  </xs:annotation>  <xs:simpleType name="derivationControl">    <xs:annotation>      <xs:documentation>   A utility type, not for public use</xs:documentation>    </xs:annotation>    <xs:restriction base="xs:NMTOKEN">      <xs:enumeration value="substitution"/>      <xs:enumeration value="extension"/>      <xs:enumeration value="restriction"/>      <xs:enumeration value="list"/>      <xs:enumeration value="union"/>    </xs:restriction>  </xs:simpleType>  <xs:group name="simpleDerivation">    <xs:choice>      <xs:element ref="xs:restriction"/>      <xs:element ref="xs:list"/>      <xs:element ref="xs:union"/>    </xs:choice>  </xs:group>  <xs:simpleType name="simpleDerivationSet">    <xs:annotation>      <xs:documentation>   #all or (possibly empty) subset of {restriction, extension, union, list}   </xs:documentation>      <xs:documentation>   A utility type, not for public use</xs:documentation>    </xs:annotation>    <xs:union>      <xs:simpleType>        <xs:restriction base="xs:token">          <xs:enumeration value="#all"/>        </xs:restriction>      </xs:simpleType>      <xs:simpleType>        <xs:list>          <xs:simpleType>            <xs:restriction base="xs:derivationControl">              <xs:enumeration value="list"/>              <xs:enumeration value="union"/>              <xs:enumeration value="restriction"/>              <xs:enumeration value="extension"/>            </xs:restriction>          </xs:simpleType>        </xs:list>      </xs:simpleType>    </xs:union>  </xs:simpleType>  <xs:complexType name="simpleType" abstract="true">    <xs:complexContent>      <xs:extension base="xs:annotated">        <xs:group ref="xs:simpleDerivation"/>        <xs:attribute name="final" type="xs:simpleDerivationSet"/>        <xs:attribute name="name" type="xs:NCName">          <xs:annotation>            <xs:documentation>              Can be restricted to required or forbidden            </xs:documentation>          </xs:annotation>        </xs:attribute>      </xs:extension>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="topLevelSimpleType">    <xs:complexContent>      <xs:restriction base="xs:simpleType">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>          <xs:group ref="xs:simpleDerivation"/>        </xs:sequence>        <xs:attribute name="name" type="xs:NCName" use="required">          <xs:annotation>            <xs:documentation>              Required at the top level            </xs:documentation>          </xs:annotation>        </xs:attribute>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="localSimpleType">    <xs:complexContent>      <xs:restriction base="xs:simpleType">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>          <xs:group ref="xs:simpleDerivation"/>        </xs:sequence>        <xs:attribute name="name" use="prohibited">          <xs:annotation>            <xs:documentation>              Forbidden when nested            </xs:documentation>          </xs:annotation>        </xs:attribute>        <xs:attribute name="final" use="prohibited"/>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:element name="simpleType" type="xs:topLevelSimpleType">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-simpleType"/>    </xs:annotation>  </xs:element>  <xs:element name="facet" abstract="true">    <xs:annotation>      <xs:documentation>        An abstract element, representing facets in general.        The facets defined by this spec are substitutable for        this element, and implementation-defined facets should        also name this as a substitution-group head.      </xs:documentation>    </xs:annotation>  </xs:element>  <xs:group name="simpleRestrictionModel">    <xs:sequence>      <xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/>      <xs:choice minOccurs="0"           maxOccurs="unbounded">        <xs:element ref="xs:facet"/>        <xs:any processContents="lax"            namespace="##other"/>      </xs:choice>    </xs:sequence>  </xs:group>  <xs:element name="restriction">    <xs:complexType>      <xs:annotation>        <xs:documentation             source="http://www.w3.org/TR/xmlschema11-2/#element-restriction">          base attribute and simpleType child are mutually          exclusive, but one or other is required        </xs:documentation>      </xs:annotation>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:group ref="xs:simpleRestrictionModel"/>          <xs:attribute name="base" type="xs:QName" use="optional"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="list">    <xs:complexType>      <xs:annotation>        <xs:documentation             source="http://www.w3.org/TR/xmlschema11-2/#element-list">          itemType attribute and simpleType child are mutually          exclusive, but one or other is required        </xs:documentation>      </xs:annotation>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:sequence>            <xs:element name="simpleType" type="xs:localSimpleType"                        minOccurs="0"/>          </xs:sequence>          <xs:attribute name="itemType" type="xs:QName" use="optional"/>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="union">    <xs:complexType>      <xs:annotation>        <xs:documentation             source="http://www.w3.org/TR/xmlschema11-2/#element-union">          memberTypes attribute must be non-empty or there must be          at least one simpleType child        </xs:documentation>      </xs:annotation>      <xs:complexContent>        <xs:extension base="xs:annotated">          <xs:sequence>            <xs:element name="simpleType" type="xs:localSimpleType"                        minOccurs="0" maxOccurs="unbounded"/>          </xs:sequence>          <xs:attribute name="memberTypes" use="optional">            <xs:simpleType>              <xs:list itemType="xs:QName"/>            </xs:simpleType>          </xs:attribute>        </xs:extension>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:complexType name="facet">    <xs:complexContent>      <xs:extension base="xs:annotated">        <xs:attribute name="value" use="required"/>        <xs:attribute name="fixed" type="xs:boolean" default="false"                      use="optional"/>      </xs:extension>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="noFixedFacet">    <xs:complexContent>      <xs:restriction base="xs:facet">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>        </xs:sequence>        <xs:attribute name="fixed" use="prohibited"/>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:element name="minExclusive" type="xs:facet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-minExclusive"/>    </xs:annotation>  </xs:element>  <xs:element name="minInclusive" type="xs:facet"        substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-minInclusive"/>    </xs:annotation>  </xs:element>  <xs:element name="maxExclusive" type="xs:facet"        substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-maxExclusive"/>    </xs:annotation>  </xs:element>  <xs:element name="maxInclusive" type="xs:facet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-maxInclusive"/>    </xs:annotation>  </xs:element>  <xs:complexType name="numFacet">    <xs:complexContent>      <xs:restriction base="xs:facet">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>        </xs:sequence>        <xs:attribute name="value"              type="xs:nonNegativeInteger" use="required"/>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:complexType name="intFacet">    <xs:complexContent>      <xs:restriction base="xs:facet">        <xs:sequence>          <xs:element ref="xs:annotation" minOccurs="0"/>        </xs:sequence>        <xs:attribute name="value" type="xs:integer" use="required"/>        <xs:anyAttribute namespace="##other" processContents="lax"/>      </xs:restriction>    </xs:complexContent>  </xs:complexType>  <xs:element name="totalDigits"    substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-totalDigits"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:restriction base="xs:numFacet">          <xs:sequence>            <xs:element ref="xs:annotation" minOccurs="0"/>          </xs:sequence>          <xs:attribute name="value" type="xs:positiveInteger" use="required"/>          <xs:anyAttribute namespace="##other" processContents="lax"/>        </xs:restriction>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="fractionDigits" type="xs:numFacet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-fractionDigits"/>    </xs:annotation>  </xs:element>  <xs:element name="length" type="xs:numFacet"    substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-length"/>    </xs:annotation>  </xs:element>  <xs:element name="minLength" type="xs:numFacet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-minLength"/>    </xs:annotation>  </xs:element>  <xs:element name="maxLength" type="xs:numFacet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-maxLength"/>    </xs:annotation>  </xs:element>  <xs:element name="enumeration" type="xs:noFixedFacet"         substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-enumeration"/>    </xs:annotation>  </xs:element>  <xs:element name="whiteSpace"    substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-whiteSpace"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:restriction base="xs:facet">          <xs:sequence>            <xs:element ref="xs:annotation" minOccurs="0"/>          </xs:sequence>          <xs:attribute name="value" use="required">            <xs:simpleType>              <xs:restriction base="xs:NMTOKEN">                <xs:enumeration value="preserve"/>                <xs:enumeration value="replace"/>                <xs:enumeration value="collapse"/>              </xs:restriction>            </xs:simpleType>          </xs:attribute>          <xs:anyAttribute namespace="##other" processContents="lax"/>        </xs:restriction>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="pattern"    substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-pattern"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:restriction base="xs:noFixedFacet">          <xs:sequence>            <xs:element ref="xs:annotation" minOccurs="0"/>          </xs:sequence>          <xs:attribute name="value" type="xs:string"                use="required"/>          <xs:anyAttribute namespace="##other"                processContents="lax"/>        </xs:restriction>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:element name="assertion" type="xs:assertion"              substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-assertion"/>    </xs:annotation>  </xs:element>  <xs:element name="explicitTimezone"    substitutionGroup="xs:facet">    <xs:annotation>      <xs:documentation           source="http://www.w3.org/TR/xmlschema11-2/#element-explicitTimezone"/>    </xs:annotation>    <xs:complexType>      <xs:complexContent>        <xs:restriction base="xs:facet">          <xs:sequence>            <xs:element ref="xs:annotation" minOccurs="0"/>          </xs:sequence>          <xs:attribute name="value" use="required">            <xs:simpleType>              <xs:restriction base="xs:NMTOKEN">                <xs:enumeration value="optional"/>                <xs:enumeration value="required"/>                <xs:enumeration value="prohibited"/>              </xs:restriction>            </xs:simpleType>          </xs:attribute>          <xs:anyAttribute namespace="##other" processContents="lax"/>        </xs:restriction>      </xs:complexContent>    </xs:complexType>  </xs:element>  <xs:annotation>    <xs:documentation>      In keeping with the XML Schema WG's standard versioning policy,       this schema document will persist at the URI      http://www.w3.org/2012/04/datatypes.xsd.      At the date of issue it can also be found at the URI      http://www.w3.org/2009/XMLSchema/datatypes.xsd.      The schema document at that URI may however change in the future,       in order to remain compatible with the latest version of XSD       and its namespace.  In other words, if XSD or the XML Schema       namespace change, the version of this document at       http://www.w3.org/2009/XMLSchema/datatypes.xsd will change accordingly;       the version at http://www.w3.org/2012/04/datatypes.xsd will not change.      Previous dated (and unchanging) versions of this schema document       include:        http://www.w3.org/2012/01/datatypes.xsd          (XSD 1.1 Proposed Recommendation)        http://www.w3.org/2011/07/datatypes.xsd          (XSD 1.1 Candidate Recommendation)        http://www.w3.org/2009/04/datatypes.xsd          (XSD 1.1 Candidate Recommendation)        http://www.w3.org/2004/10/datatypes.xsd          (XSD 1.0 Recommendation, Second Edition)        http://www.w3.org/2001/05/datatypes.xsd          (XSD 1.0 Recommendation, First Edition)    </xs:documentation>  </xs:annotation></xs:schema>

B DTD for Datatype Definitions (non-normative)

The DTD for the datatypes-specificaspects of schema documents is given below. Note there isno implication here thatschemamust bethe root element of a document.

DTD for datatype definitions
<!--        DTD for XML Schemas: Part 2: Datatypes                Id: datatypes.dtd,v 1.1.2.4 2005/01/31 18:40:42 cmsmcq Exp         Note this DTD is NOT normative, or even definitive.  --><!--        This DTD cannot be used on its own, it is intended        only for incorporation in XMLSchema.dtd, q.v.  --><!-- Define all the element names, with optional prefix --><!ENTITY % simpleType "%p;simpleType"><!ENTITY % restriction "%p;restriction"><!ENTITY % list "%p;list"><!ENTITY % union "%p;union"><!ENTITY % maxExclusive "%p;maxExclusive"><!ENTITY % minExclusive "%p;minExclusive"><!ENTITY % maxInclusive "%p;maxInclusive"><!ENTITY % minInclusive "%p;minInclusive"><!ENTITY % totalDigits "%p;totalDigits"><!ENTITY % fractionDigits "%p;fractionDigits"><!ENTITY % length "%p;length"><!ENTITY % minLength "%p;minLength"><!ENTITY % maxLength "%p;maxLength"><!ENTITY % enumeration "%p;enumeration"><!ENTITY % whiteSpace "%p;whiteSpace"><!ENTITY % pattern "%p;pattern"><!ENTITY % assertion "%p;assertion"><!ENTITY % explicitTimezone "%p;explicitTimezone"><!--        Customization entities for the ATTLIST of each element        type. Define one of these if your schema takes advantage        of the anyAttribute='##other' in the schema for schemas  --><!ENTITY % simpleTypeAttrs ""><!ENTITY % restrictionAttrs ""><!ENTITY % listAttrs ""><!ENTITY % unionAttrs ""><!ENTITY % maxExclusiveAttrs ""><!ENTITY % minExclusiveAttrs ""><!ENTITY % maxInclusiveAttrs ""><!ENTITY % minInclusiveAttrs ""><!ENTITY % totalDigitsAttrs ""><!ENTITY % fractionDigitsAttrs ""><!ENTITY % lengthAttrs ""><!ENTITY % minLengthAttrs ""><!ENTITY % maxLengthAttrs ""><!ENTITY % enumerationAttrs ""><!ENTITY % whiteSpaceAttrs ""><!ENTITY % patternAttrs ""><!ENTITY % assertionAttrs ""><!ENTITY % explicitTimezoneAttrs ""><!-- Define some entities for informative use as attribute        types --><!ENTITY % URIref "CDATA"><!ENTITY % XPathExpr "CDATA"><!ENTITY % QName "NMTOKEN"><!ENTITY % QNames "NMTOKENS"><!ENTITY % NCName "NMTOKEN"><!ENTITY % nonNegativeInteger "NMTOKEN"><!ENTITY % boolean "(true|false)"><!ENTITY % simpleDerivationSet "CDATA"><!--        #all or space-separated list drawn from derivationChoice  --><!--        Note that the use of 'facet' below is less restrictive        than is really intended:  There should in fact be no        more than one of each of minInclusive, minExclusive,        maxInclusive, maxExclusive, totalDigits, fractionDigits,        length, maxLength, minLength within datatype,        and the min- and max- variants of Inclusive and Exclusive        are mutually exclusive. On the other hand,  pattern and        enumeration and assertion may repeat.  --><!ENTITY % minBound "(%minInclusive; | %minExclusive;)"><!ENTITY % maxBound "(%maxInclusive; | %maxExclusive;)"><!ENTITY % bounds "%minBound; | %maxBound;"><!ENTITY % numeric "%totalDigits; | %fractionDigits;"> <!ENTITY % ordered "%bounds; | %numeric;"><!ENTITY % unordered   "%pattern; | %enumeration; | %whiteSpace; | %length; |   %maxLength; | %minLength; | %assertion;   | %explicitTimezone;"><!ENTITY % implementation-defined-facets ""><!ENTITY % facet "%ordered; | %unordered; %implementation-defined-facets;"><!ENTITY % facetAttr         "value CDATA #REQUIRED        id ID #IMPLIED"><!ENTITY % fixedAttr "fixed %boolean; #IMPLIED"><!ENTITY % facetModel "(%annotation;)?"><!ELEMENT %simpleType;        ((%annotation;)?, (%restriction; | %list; | %union;))><!ATTLIST %simpleType;    name      %NCName; #IMPLIED    final     %simpleDerivationSet; #IMPLIED    id        ID       #IMPLIED    %simpleTypeAttrs;><!-- name is required at top level --><!ELEMENT %restriction; ((%annotation;)?,                         (%restriction1; |                          ((%simpleType;)?,(%facet;)*)),                         (%attrDecls;))><!ATTLIST %restriction;    base      %QName;                  #IMPLIED    id        ID       #IMPLIED    %restrictionAttrs;><!--        base and simpleType child are mutually exclusive,        one is required.        restriction is shared between simpleType and        simpleContent and complexContent (in XMLSchema.xsd).        restriction1 is for the latter cases, when this        is restricting a complex type, as is attrDecls.  --><!ELEMENT %list; ((%annotation;)?,(%simpleType;)?)><!ATTLIST %list;    itemType      %QName;             #IMPLIED    id        ID       #IMPLIED    %listAttrs;><!--        itemType and simpleType child are mutually exclusive,        one is required  --><!ELEMENT %union; ((%annotation;)?,(%simpleType;)*)><!ATTLIST %union;    id            ID       #IMPLIED    memberTypes   %QNames;            #IMPLIED    %unionAttrs;><!--        At least one item in memberTypes or one simpleType        child is required  --><!ELEMENT %maxExclusive; %facetModel;><!ATTLIST %maxExclusive;        %facetAttr;        %fixedAttr;        %maxExclusiveAttrs;><!ELEMENT %minExclusive; %facetModel;><!ATTLIST %minExclusive;        %facetAttr;        %fixedAttr;        %minExclusiveAttrs;><!ELEMENT %maxInclusive; %facetModel;><!ATTLIST %maxInclusive;        %facetAttr;        %fixedAttr;        %maxInclusiveAttrs;><!ELEMENT %minInclusive; %facetModel;><!ATTLIST %minInclusive;        %facetAttr;        %fixedAttr;        %minInclusiveAttrs;><!ELEMENT %totalDigits; %facetModel;><!ATTLIST %totalDigits;        %facetAttr;        %fixedAttr;        %totalDigitsAttrs;><!ELEMENT %fractionDigits; %facetModel;><!ATTLIST %fractionDigits;        %facetAttr;        %fixedAttr;        %fractionDigitsAttrs;><!ELEMENT %length; %facetModel;><!ATTLIST %length;        %facetAttr;        %fixedAttr;        %lengthAttrs;><!ELEMENT %minLength; %facetModel;><!ATTLIST %minLength;        %facetAttr;        %fixedAttr;        %minLengthAttrs;><!ELEMENT %maxLength; %facetModel;><!ATTLIST %maxLength;        %facetAttr;        %fixedAttr;        %maxLengthAttrs;><!-- This one can be repeated --><!ELEMENT %enumeration; %facetModel;><!ATTLIST %enumeration;        %facetAttr;        %enumerationAttrs;><!ELEMENT %whiteSpace; %facetModel;><!ATTLIST %whiteSpace;        %facetAttr;        %fixedAttr;        %whiteSpaceAttrs;><!-- This one can be repeated --><!ELEMENT %pattern; %facetModel;><!ATTLIST %pattern;        %facetAttr;        %patternAttrs;><!ELEMENT %assertion; %facetModel;><!ATTLIST %assertion;        %facetAttr;        %assertionAttrs;><!ELEMENT %explicitTimezone; %facetModel;><!ATTLIST %explicitTimezone;        %facetAttr;        %explicitTimezoneAttrs;>

C Illustrative XML representations for the built-in simple type definitions

next sub-sectionC.1 Illustrative XML representations for the built-in primitive type definitions

The following, although in the form of aschema document, does not conform to the rules for schema documentsdefined in this specification. It contains explicit XMLrepresentations of the primitive datatypes which need not be declaredin a schema document, since they are automatically included in everyschema, and indeed must not be declared in a schema document, since itis forbidden to try to derive types withanyAtomicTypeas the base type definition. It is included here as a form ofdocumentation.

The (not a) schema document for primitive built-in type definitions
<?xml version='1.0'?><!DOCTYPE xs:schema SYSTEM "../namespace/XMLSchema.dtd" [<!--     keep this schema XML1.0 DTD valid  -->        <!ENTITY % schemaAttrs 'xmlns:hfp CDATA #IMPLIED'>        <!ELEMENT hfp:hasFacet EMPTY>        <!ATTLIST hfp:hasFacet                name NMTOKEN #REQUIRED>        <!ELEMENT hfp:hasProperty EMPTY>        <!ATTLIST hfp:hasProperty                name NMTOKEN #REQUIRED                value CDATA #REQUIRED>]><xs:schema  xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"   xmlns:xs="http://www.w3.org/2001/XMLSchema"  elementFormDefault="qualified"   xml:lang="en"   targetNamespace="http://www.w3.org/2001/XMLSchema">  <xs:annotation>    <xs:documentation>      This document contains XML elements which look like       definitions for the primitive datatypes.  These definitions are for      information only; the real built-in definitions are magic.    </xs:documentation>    <xs:documentation>      For each built-in datatype in this schema (both primitive and      derived) can be uniquely addressed via a URI constructed      as follows:        1) the base URI is the URI of the XML Schema namespace        2) the fragment identifier is the name of the datatype      For example, to address the int datatype, the URI is:        http://www.w3.org/2001/XMLSchema#int      Additionally, each facet definition element can be uniquely      addressed via a URI constructed as follows:        1) the base URI is the URI of the XML Schema namespace        2) the fragment identifier is the name of the facet      For example, to address the maxInclusive facet, the URI is:        http://www.w3.org/2001/XMLSchema#maxInclusive      Additionally, each facet usage in a built-in datatype definition      can be uniquely addressed via a URI constructed as follows:        1) the base URI is the URI of the XML Schema namespace        2) the fragment identifier is the name of the datatype, followed           by a period (".") followed by the name of the facet      For example, to address the usage of the maxInclusive facet in      the definition of int, the URI is:        http://www.w3.org/2001/XMLSchema#int.maxInclusive    </xs:documentation>  </xs:annotation>  <xs:simpleType name="string">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#string"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace value="preserve"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="boolean">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="finite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#boolean"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="float">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="true"/>        <hfp:hasProperty name="cardinality" value="finite"/>        <hfp:hasProperty name="numeric" value="true"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#float"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="double">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="true"/>        <hfp:hasProperty name="cardinality" value="finite"/>        <hfp:hasProperty name="numeric" value="true"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#double"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="decimal">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="totalDigits"/>        <hfp:hasFacet name="fractionDigits"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="total"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="true"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#decimal"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="duration">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#duration"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="dateTime">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#dateTime"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="time">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#time"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="date">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#date"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="gYearMonth">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#gYearMonth"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="gYear">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#gYear"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="gMonthDay">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#gMonthDay"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="gDay">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#gDay"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="gMonth">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="maxInclusive"/>        <hfp:hasFacet name="maxExclusive"/>        <hfp:hasFacet name="minInclusive"/>        <hfp:hasFacet name="minExclusive"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasFacet name="explicitTimezone"/>        <hfp:hasProperty name="ordered" value="partial"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#gMonth"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>      <xs:explicitTimezone value="optional"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="hexBinary">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#hexBinary"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="base64Binary">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#base64Binary"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="anyURI">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#anyURI"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="QName">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#QName"/>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="NOTATION">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#NOTATION"/>      <xs:documentation>        NOTATION cannot be used directly in a schema; rather a type        must be derived from it by specifying at least one enumeration        facet whose value is the name of a NOTATION declared in the        schema.      </xs:documentation>    </xs:annotation>    <xs:restriction base="xs:anyAtomicType">      <xs:whiteSpace fixed="true" value="collapse"/>    </xs:restriction>  </xs:simpleType></xs:schema>

previous sub-sectionC.2 Illustrative XML representations for the built-in ordinary type definitions

The following, although in the form of aschema document, contains XML representations of components alreadypresent in all schemas by definition. It is included here as a formof documentation.

Note: These datatypes do not need to be declared in a schema document,since they are automatically included in every schema.
Issue (B-1933):
It is an open question whether this and similar XML documents shouldbe accepted or rejected by software conforming to this specification.The XML Schema Working Group expects to resolve this question in connectionwith its work on issues relating to schema composition.
In the meantime, some existing schema processors will acceptdeclarations for them; other existing processors will reject suchdeclarations as duplicates.
Illustrative schema document for derived built-in type definitions
<?xml version='1.0'?><!DOCTYPE xs:schema SYSTEM "../namespace/XMLSchema.dtd" [<!--     keep this schema XML1.0 DTD valid  -->        <!ENTITY % schemaAttrs 'xmlns:hfp CDATA #IMPLIED'>        <!ELEMENT hfp:hasFacet EMPTY>        <!ATTLIST hfp:hasFacet                name NMTOKEN #REQUIRED>        <!ELEMENT hfp:hasProperty EMPTY>        <!ATTLIST hfp:hasProperty                name NMTOKEN #REQUIRED                value CDATA #REQUIRED>]><xs:schema  xmlns:hfp="http://www.w3.org/2001/XMLSchema-hasFacetAndProperty"  xmlns:xs="http://www.w3.org/2001/XMLSchema"  elementFormDefault="qualified"   xml:lang="en"   targetNamespace="http://www.w3.org/2001/XMLSchema"> <xs:annotation>    <xs:documentation>      This document contains XML representations for the      ordinary non-primitive built-in datatypes    </xs:documentation>  </xs:annotation>  <xs:simpleType name="normalizedString">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#normalizedString"/>    </xs:annotation>    <xs:restriction base="xs:string">      <xs:whiteSpace value="replace"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="token">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#token"/>    </xs:annotation>    <xs:restriction base="xs:normalizedString">      <xs:whiteSpace value="collapse"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="language">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#language"/>    </xs:annotation>    <xs:restriction base="xs:token">      <xs:pattern value="[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*">        <xs:annotation>          <xs:documentation source="http://www.ietf.org/rfc/bcp/bcp47.txt">            pattern specifies the content of section 2.12 of XML 1.0e2            and RFC 3066 (Revised version of RFC 1766).  N.B. RFC 3066 is now            obsolete; the grammar of RFC4646 is more restrictive.  So strict            conformance to the rules for language codes requires extra checking            beyond validation against this type.          </xs:documentation>        </xs:annotation>      </xs:pattern>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="IDREFS">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#IDREFS"/>    </xs:annotation>    <xs:restriction>      <xs:simpleType>        <xs:list itemType="xs:IDREF"/>      </xs:simpleType>      <xs:minLength value="1"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="ENTITIES">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#ENTITIES"/>    </xs:annotation>    <xs:restriction>      <xs:simpleType>        <xs:list itemType="xs:ENTITY"/>      </xs:simpleType>      <xs:minLength value="1"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="NMTOKEN">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#NMTOKEN"/>    </xs:annotation>    <xs:restriction base="xs:token">      <xs:pattern value="\c+">        <xs:annotation>          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Nmtoken">            pattern matches production 7 from the XML spec          </xs:documentation>        </xs:annotation>      </xs:pattern>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="NMTOKENS">    <xs:annotation>      <xs:appinfo>        <hfp:hasFacet name="length"/>        <hfp:hasFacet name="minLength"/>        <hfp:hasFacet name="maxLength"/>        <hfp:hasFacet name="enumeration"/>        <hfp:hasFacet name="whiteSpace"/>        <hfp:hasFacet name="pattern"/>        <hfp:hasFacet name="assertions"/>        <hfp:hasProperty name="ordered" value="false"/>        <hfp:hasProperty name="bounded" value="false"/>        <hfp:hasProperty name="cardinality" value="countably infinite"/>        <hfp:hasProperty name="numeric" value="false"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#NMTOKENS"/>    </xs:annotation>    <xs:restriction>      <xs:simpleType>        <xs:list itemType="xs:NMTOKEN"/>      </xs:simpleType>      <xs:minLength value="1"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="Name">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#Name"/>    </xs:annotation>    <xs:restriction base="xs:token">      <xs:pattern value="\i\c*">        <xs:annotation>          <xs:documentation source="http://www.w3.org/TR/REC-xml#NT-Name">            pattern matches production 5 from the XML spec          </xs:documentation>        </xs:annotation>      </xs:pattern>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="NCName">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#NCName"/>    </xs:annotation>    <xs:restriction base="xs:Name">      <xs:pattern value="[\i-[:]][\c-[:]]*">        <xs:annotation>          <xs:documentation source="http://www.w3.org/TR/REC-xml-names/#NT-NCName">            pattern matches production 4 from the Namespaces in XML spec          </xs:documentation>        </xs:annotation>      </xs:pattern>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="ID">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#ID"/>    </xs:annotation>    <xs:restriction base="xs:NCName"/>  </xs:simpleType>  <xs:simpleType name="IDREF">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#IDREF"/>    </xs:annotation>    <xs:restriction base="xs:NCName"/>  </xs:simpleType>  <xs:simpleType name="ENTITY">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#ENTITY"/>    </xs:annotation>    <xs:restriction base="xs:NCName"/>  </xs:simpleType>  <xs:simpleType name="integer">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#integer"/>    </xs:annotation>    <xs:restriction base="xs:decimal">      <xs:fractionDigits fixed="true" value="0"/>      <xs:pattern value="[\-+]?[0-9]+"/>          </xs:restriction>  </xs:simpleType>  <xs:simpleType name="nonPositiveInteger">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#nonPositiveInteger"/>    </xs:annotation>    <xs:restriction base="xs:integer">      <xs:maxInclusive value="0"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="negativeInteger">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#negativeInteger"/>    </xs:annotation>    <xs:restriction base="xs:nonPositiveInteger">      <xs:maxInclusive value="-1"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="long">    <xs:annotation>      <xs:appinfo>        <hfp:hasProperty name="bounded" value="true"/>        <hfp:hasProperty name="cardinality" value="finite"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#long"/>    </xs:annotation>    <xs:restriction base="xs:integer">      <xs:minInclusive value="-9223372036854775808"/>      <xs:maxInclusive value="9223372036854775807"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="int">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#int"/>    </xs:annotation>    <xs:restriction base="xs:long">      <xs:minInclusive value="-2147483648"/>      <xs:maxInclusive value="2147483647"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="short">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#short"/>    </xs:annotation>    <xs:restriction base="xs:int">      <xs:minInclusive value="-32768"/>      <xs:maxInclusive value="32767"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="byte">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#byte"/>    </xs:annotation>    <xs:restriction base="xs:short">      <xs:minInclusive value="-128"/>      <xs:maxInclusive value="127"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="nonNegativeInteger">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#nonNegativeInteger"/>    </xs:annotation>    <xs:restriction base="xs:integer">      <xs:minInclusive value="0"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="unsignedLong">    <xs:annotation>      <xs:appinfo>        <hfp:hasProperty name="bounded" value="true"/>        <hfp:hasProperty name="cardinality" value="finite"/>      </xs:appinfo>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#unsignedLong"/>    </xs:annotation>    <xs:restriction base="xs:nonNegativeInteger">      <xs:maxInclusive value="18446744073709551615"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="unsignedInt">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#unsignedInt"/>    </xs:annotation>    <xs:restriction base="xs:unsignedLong">      <xs:maxInclusive value="4294967295"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="unsignedShort">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#unsignedShort"/>    </xs:annotation>    <xs:restriction base="xs:unsignedInt">      <xs:maxInclusive value="65535"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="unsignedByte">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#unsignedByte"/>    </xs:annotation>    <xs:restriction base="xs:unsignedShort">      <xs:maxInclusive value="255"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="positiveInteger">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#positiveInteger"/>    </xs:annotation>    <xs:restriction base="xs:nonNegativeInteger">      <xs:minInclusive value="1"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="yearMonthDuration">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#yearMonthDuration">        This type includes just those durations expressed in years and months.        Since the pattern given excludes days, hours, minutes, and seconds,        the values of this type have a seconds property of zero.  They are        totally ordered.      </xs:documentation>    </xs:annotation>    <xs:restriction base="xs:duration">      <xs:pattern value="[^DT]*"/>    </xs:restriction>  </xs:simpleType>  <xs:simpleType name="dayTimeDuration">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#dayTimeDuration">        This type includes just those durations expressed in days, hours, minutes, and seconds.        The pattern given excludes years and months, so the values of this type         have a months property of zero.  They are totally ordered.      </xs:documentation>    </xs:annotation>    <xs:restriction base="xs:duration">      <xs:pattern value="[^YM]*(T.*)?"/>     </xs:restriction>  </xs:simpleType>    <xs:simpleType name="dateTimeStamp">    <xs:annotation>      <xs:documentation source="http://www.w3.org/TR/xmlschema11-2/#dateTimeStamp">        This datatype includes just those dateTime values Whose explicitTimezone        is present.  They are totally ordered.      </xs:documentation>    </xs:annotation>    <xs:restriction base="xs:dateTime">      <xs:explicitTimezone fixed="true"        value="required"/>     </xs:restriction>  </xs:simpleType></xs:schema>

D Built-up Value Spaces

Some datatypes, such asinteger, describe well-known mathematically abstract systems.  Others, such as the date/time datatypes, describe "real-life", "applied" systems.  Certainof the systems described by datatypes, both abstract andapplied, have values in their value spaces most easily described as thingshaving severalproperties, which in turn have values which arein some sense "primitive" or are from the value spaces ofsimpler datatypes.

Inthis document, the arguments to functions are assumed to be "call byvalue" unless explicitly noted to the contrary, meaning that if the argument is modifiedduring the processing of the algorithm, that modification isnot reflected in the"outside world".  On the other hand, the arguments to procedures are assumedto be "call by location", meaning that modificationsare so reflected,since that is the only way the processing of the algorithm can have any effect.

Properties always have values. [Definition:]  Anoptionalproperty ispermitted but notrequired to have the distinguishedvalueabsent.

[Definition:]  Throughout thisspecification, the valueabsent is used as a distinguished value to indicate that a given instance of a property"has no value" or "is absent". This should not be interpreted as constraining implementations, as for instancebetween using anullvalue for such properties or not representing them at all.

Thosevalues that are more primitive, and are used (among other things) herein toconstruct object value spaces but which we do not explicitly define aredescribed here:
  • Anumber (without precision) is an ordinarymathematical number; 1, 1.0, and1.000000000000 are the samenumber.  The decimalnumbers and integersgenerally used in the algorithms ofappendixFunctionDefinitions (§E) aresuchordinary numbers, not carrying precision.
  • [Definition:]  Aspecial value is an objectwhose only relevant properties for purposes of this specification are that itis distinct from, and unequal to, any other values (special or otherwise). A few special values in different value spaces (e.g.positiveInfinity,negativeInfinity, andnotANumber infloat anddouble) share names.  Thus, special values can be distinguished from each other in thegeneral case by considering both the name and the primitive datatype of the value; insomecases, of course, the name alone suffices to identify the value uniquely.
    Note: In the case offloatanddouble, the·special values· are members of thedatatype's·value space·

next sub-sectionD.1 Numerical Values

The following standard operators are defined herein case the reader is unsure of their definition:
Note:n ·div· 1  is a convenient and short way ofexpressing "the greatest integer lessthan or equal ton".

D.1.1 Exact Lexical Mappings

Numerals and Fragments Thereof
[45]  digit ::= [0-9]
[46]  unsignedNoDecimalPtNumeral ::=digit+
[47]  noDecimalPtNumeral ::= ('+' | '-')? unsignedNoDecimalPtNumeral
[48]  fracFrag ::=digit+
[49]  unsignedDecimalPtNumeral ::= (unsignedNoDecimalPtNumeral '.fracFrag?) | ('.fracFrag)
[50]  unsignedFullDecimalPtNumeral ::=unsignedNoDecimalPtNumeral '.fracFrag
[51]  decimalPtNumeral ::= ('+' | '-')? unsignedDecimalPtNumeral
[52]  unsignedScientificNotationNumeral ::= (unsignedNoDecimalPtNumeral | unsignedDecimalPtNumeral) ('e' | 'E')noDecimalPtNumeral
[53]  scientificNotationNumeral ::= ('+' | '-')? unsignedScientificNotationNumeral
Generic Numeral-to-Number Lexical Mappings
·unsignedNoDecimalMap· (N) → integer
Maps anunsignedNoDecimalPtNumeral to its numerical value.
·noDecimalMap· (N) → integer
Maps annoDecimalPtNumeral to its numerical value.
·unsignedDecimalPtMap· (D) → decimal number
Maps anunsignedDecimalPtNumeral to its numerical value.
·decimalPtMap· (N) → decimal number
Maps adecimalPtNumeral to its numerical value.
·scientificMap· (N) → decimal number
Maps ascientificNotationNumeral to its numerical value.
Generic Number to Numeral Canonical Mappings
Maps a nonnegative integer to aunsignedNoDecimalPtNumeral, its·canonical representation·.
Maps a nonnegative decimal number to aunsignedDecimalPtNumeral, its·canonical representation·.
Maps a decimal number to adecimalPtNumeral, its·canonical representation·.
Maps a nonnegative decimal number to aunsignedScientificNotationNumeral, its·canonical representation·.
Some numerical datatypes include some or all of three non-numerical·special values·:positiveInfinity,negativeInfinity, andnotANumber.  Their lexical spacesinclude non-numeral lexical representations for these non-numeric values:
Special Non-numerical Lexical Representations Used With Numerical Datatypes
[54]  minimalNumericalSpecialRep ::= 'INF' | '-INF' | 'NaN'
[55]  numericalSpecialRep ::= '+INF' | minimalNumericalSpecialRep
Lexical Mapping for Non-numerical·Special Values· Used With Numerical Datatypes
Maps the·lexical representations· of·special values· used with somenumerical datatypes to those·special values·.
Canonical Mapping for Non-numerical·Special Values· Used with Numerical Datatypes
Maps the·special values· used with some numerical datatypes to their·canonical representations·.

previous sub-sectionD.2 Date/time Values

        D.2.1The Seven-property Model
        D.2.2Lexical Mappings

There are several different primitive butrelated datatypes defined in the specification which pertain tovarious combinations of dates and times, and parts thereof.  Theyall use related value-space models, which are described in detail inthis section.  It is not difficult for a casual reader of thedescriptions of the individual datatypes elsewhere in thisspecification to misunderstand some of the details of just what thedatatypes are intended to represent, so more detail is presented herein this section.

All of the value spaces for dates and timesdescribed here represent moments or periods of time in UniversalCoordinated Time (UTC). [Definition:]  UniversalCoordinated Time (UTC)is an adaptation of TAI which closely approximates UT1 by adding·leap-seconds· to selected·UTC· days.

[Definition:]  Aleap-second is an additional second addedto the last day of December, June, October, or March,when such an adjustment is deemed necessary by the International Earth Rotation and Reference Systems Servicein order to keep·UTC· within 0.9 secondsof observed astronomical time.  When leap seconds areintroduced, the last minute in the day has more thansixty seconds. In theory leap seconds can also be removed from aday, but this has not yet occurred.(See[International Earth Rotation Service (IERS)],[ITU-R TF.460-6].)Leap seconds arenot supported by the types defined here.

Because thedateTime type andother date- and time-related types defined in this specification donot support leap seconds, there are portions of the·UTC· timeline which cannot be represented by values of thesetypes. Users whose applications require that leap seconds berepresented and that date/time arithmetic take historicallyoccurring leap seconds into account will wish to makeappropriate adjustments at the application level, or to use other types.

D.2.1 The Seven-property Model

There are two distinct ways to model moments in time:  eitherby tracking their year, month, day, hour, minute and second (withfractional seconds as needed), or by trackingtheir time (measured generally in seconds ordays) from some starting moment.  Each hasits advantages.  The two are isomorphic.  Fordefiniteness, we choose to model the firstusing five integer and one decimal number properties.  We superimposethe second by providing one decimal number-valuedfunction which gives the corresponding count ofseconds from zero (the "time on the time line").

There is also a seventhinteger property whichspecifies the time zone offsetas the number of minutes of offset from UTC.  Values for thesix primary properties are always stored intheir"local" values (the values shown in the lexicalrepresentations), rather than converted to·UTC·.
an integer
an integer between 1 and 12 inclusive
an integer between 1 and31 inclusive, possiblyrestricted further depending on·month· and·year·
an integer between 0 and 23 inclusive
an integer between 0 and 59 inclusive
a decimal number greater than or equalto0 and less than 60.
an·optional· integer between −840and 840 inclusive

Non-negative values of the properties map to the years, months, days of month, etc. of the Gregoriancalendar in the obvious way. Values less than 1582 in the·year· property represent years in the"proleptic Gregorian calendar".A value of zero in the·year· property represents the year 1 BCE;a value of −1 represents the year 2 BCE, −2 is 3 BCE,etc.

Note: In version 1.0 of this specification, the·year· property was not permitted to have the valuezero. The year before the year 1 in theproleptic Gregorian calendar, traditionally referred to as 1 BC or as1 BCE, was represented by a·year· value of −1, 2 BCE by −2, and soforth.Of course, many, perhaps most,references to 1 BCE (or 1 BC) actually refer not to a year in the proleptic Gregorian calendar but to a year in theJulian or "old style" calendar; the two correspondapproximately but not exactly to each other.
In this version of this specification,two changes are made in order to agree with existing usage. First,·year· is permitted to have the value zero.Second, the interpretation of·year· values is changed accordingly: a·year· value of zero represents 1 BCE, −1represents 2 BCE, etc. This representation simplifies intervalarithmetic and leap-year calculation for dates before the common era (which may be why astronomersand others interested in such calculations with the prolepticGregorian calendar have adopted it), and is consistent with thecurrent edition of[ISO 8601].
Note that 1 BCE, 5 BCE, and so on (years 0000, −0004, etc. in thelexical representation defined here) are leap years in the prolepticGregorian calendar used for the date/time datatypes defined here.Version 1.0 of this specification was unclear about the treatment ofleap years before the common era.If existingschemas or data specify dates of 29 February for any years before thecommon era, then some values givinga date of 29 February which were valid under a plausibleinterpretation 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 validunder the old interpretation remain valid under the new.

The model just described is called herein the"seven-property" model for date/time datatypes.  It is used "as is"fordateTime; all other date/time datatypes exceptduration use thesame model except that some of the six primary properties arerequired to have thevalueabsent, instead of being required to have a numerical value.  (An·optional· property, like·timezoneOffset·,is alwayspermitted to have the valueabsent.)

·timezoneOffset· values are limited to 14 hours,which is 840 (= 60 × 14) minutes.

Note: Leap-seconds are not permitted

Readersinterested in when leap-seconds have been introduced shouldconsult[USNO Historical List], which includes a listof times when the difference between TAI and·UTC· has changed. Because the simple types defined here do not support leap seconds, they cannot be used to represent the final second, in·UTC·, of any of the days containingone.  If it is important, at the application level,to track the occurrence of leap seconds, then users will need to makespecial arrangements for special handling of them andof time intervals crossing them.

While calculating, property values from thedateTime 1972-12-31T00:00:00 are used to fill infor those that areabsent, exceptthat if·day· isabsentbut·month· is not, the largest permittedday for that month is used.

Time on Timeline for Date/time Seven-propertyModel Datatypes
·timeOnTimeline· (dt) → decimal number
Maps adate/timeSevenPropertyModel value to the decimal numberrepresenting its position on the "time line".
Values from any one date/time datatype using the seven-componentmodel (all exceptduration)are ordered the same as their·timeOnTimeline· values,except that if one value's·timezoneOffset·isabsent and the other's is not, and using maximum and minimum·timezoneOffset·values for the one whose·timezoneOffset·is actuallyabsentchanges the resulting (strict)inequality, the original two values are incomparable.

D.2.2 Lexical Mappings

[Definition:]  Eachlexical representation is made up of certaindate/time fragments, each of which corresponds to a particular property of the datatypevalue.  They are defined by the following productions.
Date/time Lexical Representation Fragments
[56]  yearFrag ::= '-'?(([1-9digit digit digit+)) |('0digit digit digit))
[57]  monthFrag ::= ('0' [1-9]) |('1' [0-2])
[58]  dayFrag ::= ('0' [1-9]) | ([12digit) |('3' [01])
[59]  hourFrag ::= ([01digit) |('2' [0-3])
[60]  minuteFrag ::= [0-5digit
[61]  secondFrag ::= ([0-5digit) ('.digit+)?
[62]  endOfDayFrag ::= '24:00:00' ('.' '0'+)?
[63]  timezoneFrag ::= 'Z' | ('+' | '-') (('0digit | '1' [0-3]) ':minuteFrag | '14:00')
Each fragment other thantimezoneFrag defines a subset ofthe·lexical space· ofdecimal; the corresponding·lexical mapping· is thedecimal·lexical mapping· restricted to thatsubset.  These fragment·lexical mappings· are combinedseparately for each date/time datatype (other thanduration) to make up·the complete lexical mapping· forthat datatype.  The·yearFragValue· mapping is used toobtain the value of the·year· property, the·monthFragValue· mapping is used to obtain the value of the·month· property, etc.  Each datatype which specifiessome properties to be mandatorilyabsent also does not permitthe corresponding lexical fragments in its lexical representations.
Partial Date/time Lexical Mappings
·yearFragValue· (YR) → integer
Maps ayearFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·year· property of adate/timeSevenPropertyModel value.
·monthFragValue· (MO) → integer
Maps amonthFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·month· property of adate/timeSevenPropertyModel value.
·dayFragValue· (DA) → integer
Maps adayFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·day· property of adate/timeSevenPropertyModel value.
·hourFragValue· (HR) → integer
Maps ahourFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·hour· property of adate/timeSevenPropertyModel value.
·minuteFragValue· (MI) → integer
Maps aminuteFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·minute· property of adate/timeSevenPropertyModel value.
·secondFragValue· (SE) → decimal number
Maps asecondFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto a decimal number, presumably the·second· property of adate/timeSevenPropertyModel value.
·timezoneFragValue· (TZ) → integer
Note: The redundancy between'Z', '+00:00', and'-00:00', and the possibility of trailing fractional'0' digits forsecondFrag, are the onlyredundancies preventing these mappings from being one-to-one. Thereis no·lexical mapping· forendOfDayFrag; it is handledspecially by the relevant·lexical mappings·.  See, e.g.,·dateTimeLexicalMap·.
The following fragment·canonical mappings· for each value-objectproperty are combined as appropriate to make the·canonical mapping·for each date/time datatype (otherthanduration):
Partial Date/time Canonical Mappings
Maps an integer, presumably the·year· property of adate/timeSevenPropertyModel value,onto ayearFrag, part of adate/timeSevenPropertyModel's·lexical representation·.
Maps an integer, presumably the·month· property of adate/timeSevenPropertyModel value,onto amonthFrag, part of adate/timeSevenPropertyModel's·lexical representation·.
Maps an integer, presumably the·day· property of adate/timeSevenPropertyModel value,onto adayFrag, part of adate/timeSevenPropertyModel's·lexical representation·.
Maps an integer, presumably the·hour· property of adate/timeSevenPropertyModel value,onto ahourFrag, part of adate/timeSevenPropertyModel's·lexical representation·.
Maps an integer, presumably the·minute· property of adate/timeSevenPropertyModel value,onto aminuteFrag, part of adate/timeSevenPropertyModel's·lexical representation·.
Maps a decimal number, presumably the·second· property of adate/timeSevenPropertyModel value,onto asecondFrag, part of adate/timeSevenPropertyModel's·lexical representation·.

E FunctionDefinitions

The more important functions andprocedures defined here are summarized in thetext  When there is a text summary, the name of the function in each is a"hot-link" to the same name in the other.  All other linksto these functions link to the complete definition in this section.

next sub-sectionE.1 Generic Number-related Functions

The following functions are used with various numeric and date/time datatypes.

Auxiliary Functions for Operating on Numeral Fragments
·digitValue· (d) → integer
Maps each digit to its numerical value.
Arguments:
dmatchesdigit
Result:
a nonnegative integer less than ten
Algorithm:
Return
  • 0   when d = '0' ,
  • 1   when d = '1' ,
  • 2   when d = '2' ,
  • etc.
·digitSequenceValue· (S) → integer
Maps a sequence of digits to the position-weighted sum of the terms numerical values.
Arguments:
Sa finite sequence of·literals·, each term matchingdigit.
Result:
a nonnegative integer
Algorithm:
Return the sum of·digitValue·(Si) × 10length(S)−i wherei runs over the domain ofS.
·fractionDigitSequenceValue· (S) → integer
Maps a sequence of digits to the position-weighted sum of the terms numerical values, weighted appropriately for fractional digits.
Arguments:
Sa finite sequence of·literals·, each term matchingdigit.
Result:
a nonnegative integer
Algorithm:
Return the sum of·digitValue·(Si) − 10i wherei runs over the domain ofS.
·fractionFragValue· (N) → decimal number
Maps afracFrag to the appropriate fractional decimal number.
Arguments:
NmatchesfracFrag
Result:
a nonnegative decimal number
Algorithm:
N is necessarily the left-to-right concatenation of a finite sequenceS of·literals·, each term matchingdigit.
Generic Numeral-to-Number Lexical Mappings
·unsignedNoDecimalMap· (N) → integer
Maps anunsignedNoDecimalPtNumeral to its numerical value.
Arguments:Result:
a nonnegative integer
Algorithm:
N is the left-to-right concatenation of a finite sequenceS of·literals·, each term matchingdigit.
·noDecimalMap· (N) → integer
Maps annoDecimalPtNumeral to its numerical value.
Arguments:Result:
an integer
Algorithm:
N necessarily consists of an optional sign('+' or '-') and thena·literal·U that matchesunsignedNoDecimalPtNumeral.
Return
·unsignedDecimalPtMap· (D) → decimal number
Maps anunsignedDecimalPtNumeral to its numerical value.
Arguments:Result:
a nonnegative decimal number
Algorithm:
D necessarily consists of an optional·literal·N matchingunsignedNoDecimalPtNumeral, a decimal point, and then an optional·literal·F matchingfracFrag.
Return
·decimalPtMap· (N) → decimal number
Maps adecimalPtNumeral to its numerical value.
Arguments:
NmatchesdecimalPtNumeral
Result:
a decimal number
Algorithm:
N necessarily consists of an optional sign('+' or '-') and thenan instanceU ofunsignedDecimalPtNumeral.
Return
·scientificMap· (N) → decimal number
Maps ascientificNotationNumeral to its numerical value.
Arguments:Result:
a decimal number
Algorithm:
N necessarily consists of an instanceC of eithernoDecimalPtNumeral ordecimalPtNumeral, either an 'e' or an 'E', and then an instanceE ofnoDecimalPtNumeral.
Return
Auxiliary Functions for Producing Numeral Fragments
·digit· (i) →digit
Maps each integer between 0 and 9 to the correspondingdigit.
Arguments:
ibetween 0 and 9 inclusive
Result:
matchesdigit
Algorithm:
Return
  • '0'   when i = 0 ,
  • '1'   when i = 1 ,
  • '2'   when i = 2 ,
  • etc.
·digitRemainderSeq· (i) → sequence of integers
Maps each nonnegative integer to a sequence of integers used by·digitSeq· to ultimately create anunsignedNoDecimalPtNumeral.
Arguments:
ia nonnegative integer
Result:
sequence of nonnegative integers
Algorithm:
Return that sequences for which
  • s0 = i  and
  • sj+1 = sj ·div· 10 .
·digitSeq· (i) → sequence of integers
Maps each nonnegative integer to a sequence of integers used by·unsignedNoDecimalPtCanonicalMap· to create anunsignedNoDecimalPtNumeral.
Arguments:
ia nonnegative integer
Result:
sequence of integers where each term is between 0 and 9 inclusive
Algorithm:
Return that sequences for which sj =·digitRemainderSeq·(i)j ·mod· 10 .
·lastSignificantDigit· (s) → integer
Maps a sequence of nonnegative integers to the index of the first zero term.
Arguments:
sa sequence of nonnegative integers
Result:
a nonnegative integer
Algorithm:
Return the smallest nonnegative integerj such thats(i)j+1 is 0.
·FractionDigitRemainderSeq· (f) → sequence of decimal numbers
Maps each nonnegative decimal number less than 1 to a sequence of decimal numbers used by·fractionDigitSeq· to ultimately create anunsignedNoDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
a sequence of nonnegative decimal numbers
Algorithm:
Return that sequences for which
  • s0 = f − 10 , and
  • sj+1 = (sj ·mod· 1) − 10 .
·fractionDigitSeq· (f) → sequence of integers
Maps each nonnegative decimal number less than 1 to a sequence of integers used by·fractionDigitsCanonicalFragmentMap· to ultimately create anunsignedNoDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
a sequence of integer;s where each term is between 0 and 9 inclusive
Algorithm:
Return that sequences for which sj = ·FractionDigitRemainderSeq·(f)j ·div· 1 .
·fractionDigitsCanonicalFragmentMap· (f) →fracFrag
Maps each nonnegative decimal number less than 1 to a·literal· used by·unsignedDecimalPtCanonicalMap· to create anunsignedDecimalPtNumeral.
Arguments:
fnonnegative and less than 1
Result:
matchesfracFrag
Algorithm:
Generic Number to Numeral Canonical Mappings
Arguments:
ia nonnegative integer
Result:Algorithm:
Return·digit·(·digitSeq·(i)·lastSignificantDigit·(·digitRemainderSeq·(i))) &. . . &·digit·(·digitSeq·(i)0) .   (Notethat the concatenation is in reverse order.)
Arguments:
ian integer
Result:Algorithm:
Return
Arguments:
na nonnegative decimal number
Result:Algorithm:Arguments:
na decimal number
Result:Algorithm:
Return
Arguments:
na nonnegative decimal number
Result:Algorithm:
Return ·unsignedDecimalPtCanonicalMap·(n / 10log(n·div· 1) &'E' &·noDecimalPtCanonicalMap·(log(n·div· 1)
Arguments:
na decimal number
Result:Algorithm:
Return

For example:

Lexical Mapping for Non-numerical·Special Values· Used With Numerical Datatypes
Arguments:Result:
one ofpositiveInfinity,negativeInfinity, ornotANumber.
Algorithm:
Return
  • positiveInfinity   whenS is'INF' or '+INF',
  • negativeInfinity   whenS is'-INF', and
  • notANumber   whenS is'NaN'
Canonical Mapping for Non-numerical·Special Values· Used with Numerical Datatypes
Arguments:
cone ofpositiveInfinity,negativeInfinity, andnotANumber
Result:Algorithm:
Return
  • 'INF'   whenc ispositiveInfinity
  • '-INF'   whenc isnegativeInfinity
  • 'NaN'   whenc isnotANumber
Lexical Mapping
Arguments:
LEXmatchesdecimalLexicalRep
Result:
adecimal value
Algorithm:
Letd be adecimal value.
  1. Setd to
  2. Returnd.
Canonical Mapping
Arguments:
dadecimal value
Result:Algorithm:
  1. Ifd is an integer, then return·noDecimalPtCanonicalMap·(d).
  2. Otherwise, return·decimalPtCanonicalMap·(d).
Auxiliary Functionsfor Binary Floating-point Lexical/Canonical Mappings
·floatingPointRound· (nVcWidtheMineMax) → decimal number or·special value·
Rounds a non-zero decimal number to the nearest floating-point value.
Arguments:
nVan initially non-zero decimal number(may beset to zero during calculations)
cWidtha positive integer
eMinan integer
eMaxan integer greater thaneMin
Result:
a decimal number or·special value·(INF or −INF)
Algorithm:
Let
  • s be an integer initially 1,
  • c be a nonnegative integer, and
  • e be an integer.
  1. Sets to −1   when nV < 0 .
  2. So selecte that 2cWidth × 2(e−1) ≤ |nV| < 2cWidth × 2e .
  3. So selectc that (c − 1) × 2e ≤ |nV | <c × 2e   .
    • when eMax < e (overflow)return:
      • positiveInfinity   whens is positive, and
      • negativeInfinity   otherwise.
    • otherwise:
      1. Whene < eMin (underflow):
        • Set e = eMin
        • So selectc that (c − 1) × 2e ≤ |nV | <c × 2e .
      2. SetnV to
        • c × 2e  when |nV | > c × 2e − 2(e−1) ;
        • (c − 1) × 2e  when |nV | < c × 2e − 2(e−1) ;
        • c × 2e or(c − 1) × 2e  according to whetherc is evenor c − 1  is even, otherwise (i.e., |nV | = c × 2e − 2(e−1) ,the midpoint between the two values).
      3. Return 
        • s × nV  whennV < 2cWidth × 2eMax,
        • positiveInfinity   whens is positive, and
        • negativeInfinity   otherwise.
Note: Implementers will find the algorithms of[Clinger, WD (1990)]more efficient in memory than the simple abstract algorithm employed above.
·round· (nk) → decimal number
Maps a decimal number to that value rounded by some power of 10.
Arguments:
na decimal number
ka nonnegative integer
Result:
a decimal number
Algorithm:
Return ((n / 10k + 0.5) ·div·1) × 10k .
·floatApprox· (cej) → decimal number
Maps a decimal number( c × 10e ) to successive approximations.
Arguments:
ca nonnegative integer
ean integer
ja nonnegative integer
Result:
a decimal number
Algorithm:
Return ·round·(cj ) × 10e
Lexical Mapping
·floatLexicalMap· (LEX) →float
Maps afloatRep onto afloat value.
Arguments:
LEXmatchesfloatRep
Result:
afloat value
Algorithm:
LetnV be a decimal number or·special value· (INF or −INF).
Note: This specification permits the substitution of any other rounding algorithmwhich conforms to the requirements of[IEEE 754-2008].
Lexical Mapping
·doubleLexicalMap· (LEX) →double
Maps adoubleRep onto adouble value.
Arguments:
LEXmatchesdoubleRep
Result:
adouble value
Algorithm:
LetnV be a decimal number or·special value· (INF or −INF).
Note: This specification permits the substitution of any other rounding algorithmwhich conforms to the requirements of[IEEE 754-2008].
Canonical Mapping
Arguments:
fafloat value
Result:Algorithm:
Let
  • l be a nonnegative integer
  • s be an integer intially 1,
  • c be a positive integer, and
  • e be an integer.
  • Return·specialRepCanonicalMap·(f )  whenf is one ofpositiveInfinity,negativeInfinity, ornotANumber;
  • return '0.0E0'   whenfispositiveZero;
  • return '-0.0E0'   whenfisnegativeZero;
  • otherwise (f is numeric and non-zero):
    1. Sets to −1   when f < 0 .
    2. Letc be the smallest integer for which there existsan integere for which |f | = c × 10e .
    3. Lete be log10(|f | / c)  (so that |f | = c × 10e ).
    4. Letl be the largest nonnegative integer for which c × 10e =·floatingPointRound·(·floatApprox·(cel ), 24, −149, 104)
    5. Return·scientificCanonicalMap·(s ×·floatApprox·(cel )) .
Canonical Mapping
Arguments:
fadouble value
Result:Algorithm:
Let
  • l be a nonnegative integer
  • s be an integer intially 1,
  • c be a positive integer, and
  • e be an integer.
  • Return·specialRepCanonicalMap·(f )  whenf is one ofpositiveInfinity,negativeInfinity, ornotANumber;
  • return '0.0E0'   whenfispositiveZero;
  • return '-0.0E0'   whenfisnegativeZero;
  • otherwise (f is numeric and non-zero):
    1. Sets to −1   when f < 0 .
    2. Letc be the smallest integer for which there existsan integere for which |f | = c × 10e .
    3. Lete be log10(|f | / c)  (so that |f | = c × 10e ).
    4. Letl be the largest nonnegative integer for which c × 10e =·floatingPointRound·(·floatApprox·(cel ), 53, −1074, 971)
    5. Return·scientificCanonicalMap·(s ×·floatApprox·(cel )) .

previous sub-sectionnext sub-sectionE.2 Duration-related Definitions

The following functions are primarilyused with theduration datatype and itsderivatives.
Auxiliaryduration-relatedFunctions Operating on Representation Fragments
·duYearFragmentMap· (Y) → integer
Maps aduYearFrag to an integer, intended as part of the value of the·months· property of aduration value.
Arguments:
YmatchesduYearFrag
Result:
a nonnegative integer
Algorithm:
Y is necessarily the letter 'Y' followed by a numeralN:
·duMonthFragmentMap· (M) → integer
Maps aduMonthFrag to an integer, intended as part of the value of the·months· property of aduration value.
Arguments:
MmatchesduYearFrag
Result:
a nonnegative integer
Algorithm:
M is necessarily the letter 'M' followed by a numeralN:
·duDayFragmentMap· (D) → integer
Maps aduDayFrag to an integer, intended as part of the value of the·seconds· property of aduration value.
Arguments:
DmatchesduDayFrag
Result:
a nonnegative integer
Algorithm:
D is necessarily the letter 'D' followed by a numeralN:
·duHourFragmentMap· (H) → integer
Maps aduHourFrag to an integer, intended as part of the value of the·seconds· property of aduration value.
Arguments:
HmatchesduHourFrag
Result:
a nonnegative integer
Algorithm:
D is necessarily the letter 'D' followed by a numeralN:
·duMinuteFragmentMap· (M) → integer
Maps aduMinuteFrag to an integer, intended as part of the value of the·seconds· property of aduration value.
Arguments:
MmatchesduMinuteFrag
Result:
a nonnegative integer
Algorithm:
M is necessarily the letter 'M' followed by a numeralN:
·duSecondFragmentMap· (S) → decimal number
Maps aduSecondFrag to a decimal number, intended as part of the value of the·seconds· property of aduration value.
Arguments:
SmatchesduSecondFrag
Result:
a nonnegative decimal number
Algorithm:
S is necessarily 'S' followed by a numeralN:
Return
·duYearMonthFragmentMap· (YM) → integer
Maps aduYearMonthFrag into an integer, intended as part of the·months· property of aduration value.
Arguments:
YMmatchesduYearMonthFrag
Result:
a nonnegative integer
Algorithm:
YM necessarily consists of an instanceY ofduYearFrag and/or an instanceM ofduMonthFrag:
Let
Return  12 × y +m .
·duTimeFragmentMap· (T) → decimal number
Maps aduTimeFrag into a decimal number, intended as part of the·seconds· property of aduration value.
Arguments:
TmatchesduTimeFrag
Result:
a nonnegative decimal number
Algorithm:
T necessarily consists of an instanceH ofduHourFrag, and/or an instanceM ofduMinuteFrag, and/or an instanceS ofduSecondFrag.
Let
Return  3600 × h + 60 × m + s .
·duDayTimeFragmentMap· (DT) → decimal number
Maps aduDayTimeFrag into a decimal number, which is the potential value of the·seconds· property of aduration value.
Arguments:
DTmatchesduDayTimeFrag
Result:
a nonnegative decimal number
Algorithm:
DT necessarily consists of an instanceD ofduDayFrag and/or an instanceT ofduTimeFrag.
Let
Return  86400 × d + t .
Theduration Lexical Mapping
·durationMap· (DUR) →duration
Separates thedurationLexicalRep into the month part and the seconds part, then maps them into the·months· and·seconds· of theduration value.
Arguments:
DURmatchesdurationLexicalRep
Result:
a completeduration value
Algorithm:
DUR consists of possibly a leading '-', followed by 'P' and then an instanceY ofduYearMonthFrag and/or an instanceD ofduDayTimeFrag:
Return aduration whose and whose
TheyearMonthDuration Lexical Mapping
·yearMonthDurationMap· (YM) →yearMonthDuration
Maps the lexical representation into the·months· of ayearMonthDuration value.  (AyearMonthDuration's·seconds· is alwayszero.) ·yearMonthDurationMap· is a restriction of·durationMap·.
Arguments:Result:
a completeyearMonthDuration value
Algorithm:
YM necessarily consists ofan optional leading '-', followed by'P' and then an instanceY ofduYearMonthFrag:
Return ayearMonthDuration whose
ThedayTimeDuration Lexical Mapping
·dayTimeDurationMap· (DT) →dayTimeDuration
Maps the lexical representation into the·seconds· of adayTimeDuration value.  (AdayTimeDuration's·months· is alwayszero.) ·dayTimeDurationMap· is a restriction of·durationMap·.
Arguments:
DTadayTimeDuration value
Result:
a completedayTimeDuration value
Algorithm:
DT necessarilyconsists of possibly a leading '-', followed by'P' and then an instanceD ofduDayTimeFrag:
Return adayTimeDuration whose
Auxiliaryduration-related FunctionsProducing Representation Fragments
·duYearMonthCanonicalFragmentMap· (ym) →duYearMonthFrag
Maps a nonnegative integer, presumably the absolute value of the·months· of aduration value, to aduYearMonthFrag, a fragment of aduration·lexical representation·.
Arguments:
yma nonnegative integer
Result:Algorithm:
Let
Return
·duDayCanonicalFragmentMap· (d) →duDayFrag
Maps a nonnegative integer, presumably the day normalized value from the·seconds· of aduration value, to aduDayFrag, a fragment of aduration·lexical representation·.
Arguments:
da nonnegative integer
Result:Algorithm:
Return
·duHourCanonicalFragmentMap· (h) →duHourFrag
Maps a nonnegative integer, presumably the hour normalized value from the·seconds· of aduration value, to aduHourFrag, a fragment of aduration·lexical representation·.
Arguments:
ha nonnegative integer
Result:Algorithm:
Return
·duMinuteCanonicalFragmentMap· (m) →duMinuteFrag
Maps a nonnegative integer, presumably the minute normalized value from the·seconds· of aduration value, to aduMinuteFrag, a fragment of aduration·lexical representation·.
Arguments:
ma nonnegative integer
Result:Algorithm:
Return
·duSecondCanonicalFragmentMap· (s) →duSecondFrag
Maps a nonnegative decimal number, presumably the second normalized value from the·seconds· of aduration value, to aduSecondFrag, a fragment of aduration·lexical representation·.
Arguments:
sa nonnegative decimal number
Result:Algorithm:
Return
·duTimeCanonicalFragmentMap· (hms) →duTimeFrag
Maps three nonnegative numbers, presumably the hour, minute, and second normalized values from aduration's·seconds·, to aduTimeFrag, a fragment of aduration·lexical representation·.
Arguments:
ha nonnegative integer
ma nonnegative integer
sa nonnegative decimal number
Result:Algorithm:
Return
·duDayTimeCanonicalFragmentMap· (ss) →duDayTimeFrag
Maps a nonnegative decimal number, presumably the absolute value of the·seconds· of aduration value, to aduDayTimeFrag, a fragment of aduration·lexical representation·.
Arguments:
ssa nonnegative decimal number
Result:Algorithm:
Let
Return
Theduration Canonical Mapping
·durationCanonicalMap· (v) →durationLexicalRep
Maps aduration's property values todurationLexicalRep fragments and combines the fragments into a completedurationLexicalRep.
Arguments:
va completeduration value
Result:Algorithm:
Let
  • m bev's·months·,
  • s bev's·seconds·, and
  • sgn be '-' ifm ors is negative andthe empty string ('') otherwise.
Return
TheyearMonthDuration Canonical Mapping
Arguments:
yma completeyearMonthDuration value
Result:Algorithm:
Let
  • m beym's·months· and
  • sgn be '-' ifm is negative andthe empty string ('') otherwise.
Return sgn & 'P' &·duYearMonthCanonicalFragmentMap·(| m |) .
ThedayTimeDuration Canonical Mapping
Arguments:
dta completedayTimeDuration value
Result:Algorithm:
Let
  • s bedt's·months· and
  • sgn be '-' ifs is negative andthe empty string ('') otherwise.
Return sgn & 'P' &·duYearMonthCanonicalFragmentMap·(| s |) .

previous sub-sectionnext sub-sectionE.3 Date/time-related Definitions

        E.3.1Normalization of property values
        E.3.2Auxiliary Functions
        E.3.3Adding durations to dateTimes
        E.3.4Time on timeline
        E.3.5Lexical mappings
        E.3.6Canonical Mappings

E.3.1 Normalization of property values

When adding and subtracting numbers from date/time properties, theimmediate results may not conform to the limits specified. Accordingly, the following procedures are used to"normalize" potential property values tocorresponding values that do conform to the appropriate limits. Normalization is required when dealing with time zone offset changes (as whenconverting to·UTC· from "local" values) and whenaddingduration values to or subtracting them fromdateTime values.
Date/time Datatype Normalizing Procedures
·normalizeMonth· (yrmo)
If month (mo) is out of range, adjust month and year (yr) accordingly;otherwise, make no change.
Arguments:
yran integer
moan integer
Algorithm:
  1. Add  (mo − 1) ·div· 12  toyr.
  2. Setmo to (mo − 1) ·mod· 12 + 1 .
·normalizeDay· (yrmoda)
Ifmonth (mo) is out of range, or day (da) isout of range for the appropriate month, then adjust values accordingly,otherwise make no change.
Arguments:
yran integer
moan integer
daan integer
Algorithm:
  1. Repeat untilda is positive and not greater than·daysInMonth·(yrmo):
    1. Ifda exceeds·daysInMonth·(yrmo) then:
      1. Subtract that limit fromda.
      2. Add 1 tomo.
    2. Ifda is not positive then:
      1. Subtract 1 frommo.
      2. Add the new upper limit from the table toda.
·normalizeMinute· (yrmodahrmi)
Normalizes minute, hour, month, and year values to values that obey the appropriate constraints.
Arguments:
yran integer
moan integer
daan integer
hran integer
mian integer
Algorithm:
  1. Add  mi ·div· 60  tohr.
  2. Setmi to mi ·mod· 60 .
  3. Add hr ·div· 24  toda.
  4. Sethr to hr ·mod· 24 .
  5. ·normalizeDay·(yrmoda).
·normalizeSecond· (yrmodahrmise)
Normalizes second, minute, hour, month, and year values to values that obey the appropriateconstraints.  (This algorithm ignores leap seconds.)
Arguments:
yran integer
moan integer
daan integer
hran integer
mian integer
sea decimal number
Algorithm:
  1. Add se ·div· 60  tomi.
  2. Setse tose ·mod· 60 .
  3. ·normalizeMinute·(yrmodahrmi).

E.3.2 Auxiliary Functions

Date/time Auxiliary Functions
·daysInMonth· (ym) → integer
Returns the number of the last day of the monthfor any combination of year and month.
Arguments:
yan·optional· integer
man integer between 1 and 12
Result:
between 28 and 31 inclusive
Algorithm:
Return:
  • 28   whenm is 2 andy is not evenly divisible by 4,or is evenly divisible by 100 but not by 400, or isabsent,
  • 29   whenm is 2 andy is evenly divisible by 400, or is evenly divisible by 4 but not by 100,
  • 30   whenm is 4, 6, 9, or 11,
  • 31   otherwise (m is 1, 3, 5, 7, 8, 10, or 12)
·newDateTime· (YrMoDaHrMiSeTz) → an instance of thedate/timeSevenPropertyModel
Returns an instance of thedate/timeSevenPropertyModel withproperty values as specified in the arguments. If an argument is omitted, the corresponding property is set toabsent.
Arguments:
Yran·optional·integer
Moan·optional·integer between 1 and 12 inclusive
Daan·optional·integer between 1 and 31 inclusive
Hran·optional·integer between 0 and 24 inclusive
Mian·optional·integer between 0 and 59 inclusive
Sean·optional·decimal number greater than or equal to 0 and less than 60
Tzan·optional·integerbetween −840 and 840 inclusive.
Result:
Algorithm:
Let
  • dt be an instance of thedate/timeSevenPropertyModel
  • yrbeYr whenYr is notabsent, otherwise 1
  • mo beMowhenMo isnotabsent, otherwise 1
  • da beDawhenDa isnotabsent, otherwise 1
  • hr beHrwhenHr isnotabsent, otherwise 0
  • mi beMiwhenMi isnotabsent, otherwise 0
  • se beSewhenSe isnotabsent, otherwise 0
  1. ·normalizeSecond·(yrmodahrmise)
  2. Set the·year· property ofdt toabsentwhenYr isabsent, otherwiseyr.
  3. Set the·month· property ofdt toabsentwhenMo isabsent, otherwisemo.
  4. Set the·day· property ofdt toabsentwhenDa isabsent, otherwiseda.
  5. Set the·hour· property ofdt toabsentwhenHr isabsent, otherwisehr.
  6. Set the·minute· property ofdt toabsentwhenMi isabsent, otherwisemi.
  7. Set the·second· property ofdt toabsentwhenSe isabsent, otherwisese.
  8. Set the·timezoneOffset· property ofdt toTz
  9. Returndt.

E.3.3 Adding durations to dateTimes

Given adateTimeS and adurationD, function·dateTimePlusDuration·specifies how to compute adateTimeE, whereE is the end of the time period with startS anddurationD i.e.E =S +D.  Such computations are used, for example, todetermine whether adateTime is within a specific time period.  This algorithm can also be applied,when applications need the operation,to the addition ofdurations to the datatypesdate,gYearMonth,gYear,gDay andgMonth, each of which can be viewed as denoting a set ofdateTimes. In such cases, the addition is made to the first or startingdateTime in the set. Note that the extension of thisalgorithm to types other thandateTime is notneeded for schema-validity assessment.

Essentially, this calculation adds the·months· and·seconds· properties of theduration value separately to thedateTime value. The·months· valueis added to the startingdateTimevalue first. If the day is out of range for the newmonth value, it ispinnedto be within range. Thus April 31 turns into April 30. Then the·seconds· valueis added. This latter addition cancause the year, month, day, hour, and minute to change.

Leap seconds are ignored by the computation. All calculationsuse 60 seconds per minute.

Thus the addition of either PT1M or PT60S to any dateTime will alwaysproduce the same result. This is a special definition of addition whichis designed to match common practice, and—most importantly—be stableover time.

A definition that attempted to take leap-seconds into account wouldneed to be constantly updated, and could not predict the results offuture implementation's additions. The decision to introduce a leapsecond in·UTC· is the responsibility of the[International Earth Rotation Service (IERS)]. They make periodicannouncements as to when leap seconds are to be added, but this is notknown more than a year in advance. For more information on leapseconds, see[U.S. Naval Observatory Time Service Department].

·dateTimePlusDuration· (dudt) →dateTime
Adds aduration to adateTime value, producing anotherdateTime value.
Arguments:
duadurationvalue
dtadateTimevalue
Result:
adateTimevalue
Algorithm:
Let
  1. Adddu's·months· tomo.
  2. ·normalizeMonth·(yrmo). (I.e., carry anyover- or underflow, adjust month.)
  3. Setdato  min(da·daysInMonth·(yrmo)).(I.e.,pin the value if necessary.)
  4. Adddu's·seconds· tose.
  5. ·normalizeSecond·(yrmodahrmise).(I.e., carry over- or underflow of seconds up to minutes, hours, etc.)
  6. Return·newDateTime·(yr,mo,da,hr,mi,se,tz)

This algorithm may be applied to date/time typesother thandateTime, by

  1. For eachabsent property, supply the minimum legal value for thatproperty (1 for years, months, days, 0 for hours, minutes, seconds).
  2. Call the function.
  3. For each propertyabsent in the initial value,set the corresponding property in the result value toabsent.

Examples:

dateTimedurationresult
2000-01-12T12:13:14ZP1Y3M5DT7H10M3.3S2001-04-17T19:23:17.3Z
2000-01-P3M1999-10
2000-01-12PT33H2000-01-13
Note that the addition defined by·dateTimePlusDuration· differs from addition onintegers or real numbers in not being commutative.The order of addition of durations to instantsis significant.For example, there are cases where:

((dateTime + duration1) + duration2) != ((dateTime +duration2) + duration1)

Example:

  • (2000-03-30 + P1D) + P1M = 2000-03-31 + P1M = 2000-04-30
  • (2000-03-30 + P1M) + P1D = 2000-04-30 + P1D = 2000-05-01

E.3.4 Time on timeline

Time on Timeline for Date/time Seven-propertyModel Datatypes
·timeOnTimeline· (dt) → decimal number
Maps adate/timeSevenPropertyModel value to the decimal numberrepresenting its position on the "time line".
Arguments:Result:
a decimal number
Algorithm:
Let
  1. Subtract·timezoneOffset· frommi  when·timezoneOffset· is notabsent.
  2. (·year·)
    1. SetToTl to 31536000 × yr .
  3. (Leap-year Days,·month·, and·day·)
    1. Add  86400 ×(yr ·div· 400 −yr ·div· 100 +yr ·div· 4)  toToTl.
    2. Add   86400 × Summ < mo ·daysInMonth·(yr + 1, m) toToTl
    3. Add   86400 × da  toToTl.
  4. (·hour·,·minute·,and·second·)
    1. Add  3600 × hr +60 × mi +se toToTl.
  5. ReturnToTl.

E.3.5 Lexical mappings

Partial Date/time Lexical Mappings
·yearFragValue· (YR) → integer
Maps ayearFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·year· property of adate/timeSevenPropertyModel value.
Arguments:
YRmatchesyearFrag
Result:
an integer
Algorithm:
·monthFragValue· (MO) → integer
Maps amonthFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·month· property of adate/timeSevenPropertyModel value.
Arguments:
MOmatchesmonthFrag
Result:
an integer
Algorithm:
·dayFragValue· (DA) → integer
Maps adayFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·day· property of adate/timeSevenPropertyModel value.
Arguments:
DAmatchesdayFrag
Result:
an integer
Algorithm:
·hourFragValue· (HR) → integer
Maps ahourFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·hour· property of adate/timeSevenPropertyModel value.
Arguments:
HRmatcheshourFrag
Result:
an integer
Algorithm:
·minuteFragValue· (MI) → integer
Maps aminuteFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto an integer, presumably the·minute· property of adate/timeSevenPropertyModel value.
Arguments:
MImatchesminuteFrag
Result:
an integer
Algorithm:
·secondFragValue· (SE) → decimal number
Maps asecondFrag, part of adate/timeSevenPropertyModel's·lexical representation·,onto a decimal number, presumably the·second· property of adate/timeSevenPropertyModel value.
Arguments:
SEmatchessecondFrag
Result:
a decimal number
Algorithm:
Return
·timezoneFragValue· (TZ) → integer
Arguments:
TZmatchestimezoneFrag
Result:
an integer
Algorithm:
TZ necessarily consists of either just 'Z', or a sign ('+' or '-') followed by an instanceH ofhourFrag, a colon, and an instanceM ofminuteFrag
Return
Note: There is no·lexical mapping· forendOfDayFrag; it is handled specially by the relevant·lexical mappings·.  See, e.g.,·dateTimeLexicalMap·.
Lexical Mapping
Arguments:
LEXmatchesdateTimeLexicalRep
Result:
a completedateTime value
Algorithm:
LEX necessarily includessubstringsthat are instances ofyearFrag,monthFrag, anddayFrag(below referred to asY,MO, andD respectively);italso contains either instances ofhourFrag,minuteFrag,andsecondFrag(Y,MI, andS),orelse an instance ofendOfDayFrag; finally,it may optionally contain an instanceoftimezoneFrag(T).
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
Lexical Mapping
·timeLexicalMap· (LEX) →time
Maps atimeLexicalRep toatime value.
Arguments:
LEXmatchestimeLexicalRep
Result:
a completetime value
Algorithm:
LEX necessarily includeseithersubstrings that are instances ofhourFrag,minuteFrag,andsecondFrag, (below referred to asH,M, andS respectively), orelse an instance ofendOfDayFrag; finally, it may optionally containan instance oftimezoneFrag(T).
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent
Return
Lexical Mapping
·dateLexicalMap· (LEX) →date
Maps adateLexicalRep to adate value.
Arguments:
LEXmatchesdateLexicalRep
Result:
a completedate value
Algorithm:
LEX necessarily includesan instanceY ofyearFrag, an instanceM ofmonthFrag,and an instanceD ofdayFrag,hyphen-separated and optionally followed by an instanceT oftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent
Return·newDateTime·(·yearFragValue·(Y),·monthFragValue·(M),·dayFragValue·(D),absent,absent,absent,tz.)
Lexical Mapping
Arguments:Result:
a completegYearMonth value
Algorithm:
LEX necessarily includesan instanceY ofyearFrag and an instanceM ofmonthFrag,hyphen-separated and optionally followed by an instanceT oftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
Return·newDateTime·(·yearFragValue·(Y),·monthFragValue·(M),absent,absent,absent,absent,tz).
Lexical Mapping
Arguments:
LEXmatchesgYearLexicalRep
Result:
a completegYear value
Algorithm:
LEX necessarily includesan instanceY ofyearFrag, optionally followed by an instanceToftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
Return·newDateTime·(·yearFragValue·(Y),absent,absent,absent,absent,absent,tz).
Lexical Mapping
Arguments:
LEXmatchesgMonthDayLexicalRep
Result:
a completegMonthDay value
Algorithm:
LEX necessarily includesan instanceM ofmonthFrag and an instanceD ofdayFrag,hyphen-separated and optionally followed by an instanceT oftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
Return·newDateTime·(absent,·monthFragValue·(M),·dayFragValue·(D),absent,absent,absent,tz.
Lexical Mapping
·gDayLexicalMap· (LEX) →gDay
Maps agDayLexicalRep toagDay value.
Arguments:
LEXmatchesgDayLexicalRep
Result:
a completegDay value
Algorithm:
LEX necessarily includesan instanceD ofdayFrag, optionally followed by an instanceToftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
  1. Return·newDateTime·(gD,absent,absent,·dayFragValue·(D),absent,absent,absent,tz).
Return·newDateTime·(absent,absent,·dayFragValue·(D),absent,absent,absent,tz).
Lexical Mapping
Arguments:
LEXmatchesgMonthLexicalRep
Result:
a completegMonth value
Algorithm:
LEX necessarily includesan instanceM ofmonthFrag, optionally followed by an instanceToftimezoneFrag.
Lettzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent.
Return·newDateTime·(absent,·monthFragValue·(M),absent,absent,absent,absent,tz)

E.3.6 Canonical Mappings

Auxiliary Functions for Date/time Canonical Mappings
·unsTwoDigitCanonicalFragmentMap· (i) →unsignedNoDecimalPtNumeral
Maps a nonnegative integer less than 100 onto an unsigned always-two-digit numeral.
Arguments:
ia nonnegative integer less than 100
Result:Algorithm:
Return·digit·(i ·div· 10) &·digit·(i ·mod· 10)
·fourDigitCanonicalFragmentMap· (i) →noDecimalPtNumeral
Maps an integer between -10000 and 10000 onto an always-four-digit numeral.
Arguments:
ian integer whose absolute value is less than 10000
Result:Algorithm:
Partial Date/time Canonical Mappings
Arguments:
yan integer
Result:
matchesyearFrag
Algorithm:
Return
Arguments:
man integer between 1 and 12 inclusive
Result:
matchesmonthFrag
Algorithm:Arguments:
dan integer between 1 and 31 inclusive (may be limited further depending on associated·year· and·month·)
Result:
matchesdayFrag
Algorithm:Arguments:
han integer between 0 and 23 inclusive.
Result:
matcheshourFrag
Algorithm:Arguments:
man integer between 0 and 59 inclusive.
Result:
matchesminuteFrag
Algorithm:Arguments:
sa nonnegative decimal number less than 70
Result:
matchessecondFrag
Algorithm:Arguments:
tan integer between −840 and 840 inclusive
Result:Algorithm:
Return
Canonical Mapping
Arguments:
dta completedateTime value
Result:Algorithm:
Return
Canonical Mapping
Arguments:
tia completetime value
Result:Algorithm:
Return
Canonical Mapping
Arguments:
daa completedate value
Result:Algorithm:
Return
Canonical Mapping
Arguments:
yma completegYearMonth value
Result:Algorithm:
Return
Canonical Mapping
Arguments:
gYa completegYear value
Result:Algorithm:
Canonical Mapping
Arguments:
mda completegMonthDay value
Result:Algorithm:
Return
Canonical Mapping
Arguments:
gDa completegDay value
Result:Algorithm:
Canonical Mapping
Arguments:
gMa completegMonth value
Result:Algorithm:

previous sub-sectionE.4 Lexical and Canonical Mappings for Other Datatypes

The following functions are used with various datatypes neither numericnor date/time related.

Lexical Mapping
·stringLexicalMap· (LEX) →string
Maps a·literal· matching thestringRep production toastring value.
Arguments:
LEXa·literal· matchingstringRep
Result:
Astring value
Algorithm:
ReturnLEX.  (The function is the identityfunction on the domain.)
Lexical Mapping
·booleanLexicalMap· (LEX) →boolean
Maps a·literal· matching thebooleanRep production toaboolean value.
Arguments:
LEXa·literal· matchingbooleanRep
Result:
Aboolean value
Algorithm:
Return
  • true   whenLEX is 'true'or '1' , and
  • false   otherwise (LEX is 'false'or '0').
Canonical Mapping
Arguments:
sastring value
Result:
matchesstringRep
Algorithm:
Returns.  (The function is the identityfunction on the domain.)
Canonical Mapping
Arguments:
baboolean value
Result:
matchesbooleanRep
Algorithm:
Return
  • 'true'   whenb istrue, and
  • 'false'   otherwise (b isfalse).

E.4.1 Lexical and canonical mappings forhexBinary

The·lexical mapping· forhexBinarymaps each pair of hexadecimal digits to an octet, in the conventional way:

Lexical Mapping for hexBinary
·hexBinaryMap· (LEX) →hexBinary
Maps a·literal· matching thehexBinary production toa sequence of octets in the form of ahexBinary value.
Arguments:
LEXa·literal· matchinghexBinary
Result:
A sequence of binary octets in the form of ahexBinary value
Algorithm:
LEX necessarily includes a sequence of zero or moresubstrings matching thehexOctet production.
Leto be the sequence of octets formed by applying·hexOctetMap· to eachhexOctet inLEX, in order, and concatenating the results.
Returno.

The auxiliary functions·hexOctetMap· and·hexDigitMap· are used by·hexBinaryMap·.

Mappings for hexadecimal digits
·hexOctetMap· (LEX) → octet
Maps a·literal· matching thehexOctet production toa single octet.
Arguments:
LEXa·literal· matchinghexOctet
Result:
A single binary octet
Algorithm:
LEX necessarily includes exactly two hexadecimal digits.
Letd0 be the first hexadecimal digit inLEX.Letd1 be the second hexadecimal digit inLEX.
Return the octet whose four high-order bits are·hexDigitMap·(d0) and whose four low-order bitsare·hexDigitMap·(d1).
·hexDigitMap· (d) → a bit-sequence of length four
Maps a hexadecimal digit (a character matchingthehexDigit production) toa sequence of four binary digits.
Arguments:
da hexadecimal digit
Result:
a sequence of four binary digits
Algorithm:
Return
  • 0000 whend = '0',
  • 0001 whend = '1',
  • 0010 whend = '2',
  • 0011 whend = '3',
  • ...
  • 1110 whend = 'E' or 'e',
  • 1111 whend = 'F' or 'f'.

The·canonical mapping· forhexBinary uses only theuppercase forms of A-F.

Canonical Mapping for hexBinary
·hexBinaryCanonical· (o) →hexBinary
Maps ahexBinary value to a literalmatching thehexBinary production.
Arguments:
oahexBinary value
Result:
matcheshexBinary
Algorithm:
Leth be the sequence of literals formed by applying·hexOctetCanonical· to each octet ino, in order, and concatenating the results.
Returnh.
Auxiliary procedures for canonical mapping ofhexBinary
·hexOctetCanonical· (o) →hexOctet
Maps a binary octet to a literalmatching thehexOctet production.
Arguments:
oa binary octet
Result:
matcheshexOctet
Algorithm:
Letlo be the four low-order bits ofo,andhi be the four high-order bits.
·hexDigitCanonical· (d) →hexDigit
Maps a four-bit sequence to a hexadecimaldigit (a literalmatching thehexDigit production).
Arguments:
da sequence of four binary digits
Result:
matcheshexDigit
Algorithm:
Return
  • '0' whend = 0000,
  • '1' whend = 0001,
  • '2' whend = 0010,
  • '3' whend = 0011,
  • ...
  • 'E' whend = 1110,
  • 'F' whend = 1111.

F Datatypes and Facets

F.1 Fundamental Facets

The following table shows the values of the fundamental facetsfor each·built-in· datatype.

 Datatypeorderedboundedcardinalitynumeric
primitivestringfalsefalsecountably infinitefalse
booleanfalsefalsefinitefalse
floatpartialtruefinitetrue
doublepartialtruefinitetrue
decimaltotalfalsecountably infinitetrue
durationpartialfalsecountably infinitefalse
dateTimepartialfalsecountably infinitefalse
timepartialfalsecountably infinitefalse
datepartialfalsecountably infinitefalse
gYearMonthpartialfalsecountably infinitefalse
gYearpartialfalsecountably infinitefalse
gMonthDaypartialfalsecountably infinitefalse
gDaypartialfalsecountably infinitefalse
gMonthpartialfalsecountably infinitefalse
hexBinaryfalsefalsecountably infinitefalse
base64Binaryfalsefalsecountably infinitefalse
anyURIfalsefalsecountably infinitefalse
QNamefalsefalsecountably infinitefalse
NOTATIONfalsefalsecountably infinitefalse
non-primitivenormalizedStringfalsefalsecountably infinitefalse
tokenfalsefalsecountably infinitefalse
languagefalsefalsecountably infinitefalse
IDREFSfalsefalsecountably infinitefalse
ENTITIESfalsefalsecountably infinitefalse
NMTOKENfalsefalsecountably infinitefalse
NMTOKENSfalsefalsecountably infinitefalse
Namefalsefalsecountably infinitefalse
NCNamefalsefalsecountably infinitefalse
IDfalsefalsecountably infinitefalse
IDREFfalsefalsecountably infinitefalse
ENTITYfalsefalsecountably infinitefalse
integertotalfalsecountably infinitetrue
nonPositiveIntegertotalfalsecountably infinitetrue
negativeIntegertotalfalsecountably infinitetrue
longtotaltruefinitetrue
inttotaltruefinitetrue
shorttotaltruefinitetrue
bytetotaltruefinitetrue
nonNegativeIntegertotalfalsecountably infinitetrue
unsignedLongtotaltruefinitetrue
unsignedInttotaltruefinitetrue
unsignedShorttotaltruefinitetrue
unsignedBytetotaltruefinitetrue
positiveIntegertotalfalsecountably infinitetrue
yearMonthDurationpartialfalsecountably infinitefalse
dayTimeDurationpartialfalsecountably infinitefalse
dateTimeStamppartialfalsecountably infinitefalse

G Regular Expressions

A·regular expression· R is a sequence ofcharacters that denote asetof stringsL(R). When used to constrain a·lexical space·, aregularexpressionR asserts that only strings inL(R)are valid·literals· for values of that type.

Note: Unlike some popular regular expression languages (including those defined by Perl and standard Unix utilities), the regular expression language defined here implicitly anchors all regular expressions at the head and tail, as the most common use of regular expressions in·pattern· is to match entire·literals·.For example, a datatype·derived· fromstring suchthat all values must begin with the character'A'(#x41) and end with the character'Z'(#x5a) would be defined as follows:
<simpleType name='myString'> <restriction base='string'>  <pattern value='A.*Z'/> </restriction></simpleType>
In regular expression languages that are not implicitly anchored at the head and tail,it is customary to write the equivalent regular expression as:

^A.*Z$

where'^'anchors the pattern at the head and'$'anchors at the tail.
In those rare cases where an unanchored match is desired, including'.*'at the beginning and ending of the regular expression willachieve the desired results.  For example, a datatype·derived· from stringsuch that all values must contain at least 3 consecutive'A'(#x41)characters somewhere within the value could be defined as follows:
<simpleType name='myString'> <restriction base='string'>  <pattern value='.*AAA.*'/> </restriction></simpleType>

next sub-sectionG.1 Regular expressions and branches

[Definition:]  Aregular expression is composed from zero or more·branches·,separated by'|'characters.

[64]   regExp   ::=   branch( '|'branch )*

For all·branches·S, and for all·regularexpressions·T, valid·regularexpressions·R are:Denoting the set of stringsL(R)containing:
(empty string)just the empty string
Sall strings inL(S)
S |Tall strings inL(S)and all strings inL(T)

[Definition:]  Abranch consists of zero or more·pieces·,concatenated together.

[65]   branch   ::=   piece*

For all·pieces·S, and for all·branches·T, valid·branches·R are:Denoting the set of stringsL(R)containing:
Sall strings inL(S)
STall stringsstwiths inL(S)andtinL(T)

previous sub-sectionnext sub-sectionG.2 Pieces, atoms, quantifiers

[Definition:]  Apiece is an·atom·, possibly followed by a·quantifier·.

[66]   piece   ::=   atom quantifier?

For all·atoms·S and non-negativeintegersn,msuch thatnm, valid·pieces·R are:Denoting the set of stringsL(R)containing:
Sall strings inL(S)
S ?the empty string, and all strings inL(S)
S *all strings inL(S ?)and all stringsstwiths inL(S *)andtinL(S)  (all concatenations of zero or more strings fromL(S) )
S +all stringsstwiths inL(S)andtinL(S *)  (all concatenations of one or more strings fromL(S) )
S {n,m}all stringsstwiths inL(S)andtinL(S {n−1,m−1})(allconcatenationsof at leastn,and at mostm,strings fromL(S) )
S {n}allstrings inL(S{n,n}(allconcatenationsof exactlynstrings fromL(S) )
S {n,}allstrings inL(S{n} S *(allconcatenationsof at leastnstrings fromL(S) )
S {0,m}all stringsstwiths inL(S ?)andtinL(S {0,m−1}). (allconcatenationsof at mostmstrings fromL(S) )
S {0,0}only the empty string
Note: The regular expression language in the Perl Programming Language[Perl] does not include a quantifier of the form S {,m} ,since it is logically equivalent toS {0,m} . We have, therefore, left this logical possibility out of the regularexpression language defined by this specification.

[Definition:]  Aquantifier is one of'?','*', or '+', or a string of the form {n,m} or {n,} , which have the meaningsdefined in the table above.

[67]   quantifier   ::=   [?*+] | ( '{'quantity '}' )
[68]   quantity   ::=   quantRange |quantMin |QuantExact
[69]   quantRange   ::=   QuantExact ','QuantExact
[70]   quantMin   ::=   QuantExact ','
[71]   QuantExact   ::=   [0-9]+

[Definition:]  Anatom is either a·normal character·, a·character class·, ora parenthesized·regular expression·.

[72]   atom   ::=   NormalChar |charClass | ( '('regExp ')' )

For all·normalcharacters·c,·characterclasses·C, and·regularexpressions·S, valid·atoms·R are:Denoting the set of stringsL(R)containing:
cthe single string consisting only ofc
Call strings inL(C)
( S )L(S)

previous sub-sectionnext sub-sectionG.3 Characters and metacharacters

[Definition:]  Ametacharacter is either'.','\', '?', '*','+', '{', '}','(', ')','|','[',or ']'. These characters have special meanings in·regularexpressions·, but can be escaped to form·atoms·that denote the sets of strings containing only themselves, i.e., an escapedmetacharacterbehaves like a·normal character·.

[Definition:]  Anormal character is any XML character that is not a·metacharacter·. In·regularexpressions·, anormalcharacter is an·atom·that denotes the singleton set of strings containing only itself.

[73]   NormalChar   ::=   [^.\?*+{}()|#x5B#x5D]/*  N.B.:  #x5B = '[',#x5D = ']'  */

previous sub-sectionG.4 Character Classes

        G.4.1Character class expressions
        G.4.2Character Class Escapes
            G.4.2.1Single-character escapes
            G.4.2.2Category escapes
            G.4.2.3Block escapes
            G.4.2.4Unrecognized category escapes
            G.4.2.5Multi-character escapes

[Definition:]  Acharacter class is an·atom·R that identifies asetof charactersC(R). The set of stringsL(R). denoted by a character classR contains one single-characterstring "c" for each characterc inC(R).

[74]   charClass   ::=   SingleCharEsc |charClassEsc |charClassExpr |WildcardEsc

A character class is either a·single-character escape· ora·character class escape· or a·character class expression· ora·wildcard character·.

Note: The rules for which characters must be escaped and whichcan represent themselves are different when inside a·character class expression·; some·normal characters·must be escaped and some·metacharacters· neednot be.

G.4.1 Character class expressions

[Definition:]  Acharacter class expression(charClassExpr)is a·character group· surrounded by'['and']'characters.  For all character groupsG[ G ] is a validcharacter classexpression, identifying the set of charactersC([G]) =C(G).

[75]   charClassExpr   ::=   '['charGroup ']'

[Definition:]  Acharacter group (charGroup) starts with either a·positive character group· ora·negative character group·,and is optionally followed by a subtraction operator '-'and a further·character class expression·. [Definition:]  A·character group· that contains a subtraction operatoris referred to as acharacter class subtraction.

[76]   charGroup   ::=   (posCharGroup |negCharGroup ) ( '-'charClassExpr )?

If the first character in acharGroup is '^', this is taken as indicating that thecharGroupstarts with anegCharGroup. AposCharGroup can itself start with '^' but only when it appears within anegCharGroup, that is, when the '^' is preceded by another '^'.

Note: For example, the string'[^X]'is ambiguous according the grammar rules, denoting eithera character class consisting of a negative character groupwith'X'as a member, or a positive character class with'X'and'^'as members.  Thenormative prose rule just given requires that thefirst interpretation be taken.
The string '[^]'is unambiguous: the grammar recognizes it as a character class expression containinga positivecharacter group containing justthe character'^'. But the grammatical derivation of the string violatesthe rule just given, so the string'[^]'must not be accepted as a regular expression.

A '-' characteris recognized as a subtraction operator (and hence, as terminating theposCharGroup ornegCharGroup) if it is immediately followed by a '[' character.

For any·positive character group·or·negative character group·G, and any·character class expression·CG - C  is a valid·character group·, identifying the set of all characters inC(G)that are not inC(C).

[Definition:]  Apositive character group consists of one or more·character group parts·, concatenatedtogether. Theset of characters identified by apositive character group isthe union of all of the sets identifiedby its constituent·character group parts·.

[77]   posCharGroup   ::=   (charGroupPart)+

For all·characterranges·R, all·character classescapes·E,and all·positive character groups·P, valid·positivecharater groups·G are:Identifying the set of charactersC(G)containing:
Rall characters inC(R)
Eall characters inC(E)
RPall characters inC(R)and all characters inC(P)
EPall characters inC(E)and all characters inC(P)

[Definition:]  Anegative character group (negCharGroup)consists of a '^'characterfollowed by a·positive character group·.The set of characters identified bya negative character groupC(^P)isthe set of all characters that arenot inC(P).

[78]   negCharGroup   ::=   '^'posCharGroup

[Definition:]  Acharacter group part (charGroupPart) is anyof: a single unescaped character(SingleCharNoEsc),a single escaped character(SingleCharEsc), a character class escape(charClassEsc),or a character range(charRange).

[79]   charGroupPart   ::=   singleChar |charRange |charClassEsc
[80]   singleChar   ::=   SingleCharEsc |SingleCharNoEsc
If acharGroupPart starts with asingleChar and this is immediately followed by a hyphen,thenthe following rules apply.
  1. If the hyphen is immediately followed by '[',then the hyphen is not part of thecharGroupPart:instead, it is recognized as a character-class subtraction operator.
  2. If the hyphen is immediately followed by ']',then the hyphen is recognized as asingleChar andis part of thecharGroupPart.
  3. If the hyphen is immediately followed by '-[',then the hyphen is recognized as asingleChar andis part of thecharGroupPart.
  4. Otherwise, the hyphenmust be immediately followed by somesingleChar other than a hyphen. In this casethe hyphen is not part of thecharGroupPart;instead it is recognized, together with the immediatelypreceding and following instances ofsingleChar,as acharRange.
  5. If the hyphen is followed by any other character sequence, then the string in which it occurs is not recognized as a regular expression.
It is an error if either of the twosingleChars in acharRange is aSingleCharNoEsc comprising an unescaped hyphen.
Note: The rule just given resolves what would otherwise be the ambiguous interpretationof some strings, e.g.'[a-k-z]';it also constrains regular expressions in waysnot expressed in the grammar. For example, therule (not the grammar) excludes the string'[--z]'from theregular expression language defined here.

[Definition:]  Acharacter range R identifies a set ofcharactersC(R) with UCS code points in a specified range.

[81]   charRange   ::=   singleChar '-'singleChar

A·character range· in the form s-e  identifiesthe setof characterswith UCS code points greater than or equal to the code pointofs, but not greater than the code point ofe.

[82]   SingleCharNoEsc   ::=   [^\#x5B#x5D]/*  N.B.: #x5B = '[',#x5D = ']'  */

A single unescaped character(SingleCharNoEsc) is any characterexcept '[' or ']'.There are special rules, described earlier, thatconstrainthe use of the characters '-' and'^' in order to disambiguate the syntax.

A single unescaped characteridentifies the singleton set of characters containingthat character alone.

A single escaped character(SingleCharEsc), when used within acharacter group, identifies the singleton set of characterscontaining the character denoted by theescape (seeCharacter Class Escapes (§G.4.2)).

G.4.2 Character Class Escapes

[Definition:]  Acharacter class escape is a short sequence of charactersthat identifies a predefinedcharacter class.  The valid character class escapes are the·multi-character escapes·, and the·category escapes· (including the·block escapes·).

[83]   charClassEsc   ::=   (MultiCharEsc |catEsc |complEsc)
G.4.2.1 Single-character escapes

Closely related to thecharacter-class escapes are the single-character escapes.[Definition:]  Asingle-character escape identifies a set containingonly onecharacter—usuallybecause that character is difficult orimpossible to write directly into a·regular expression·.

[84]   SingleCharEsc   ::=   '\' [nrt\|.?*+(){}#x2D#x5B#x5D#x5E]/* N.B.:  #x2D = '-', #x5B = '[', #x5D = ']', #x5E = '^' */

The valid·singlecharacter escapes·R are:Identifying the set of characterscontaining:
\nthe newline character (#xA)
\rthe return character (#xD)
\tthe tab character (#x9)
\\\
\||
\..
\--
\^^
\??
\**
\++
\{{
\}}
\((
\))
\[[
\]]
G.4.2.2 Category escapes

[Definition:]  [Unicode Database] specifies a number of possible values forthe "General Category" property and provides mappingsfrom code points to specific character properties. The set containing all characters that have propertyXcan be identified with acategory escape \p{X} (using a lower-case'p'). The complement of this set is specified with thecategoryescape \P{X}(using an upper-case 'P'). For allX, ifX is a recognizedcharacter-property code, then[\P{X}]=[^\p{X}].

[85]   catEsc   ::=   '\p{'charProp '}'
[86]   complEsc   ::=   '\P{'charProp '}'
[87]   charProp   ::=   IsCategory |IsBlock

[Unicode Database] is subject to future revision.  Forexample, the mapping from code points to character properties might beupdated. All·minimally conforming· processorsmust support the character properties defined inthe version of[Unicode Database] cited in thenormative references (Normative (§K.1)) or insome later version of the Unicode database.  Implementors are encouraged to support thecharacter properties defined in any later versions. When theimplementation supports multiple versions of the Unicode database, andthey differ in salient respects (e.g. different properties areassigned to the same character in different versions of the database),then it is·implementation-defined· which set of property definitions is usedfor any given assessment episode.

Note: In order to benefit from continuing work on the Unicode database,a conforming implementation might by default use the latest supportedversion of the character properties. In order to maximize consistencywith other implementations of this specification, however, an implementation might choose to provide·user options· to specify theuse of the version of the database cited in the normative references.ThePropertyAliases.txtandPropertyValueAliases.txt files ofthe Unicode database may be helpful to implementors in this connection.

For convenience, the following table lists the values of the "General Category" property in the versionof[Unicode Database]cited in the normative references(Normative (§K.1)). The properties with single-character names are not defined in[Unicode Database].  The value of a single-characterproperty is the union of the values of all the two-character propertieswhose first character is the character in question.  For example,forN, the union ofNd,Nl andNo.

Note: As of this publication the Java regexlibrary doesnot includeCn in its definition ofC, so that definition cannot be used without modificationin conformant implementations.
CategoryPropertyMeaning
LettersLAll Letters
Luuppercase
Lllowercase
Lttitlecase
Lmmodifier
Loother
 
MarksMAll Marks
Mnnonspacing
Mcspacing combining
Meenclosing
 
NumbersNAll Numbers
Nddecimal digit
Nlletter
Noother
 
PunctuationPAll Punctuation
Pcconnector
Pddash
Psopen
Peclose
Piinitial quote(may behave like Ps or Pe depending on usage)
Pffinal quote(may behave like Ps or Pe depending on usage)
Poother
 
SeparatorsZAll Separators
Zsspace
Zlline
Zpparagraph
 
SymbolsSAll Symbols
Smmath
Sccurrency
Skmodifier
Soother
 
OtherCAll Others
Cccontrol
Cfformat
Coprivate use
Cnnot assigned
[88]   IsCategory   ::=   Letters |Marks |Numbers |Punctuation |Separators |Symbols |Others
[89]   Letters   ::=   'L' [ultmo]?
[90]   Marks   ::=   'M' [nce]?
[91]   Numbers   ::=   'N' [dlo]?
[92]   Punctuation   ::=   'P' [cdseifo]?
[93]   Separators   ::=   'Z' [slp]?
[94]   Symbols   ::=   'S' [mcko]?
[95]   Others   ::=   'C' [cfon]?
Note: The properties mentioned above exclude the Cs property.  The Cs property identifies"surrogate" characters, which do not occur at thelevel of the "character abstraction" that XMLinstance documents operate on.
G.4.2.3 Block escapes

[Unicode Database] groups the code points of the UniversalCharacter Set (UCS) into a number of blocks such as Basic Latin (i.e.,ASCII), Latin-1 Supplement, Hangul Jamo, CJK Compatibility, etc. The block-escape construct allows regular expressions to refer to setsof characters by the name of the block in which they appear, using a·normalized block name·.

[Definition:]  For any Unicode block, thenormalized block name of thatblock is the string of characters formed by stripping out white spaceand underbar characters from the block name as given in[Unicode Database], while retaining hyphens and preserving casedistinctions.

[Definition:]  Ablock escape expression denotes the set of charactersin a given Unicode block. For any Unicode blockB, with·normalized block name·X, the set containing allcharacters defined in blockB can be identified with theblockescape\p{IsX} (using lower-case'p'). The complement of this set is denoted by theblock escape\P{IsX} (using upper-case'P'). For allX, ifX is a normalized block namerecognized by the processor, then[\P{IsX}] =[^\p{IsX}].

[96]   IsBlock   ::=   'Is' [a-zA-Z0-9#x2D]+/*  N.B.: #x2D = '-' */

·block escape·\p{IsBasicLatin}

Note: Current versions of the Unicode database recommend that whenever block names are being matched hyphens, underbars, and white space should be dropped and letters folded to a single case, so both the string 'BasicLatin' and the string '-- basic LATIN --' will match the block name "Basic Latin".
The handling of block names in block escapes differs from this behavior in two ways. First, the normalized block names defined in this specification do not suppress hyphens in the Unicode block names and do not level case distinctions. The normalized form of the block name 'Latin-1 Supplement', for example, is thus 'Latin-1Supplement', not 'latin1supplement' or 'LATIN1SUPPLEMENT'. Second, XSD processors are not required to perform any normalization at all upon the block name as given in the·block escape·, so '\p{Latin-1Supplement}' will be recognized as a reference to the Latin-1 Supplement block, but '\p{Is Latin-1 supplement}' will not.

[Unicode Database] has been revised since XSD 1.0 waspublished, and is subject to future revision. In particular, thegrouping of code points into blocks has changed, and may changeagain. All·minimally conforming· processorsmustsupport the blocks defined in the version of[Unicode Database]cited in the normative references (Normative (§K.1)) or in somelater version of the Unicode database. Implementorsare encouraged to support the blocks defined in earlier and/or laterversions of the Unicode Standard. When the implementation supportsmultiple versions of the Unicode database, and they differ in salientrespects (e.g. different characters are assigned to a given block indifferent versions of the database), then it is·implementation-defined· whichset of block definitions is used for any given assessment episode.

In particular, the version of[Unicode Database] referenced in XSD 1.0 (namely, Unicode 3.1)contained a number ofblocks which have been renamed in later versions of thedatabase Since theolder block names may appear in regular expressions withinXSD 1.0 schemas, implementors are encouraged to support the supersededblock names in XSD 1.1 processors for compatibility, either by defaultor·at user option·. At the time thisdocument was prepared, block names from Unicode 3.1 known to have beensuperseded in this way included:
  • #x0370 - #x03FF: Greek
  • #x20D0 - #x20FF: CombiningMarksforSymbols
  • #xE000 - #xF8FF: PrivateUse
  • #xF0000 - #xFFFFD: PrivateUse
  • #x100000 - #x10FFFD: PrivateUse

A tabulation of normalized block names for Unicode 2.0.0 andlater is given in[Unicode block names].

For the treatment of regular expressionscontaining unrecognized Unicode block names, seeUnrecognized category escapes (§G.4.2.4).

G.4.2.4 Unrecognized category escapes

A string of the form "\p{S}" constitutes acatEsc (category escape), and similarly a string of the form "\P{S}" constitutes acomplEsc (category-complement escape) only if the stringS matches eitherIsCategory orIsBlock.

Note: If an unknown string of characters is used in a category escape instead of a known character category code or a string matching theIsBlock production, the resulting string will (normally) not match theregExp production and thus not be a regular expression as defined in this specification. If the non-regExp string occurs where a regular expression is required, the schema document will be in·error·.

Any string of hyphens, digits, and Basic Latin characters beginning with 'Is' will match the non-terminalIsBlock and thus be allowed in a regular expression. Most of these strings, however, will not denote any Unicode block. Processorsshould issue a warning if they encounter a regular expression using a block name they do not recognize. Processorsmay·at user option· treat unrecognized block names as·errors· in the schema.

Note: Treating unrecognized block names as errors increases the likelihood that errors in spelling the block name will be detected and can be helpful in checking the correctness of schema documents. However, it also decreases the portability of schema documents among processors supporting different versions of[Unicode Database]; it is for this reason that processors are allowed to treat unrecognized block names as errors only when the user has explicitly requested this behavior.

If a string "IsX" matches the non-terminalIsBlock butX is not a recognized block name, then the expressions "\p{IsX}" and "\P{IsX}" each denote the set of all characters. Processorsmay·at user option· treat both "\p{IsX}" and "\P{IsX}" as denoting the empty set, instead of the set of all characters.

Note: The meaning defined for a block escape with an unrecognized block name makes it synonymous with the regular expression '.|[\n\r]'. A processor which does not recognize the block name will thus not enforce the constraint that the characters matched are in, or are not in, the block in question. Any string which satisfies the regular expression as written will be accepted, but not all strings accepted will actually satisfy the expression as written: some strings which do not satisfy the expression as written will also be accepted. So some invalid input will be wrongly identified as valid.
If (at·user option·) the expressions are treated as denoting the empty set, then the converse is true: any string which fails to satisfy the expression as written will be rejected, but not all strings rejected by the processor will actually have failed to satisfy the expression as written. So some valid input will be wrongly identified as invalid.
Which behavior is preferable in concrete circumstances depends on the relative cost of failure to accept valid input (false negatives) and failure to reject invalid input (false positives). It is for this reason that processors are allowed to provide·user options· to control the behavior. The principle of being liberal in accepting input (often called Postel's Law) suggests that the default behavior should be to accept strings not known to be invalid, rather than the converse; it is for this reason that block escapes with unknown block names should be treated as matching any character unless the user explicitly requests the alternative behavior.
G.4.2.5 Multi-character escapes

[Definition:]  Amulti-character escape provides a simple way to identifyany ofa commonly used set of characters: [Definition:]  Thewildcard character is a metacharacter which matchesalmost any single character:

[97]   MultiCharEsc   ::=   '\' [sSiIcCdDwW]
[98]   WildcardEsc   ::=   '.'

Character sequenceEquivalent·character class·
.[^\n\r]
\s[#x20\t\n\r]
\S[^\s]
\ithe set of initial name characters, those·matched· byNameStartChar in[XML]
\I[^\i]
\cthe set of name characters, those·matched· byNameChar
\C[^\c]
\d\p{Nd}
\D[^\d]
\w[#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}](all characters except the set of "punctuation","separator" and "other" characters)
\W[^\w]
Note: The·regular expression· language defined here does notattempt to provide a general solution to "regular expressions" overUCS character sequences.  In particular, it does not easily providefor matching sequences of base characters and combining marks.The language is targeted at support of "Level 1" features as defined in[Unicode Regular Expression Guidelines].  It is hoped that future versions of thisspecification will provide support for "Level 2" features.

H Implementation-defined and implementation-dependent features (normative)

next sub-sectionH.1 Implementation-defined features

The following features in this specification are·implementation-defined·.Any software which claims to conform to this specification (or to thespecification of any host language which embedsXSD 1.1: Datatypes)must describe how these choices have been exercised, in documentation which accompanies any conformance claim.

  1. For the datatypes which depend on[XML] or[Namespaces in XML], it is·implementation-defined· whether a conforming processor takes the relevantdefinitions from[XML] and[Namespaces in XML], orfrom[XML 1.0] and[Namespaces in XML 1.0]. Implementationsmay support eitherthe form of these datatypes based on version 1.0 of thosespecifications, or the form based on version 1.1, or both.
  2. For the datatypes with infinite·value spaces·, it is·implementation-defined· whether conforming processorsset a limit on the size of the values supported.If such limits are set, theymust be documented,and the limitsmust be equal to, or exceed, theminimal limits specified inPartial Implementation of Infinite Datatypes (§5.4)..
  3. It is·implementation-defined· whether·primitive· datatypes other thanthose defined in this specification are supported.
    For each·implementation-defined· datatype, aSimple Type Definitionmust bespecified which conforms to the rules given inBuilt-in Simple Type Definitions (§4.1.6).
    In addition, the following informationmust be provided:
    1. The nature of the datatype's·lexical space·,·value space·,and·lexical mapping·.
    2. The nature of the equality relation; in particular, how to determinewhether two values which are not identical are equal.
      Note: There is no requirement that equality be distinct from identity,but itmay be.
    3. The values of the·fundamental facets·.
    4. Which of the·constraining facets· defined in this specificationare applicable to the datatype (andmay thus be used in·facet-based restriction· from it), and what they mean when applied to it.
    5. If·implementation-defined··constraining facets· are supported, which of those·constraining facets· are applicable to the datatype, and what theymean when applied to it.
    6. What URI reference (more precisely, whatanyURI value)is to be used to refer to the datatype, analogous to those providedfor the datatypes defined here in sectionBuilt-in Datatypes and Their Definitions (§3).
      Note: It is convenient if the URI for a datatype and theexpanded name of its simple type definition are related by a simple mapping, like the URIs given for the·built-in· datatypesinBuilt-in Datatypes and Their Definitions (§3). However, this is nota requirement.
    7. For each·constraining facet· given a value for the new·primitive·,what URI reference (more precisely, whatanyURI value)is to be used to refer to the usage of that facet on the datatype, analogous to those provided, for the·built-in· datatypes, in sectionBuilt-in Datatypes and Their Definitions (§3).
      Note: As specified normatively elsewhere, the set of facets given valueswill at the very least include thewhiteSpace facet.
    The·value space· of the·primitive· datatypemust be disjointfrom those of the other·primitive· datatypes.
    The·lexical mapping· defined for an·implementation-defined· primitivemust be a total function from the·lexical space· onto the·value space·. That is, (1) each·literal· in the·lexical space·must map to exactly one value, and (2) each valuemust bethe image of at least one member of the·lexical space·, andmay be the image of more than one.
    For consistency with the·constraining facets· defined here,implementors who define new·primitive· datatypesshould allowthe·pattern· and·enumeration·facets to apply.
    The implementorshould specify a·canonical mapping·for the datatype if practicable.
  4. It is·implementation-defined· whether·constraining facets· other thanthose defined in this specification are supported.
    For each·implementation-defined· facet, the following informationmust be provided:
    1. What properties the facet has, viewed as a schema component.
      Note: For most·implementation-defined· facets, the structural pattern usedfor most·constraining facets· defined in this specification isexpected to be satisfactory, but other structuresmay be specified.
    2. Whether the facet is a·pre-lexical·,·lexical·, or·value-based· facet.
    3. Whether restriction of the facet takes the form of replacinga less restrictive facet value with a more restrictive value(as in the·minInclusive· and most other·constraining facets· defined in this specification) or of adding new values to a set of facet values (asfor the·pattern· facet). In the former case,the information providedmust also specify how to determinewhich of two given values is more restrictive (and thus canbe used to restrict the other).
      When an·implementation-defined· facet is used in·facet-based restriction·, thenew valuemust be at least as restrictive as the existingvalue, if any.
      Note: The effect of the preceding paragraph is to ensure thata type derived by·facet-based restriction· using an·implementation-defined· facet does not allow, or appear to allow, values not presentin the·base type·.
    4. What·primitive· datatypes the new·constraining facet· applies to, and what it means when applied to them.
      For a·pre-lexical· facet, how to compute the resultof applying the facet value to any given·literal·.
      For a·pre-lexical· facet, theorder in which it is applied to·literals·, relative toother·pre-lexical· facets.
      For a·lexical· facet, how to tell whether any given·literal· is facet-valid with respect to it.
      For a·value-based· facet, how to tell whether anygiven value in the relevant·primitive· datatypesis facet-valid with respect to it.
      Note: The host languagemay choose to specify that·implementation-defined··constraining facets· are applicable to·built-in··primitive·datatypes; this information is necessary to make the·implementation-defined· facet usable in such host languages.
    5. What URI reference (more precisely, whatanyURI value)is to be used to refer to the facet, analogous to those providedfor the datatypes defined here in sectionBuilt-in Datatypes and Their Definitions (§3).
    6. What element is to be used in XSD schema documents to apply the facetin the course of·facet-based restriction·. A schema documentmust beprovided with an element declaration for each·implementation-defined· facet;the element declarationsshould specifyxs:facet astheir substitution-group head.
      Note: The elements'expanded names are used by the condition-inclusionmechanism of[XSD 1.1 Part 1: Structures] to allow schema authors to test whethera particular facet is supported and adjust the schema document'scontents accordingly.
    ·Implementation-defined··pre-lexical· facetsmust not, when applied to·literals· which have been whitespace-normalizedby thewhiteSpace facet, produce·literals· which areno longer whitespace-normalized.
  5. It is·implementation-defined· whether an implementation of this specificationsupports other versions of the Unicode database[Unicode Database] in addition to the version cited normatively in the normativereferences (Normative (§K.1)). If an implementation supportsadditional versions of the Unicode database, it is·implementation-defined·which character properties and which block name definitions areused in a given validity assessment.
    It is·implementation-defined· whether an implementation is capable,·at user option·, of treating unrecognized block names as errorsin a schema.
    It is·implementation-defined· whether an implementation is capable,·at user option·, of treating unrecognized category escapes asdenoting the empty set instead of the set of all characters.
Note: It follows from the above that each·implementation-defined··primitive·datatype and each·implementation-defined· constraining facet has anexpanded name.Theseexpanded names are used by the condition-inclusion mechanismof[XSD 1.1 Part 1: Structures] to allow schema authors to test whether aparticular datatype or facet is supported and adjust the schema document'scontents accordingly.

previous sub-sectionH.2 Implementation-dependent features

The following features in this specification are·implementation-dependent·.Software which claims to conform to this specification (or to thespecification of any host language which embedsXSD 1.1: Datatypes)may describe how these choices have been exercised, in documentation which accompanies any conformance claim.

  1. When multiple errors are encountered in type definitions or elsewhere,it is·implementation-dependent· how many of the errors are reported (as longas at least one error is reported), and which,what form the report of errors takes, and how much detail is included.

I Changes since version 1.0

next sub-sectionI.1 Datatypes and Facets

In order to align this specification withthose being prepared by the XSL and XML Query Working Groups, a newdatatype namedanyAtomicType has been introduced; itserves as the base type definition for all·primitive··atomic· datatypes.

The treatment of datatypes has been made moreprecise and explicit; most of these changes affect the section onDatatype System (§2). Definitions have been revised thoroughly andtechnical terms are used more consistently.

The (numeric) equality of values is now distinguished fromthe identity of the values themselves; this allowsfloat anddouble to treat positive and negativezero as distinct values, but neverthelessto treat them as equal for purposes of bounds checking. This allows abetter alignment with the expectations of users working with IEEEfloating-point binary numbers.

The{value} of thebounded component forlist datatypes is now alwaysfalse, reflecting the fact that no ordering is prescribed for·list·datatypes, and sothey cannot be bounded using the facets defined by thisspecification.

Units of length have been specified for all datatypes that are permittedthe length constraining facet.

The use of the namespacehttp://www.w3.org/2001/XMLSchema-datatypes has beendeprecated. The definition of a namespace separate from the mainnamespace defined by this specification proved not to be necessary orhelpful in facilitating the use, by other specifications, of thedatatypes defined here, and its use raises a number of difficultunsolved practical questions.

Anassertions facet has been added, to allow schemaauthors to associated assertions with simple type definitions,analogous to those allowed by[XSD 1.1 Part 1: Structures] for complex type definitions.

The discussion of whitespace handling inwhiteSpace (§4.3.6) makes clearer that when the value iscollapse,·literals· consisting solely of whitespace characters are reduced to the empty string; the earlier formulation has been misunderstood by some implementors.

Conforming implementationsmay now support·primitive· datatypesand facets in addition to those defined here.

previous sub-sectionnext sub-sectionI.2 Numerical Datatypes

As noted above, positive and negative zero,float anddouble are now treated asdistinct but arithmetically equal values.

The description of the lexical spaces ofunsignedLong,unsignedInt,unsignedShort, andunsignedByte has been revised to agree with theschema for schemas by allowing for the possibility of aleading sign.

Thefloat anddouble datatypes now follow IEEE 754 implementationpractice more closely; in particular, negative and positive zero arenow distinct values, although arithmetically equal. Conversely, NaN is identical but not arithmetically equalto itself.

The character sequence '+INF' has been added to thelexical spaces offloat anddouble.

previous sub-sectionnext sub-sectionI.3 Date/time Datatypes

The treatment ofdateTime and related datatypes has been changed to provide a more explicit account ofthe value space in terms of seven numeric properties. The mostimportant substantive change is that values now explicitly retaininformation about the time zone offset indicated in the lexical form; thisallows better alignment with the treatment of such values in[XQuery 1.0 and XPath 2.0 Functions and Operators].

At the suggestion of theW3C OWL Working Group, aexplicitTimezone facethas been added to allow date/time datatypes to be restricted byrequiring or forbidding an explicit time zone offset from UTC,instead of making it optional. ThedateTimeStampdatatype has been defined using this facet.

Thetreatment of the date/time datatype includes a carefully reviseddefinition of order that ensures that for repeating datatypes (time,gDay, etc.), timezoned values will becompared as though they are on the same "calendarday" ("local" property values) so that inany given timezone, the days start at the local midnight and end justbefore local midnight.  Days do not run from 00:00:00Z to24:00:00Z in timezones other than Z.

The lexical representation'0000' for years is recognized and maps to the year 1BCE; '-0001' maps to 2 BCE, etc. This is a change fromversion 1.0 of this specification, in order to align with establishedpractice (the so-called "astronomical yearnumbering") and[ISO 8601].

Algorithms for arithmetic involvingdateTime andduration values have been provided, and correctionsmade to the·timeOnTimeline· function.

The treatment of leap seconds is no longer·implementation-defined·:the date/time types described here do not include leap-second values.

At the suggestion of theW3C Internationalization Core Working Group, most references to "time zone" have been replaced with references to "time zone offset"; thisresolves issue4642Terminology: zone offset versus time zone.

A number of syntactic and semantic errors in some of the regularexpressions given to describe the lexical spaces of the·primitive·datatypes (most notably the date/time datatypes) have been corrected.

The lexical mapping for times of the form '24:00:00' (withor without a trailing decimal point and zeroes) has been specifiedexplicitly.

previous sub-sectionI.4 Other changes

Support has been added for[XML] version 1.1 and[Namespaces in XML] version 1.1. The datatypes which depend on[XML] and[Namespaces in XML]may now be used with the definitions provided by the 1.1 versions of those specifications, as well as with the definitions in the1.0 versions. It is·implementation-defined· whether software conformingto this specification supports the definitions given in version 1.0,or in version 1.1, of[XML] and[Namespaces in XML].

To reduce confusion and avert a widespread misunderstanding, the normative references to various W3C specifications now state explicitly that while the reference describes the particular edition of a specification current at the time this specification is published, conforming implementations of this specification are not required to ignore later editions of the other specification but insteadmay support later editions, thus allowing users of this specification to benefit from corrections to other specifications on which this one depends.

The reference to the Unicode Database[Unicode Database]has been updated from version 4.1.0 to version 5.1.0,at the suggestion of theW3C Internationalization Core Working Group

References to various other specifications have also been updated.

The account of the value space ofduration has been changed to specify that values consist onlyof two numbers (the number of months and the number of seconds) ratherthan six (years, months, days, hours, minutes, seconds). This allowsclearly equivalent durations like P2Y and P24M to have the samevalue.

Two new totally ordered restrictions ofdurationhave been defined:yearMonthDuration, defined inyearMonthDuration (§3.4.26), anddayTimeDuration, defined indayTimeDuration (§3.4.27).This allows better alignment with the treatment of durations in[XQuery 1.0 and XPath 2.0 Functions and Operators].

The XML representations of the·primitive· and·ordinary· built-in datatypes have been moved out of the schema documentfor schema documents inSchema for Schema Documents (Datatypes) (normative) (§A) and into a different appendix (Illustrative XML representations for the built-in simple type definitions (§C)).

Numerous minor corrections have been made in response to commentson earlier working drafts.

The treatment of topics handled both in this specification and in[XSD 1.1 Part 1: Structures] has been revised to alignthe two specifications more closely.

Several references to other specifications have been updated torefer to current versions of those specifications, including[XML],[Namespaces in XML],[RFC 3986],[RFC 3987], and[RFC 3548].

Requirements for the datatype-validity of values of typelanguage have been clarified.

Explicit definitions have been provided for the lexical and·canonical mappings· of most of the primitive datatypes.

Schema Component Constraintenumeration facet value required for NOTATION (§3.3.19), which restricts the use ofNOTATION to validate·literals· without first enumerating a set of values, has been clarified.

Some errors in the definition of regular-expression metacharactershave been corrected.

The descriptions of thepatternandenumeration facets have been revised to make clearer howvalues from different derivation steps are combined.

A warning against using the whitespace facet for tokenizingnatural-language data has been added on the request of the W3CInternationalization Working Group.

In order to correct an error in version 1 of this specification and of[XSD 1.1 Part 1: Structures],·unions· are no longer forbidden to be members of other·unions·.Descriptions of·union· types have also been changed to reflect the fact that·unions· can be derived byrestricting other·unions·. The concepts of·transitive membership· (the members of all members, recursively) and·basic member· (those datatypes in the transitivemembership which are not·unions·) have been introduced and are used.

The requirements of conformance have been clarified in variousways.A distinction is now made between·implementation-defined· and·implementation-dependent· features, and a list ofsuch features is provided inImplementation-defined and implementation-dependent features (normative) (§H).Requirements imposed on host languages whichuse or incorporate the datatypes defined by this specification aredefined.

The definitions ofmust,must not, and·error· have been changed to specify that processorsmust detect andreport errors in schemas and schema documents (although the qualityand level of detail in the error report is not constrained).

The lexical mapping of theQName datatype,in particular its dependence on the namespace bindings inscope at the place where the·literal· appears, has been clarified.

The characterization of·lexical mappings· has been revised to saymore clearly when they are functions and when they are not, and when(in the·special· datatypes) there are values in the·value space· notmapped to by any members of the·lexical space·.

The nature of equality and identity of listshas been clarified.

Enumerations, identity constraints, and value constraints now treat both identical valuesand equal values as being the same for purposes of validation.This affects primitive datatypes in which identity and equalityare not the same. Positive and negative zero, for example,are not treated as different for purposes of keys, keyrefs,or uniqueness constraints, and an enumeration which includeseither zero will accept either zero.

The mutual relations of lists and unions have been clarified, inparticular the restrictions on what kinds of datatypesmay appear asthe·item type· of a list or among the·member types· of a union.

Unions with no member types (and thus with empty·value space· and·lexical space·) are now explicitly allowed.

Cycles in the definitions of·unions· and in thederivation of simple types are now explicitly forbidden.

A number of minor errors and obscurities have been fixed.

J Glossary (non-normative)

The listing below is for the benefit of readers of a printed version of thisdocument: it collects together all the definitions which appear in thedocument above.

Constraint on Schemas
Constraints on the schema components themselves, i.e. conditionscomponentsmust satisfy to be components at all.Largely to be found inDatatype components (§4).
Schema Representation Constraint
Constraints on the representation of schema components in XML. Some but not all of these are expressed inSchema for Schema Documents (Datatypes) (normative) (§A) andDTD for Datatype Definitions (non-normative) (§B).
UTC
UniversalCoordinated Time (UTC)is an adaptation of TAI which closely approximates UT1 by adding·leap-seconds· to selected·UTC· days.
Validation Rule
Constraints expressed by schema components which information itemsmust satisfy to be schema-valid.  Largely tobe found inDatatype components (§4).
XDM representation
For any valueV and any datatypeT, theXDM representation ofV underT is defined recursively as follows. Call the XDM representationX. Then
1IfT =·xs:anySimpleType· or·xs:anyAtomicType· thenX isV,and thedynamictype ofX isxs:untypedAtomic.
2IfT .{variety} =atomic,then letT2 be the·nearest built-in datatype· toT.IfV is a member of the·value space· ofT2, thenX isV and thedynamic typeofX isT2.Otherwise (i.e. ifV is not a member of the·value space· ofT2),X is the·XDM representation· ofV underT2 .{base type definition}.
3IfT .{variety} =list,thenX is a sequence of atomic values, each atomic value being the·XDM representation· of the correspondingitem in the listV underT .{item type definition}.
4IfT .{variety} =union,thenX is the·XDM representation· ofVunder the·active basic member· ofVwhen validated againstT.If there is no·active basic member·,thenV has no·XDM representation· underT.
absent
Throughout thisspecification, the valueabsent is used as a distinguished value to indicate that a given instance of a property"has no value" or "is absent".
active basic member
If the·active member type· isitself a·union·, one ofits members will beits·active member type·, and so on, untilfinally a·basic (non-union)member· is reached. That·basic member· istheactive basic member of the union.
active member type
In a validinstance of any·union·, the first of its members in order whichaccepts the instance as valid is theactive membertype.
ancestor
Theancestors of atype definition are its{base type definition} and the·ancestors· of its{base type definition}.
anyAtomicType
anyAtomicTypeis a special·restriction· ofanySimpleType.The·value·and·lexical spaces· ofanyAtomicType are the unions of the·value·and·lexical spaces·of all the·primitive· datatypes, andanyAtomicType is their·base type·.
anySimpleType
The definition ofanySimpleType is a special·restriction· ofanyType. The·lexical space· ofanySimpleTypeis the set of all sequences of Unicodecharacters, and its·value space· includes all·atomic values·and all finite-length lists of zero or more·atomic values·.
atomic
Atomic datatypesare those whose·value spaces· contain only·atomic values·Atomic datatypes areanyAtomicType and all datatypes·derived· from it.
atomic value
Anatomic value is an elementary value, notconstructed from simpler values by any user-accessiblemeans defined by this specification.
base type
Every datatypeother thananySimpleTypeis associated with another datatype, itsbase type.Base types can be·special·,·primitive·, or·ordinary·.
basic member
Those members of the·transitive membership·of a·union· datatypeU which are themselves not·union·datatypesare thebasic members ofU.
built-in
Built-indatatypes are those which are defined in this specification; they can be·special·,·primitive·, or·ordinary· datatypes.
canonical mapping
Thecanonical mapping is a prescribed subset of the inverse of a·lexical mapping· which is one-to-one and whose domain (where possible) is the entire range of the·lexical mapping· (the·value space·).
canonical representation
Thecanonicalrepresentation of a value in the·value space· of a datatype isthe·lexical representation· associated with that value by thedatatype's·canonical mapping·
character class subtraction
A·character group· that contains a subtraction operatoris referred to as acharacter class subtraction.
character group part
Acharacter group part (charGroupPart) is anyof: a single unescaped character(SingleCharNoEsc),a single escaped character(SingleCharEsc), a character class escape(charClassEsc),or a character range(charRange).
constraining facet
Constraining facetsare schema components whose values may be set or changedduring·derivation· (subject to facet-specific controls) to control various aspects of the derived datatype.
constructed
All·ordinary· datatypes are defined in terms of, orconstructed from, other datatypes, either by·restricting· the·value space· or·lexical space· of a·base type· using zero or more·constraining facets·or by specifying the new datatype as a·list· of items of some·item type·,or by defining it as a·union· of some specified sequence of·member types·.
datatype
Inthis specification, adatatype hasthree properties:
derived
A datatypeT isimmediately derived from another datatypeX if and only ifX is the·base type· ofT.
derived
A datatypeR isderived from another datatypeB if and only if one of the following is true:
div
Ifm andn are numbers, thenm divn is the greatest integer less than or equal tom / n .
error
A failure of a schema or schema document to conform to the rules of this specification.
Except as otherwise specified, processorsmust distinguisherror-free (conforming) schemas and schema documentsfrom those with errors;if a schema used in type-validation or a schema document used in constructing a schema is in error, processorsmust report the fact; if more than one is in error, it is·implementation-dependent· whether more than one is reported as being in error. If more than one of the constraints given in this specification is violated, it is·implementation-dependent· how many of the violations, and which, are reported.
Note: Failure of an XML element or attribute to be datatype-valid against a particular datatype in a particular schema is not in itself a failure to conform to this specification and thus, for purposes of this specification, not an error.
facet-based restriction
A datatype is defined byfacet-based restriction of another datatype(its·base type·),when values for zero or more·constraining facets· are specifiedthat serve to constrain its·value space· and/or its·lexical space· to a subset of those of the·base type·.
for compatibility
A feature of this specification included solely to ensure thatschemas which use this feature remain compatible with[XML].
fundamental facet
Eachfundamental facet is aschema component that provides a limited piece of information aboutsome aspect of each datatype.
implementation-defined
Somethingwhichmay vary among conforming implementations, but whichmustbe specified by the implementor for each particular implementation,isimplementation-defined.
implementation-dependent
Somethingwhichmay vary among conforming implementations, is not specified bythis or any W3C specification, and is not required to be specifiedby the implementor for any particular implementation,isimplementation-dependent.
incomparable
Twovalues that are neither equal, less-than, nor greater-than areincomparable. Two valuesthat are not·incomparable· arecomparable.
intervening union
If a datatypeM is in the·transitive membership· of a·union·datatypeU, but not one ofU's·member types·,then a sequence of one or more·union· datatypes necessarily exists,such that the first is one of the·member types· ofU, eachis one of the·member types· of its predecessor in the sequence, andM is one of the·member types· of the last in the sequence.The·union· datatypes in this sequence are said tointervene betweenM andU. WhenU andM are given by the context, the datatypesin the sequence are referred to as theintervening unions.WhenM is one of the·member types· ofU,the set ofintervening unions is the empty set.
item type
The·atomic· or·union·datatype that participates in the definition of a·list· datatypeis theitem type of that·list· datatype.
leap-second
Aleap-second is an additional second addedto the last day of December, June, October, or March,when such an adjustment is deemed necessary by the International Earth Rotation and Reference Systems Servicein order to keep·UTC· within 0.9 secondsof observed astronomical time.  When leap seconds areintroduced, the last minute in the day has more thansixty seconds. In theory leap seconds can also be removed from aday, but this has not yet occurred.(See[International Earth Rotation Service (IERS)],[ITU-R TF.460-6].)Leap seconds arenot supported by the types defined here.
lexical
A constraining facet whichdirectly restricts the·lexical space· of a datatype is alexical facet.
lexical mapping
Thelexical mapping for a datatype is a prescribed relationwhich maps from the·lexical space· of the datatypeinto its·value space·.
lexical representation
The members of the·lexical space· arelexical representations of the values to which they aremapped.
lexical space
Thelexical space of a datatype is the prescribed set of stringswhich·the lexicalmapping· for that datatypemaps to values of that datatype.
list
List datatypes arethose having values each of which consists of a finite-length(possibly empty) sequence of·atomic values·. The values in a list aredrawn from some·atomic· datatype (or froma·union· of·atomic· datatypes), which isthe·item type· of thelist.
literal
A sequence of zero or morecharacters in the Universal Character Set (UCS) which may or may notprove upon inspection to be a member of the·lexical space· of a givendatatype and thus a·lexical representation· of a given value in that datatype's·value space·, is referred to as aliteral.
match
(Of strings or names:) Two strings or names being compared must beidentical. Characters with multiple possible representations inISO/IEC 10646 (e.g. characters with both precomposed andbase+diacritic forms) match only if they have the same representationin both strings. No case folding is performed.
(Of strings and rules in the grammar:) A string matches a grammatical production if and only if it belongs to the languagegenerated by that production.
may
Schemas, schema documents, and processorsare permitted to but neednot behave as described.
member types
The datatypes that participate in thedefinition of a·union· datatype are known as themember types of that·union· datatype.
minimally conforming
Implementations claimingminimal conformance to this specificationindependent of any host languagemust doall of the following:
1Support all the·built-in· datatypes defined in this specification.
2Completely and correctly implement all of the·constraints on schemas·defined in this specification.
3Completely and correctly implement all of the·Validation Rules·defined in this specification, when checking thedatatype validity of literals against datatypes.
mod
Ifm andn are numbers, thenmmodn is m − n × ( m ·div· n) .
must
(Of schemas and schema documents:) Schemas and documentsare required to behave as described; otherwise they are in·error·.
(Of processors:)Processors are required to behave as described.
must not
Schemas, schema documentsand processors are forbidden to behave asdescribed; schemas and documents which neverthelessdo so are in·error·.
nearest built-in datatype
Forany datatypeT, thenearest built-in datatype toT is the first·built-in· datatype encountered in followingthe chain of links connecting each datatype to its·base type·. IfT is a·built-in· datatype, then thenearest built-in datatype ofT isT itself; otherwise,it is the nearest built-in datatype ofT's·base type·.
normalized block name
For any Unicode block, thenormalized block name of thatblock is the string of characters formed by stripping out white spaceand underbar characters from the block name as given in[Unicode Database], while retaining hyphens and preserving casedistinctions.
optional
Anoptionalproperty ispermitted but notrequired to have the distinguishedvalueabsent.
ordered
A·value space·, and hence a datatype, is said to beordered if somemembers of the·value space· are drawn from a·primitive· datatype for which the table inFundamental Facets (§F.1) specifiesthe valuetotal orpartial for theordered facet.
ordinary
Ordinarydatatypes are all datatypes other than the·special· and·primitive· datatypes.
owner
Acomponent may be referred to as theowner of its properties, and of the values ofthose properties.
pre-lexical
A constraining facet whichis used to normalize an initial·literal· before checkingto see whether the resulting character sequence is a member of a datatype's·lexical space· is apre-lexical facet.
primitive
Primitivedatatypes are those datatypes that are not·special· and arenot defined in terms of other datatypes;they existab initio.
regular expression
Aregular expression is composed from zero or more·branches·,separated by'|'characters.
restriction
A datatypeR is arestriction of another datatypeB when
should
It is recommended that schemas, schema documents, andprocessors behave as described, but therecan be valid reasons for them not to; it is important that thefull implications be understood and carefully weighed beforeadopting behavior at variance with the recommendation.
special
Thespecialdatatypes areanySimpleType andanyAtomicType.
special value
Aspecial value is an objectwhose only relevant properties for purposes of this specification are that itis distinct from, and unequal to, any other values (special or otherwise).
transitive membership
Thetransitive membership ofa·union· is the set of its own·member types·, and the·member types·of its members, and so on. More formally, ifU is a·union·, then (a) its·member types· are in the transitive membershipofU, and (b) for any datatypesT1 andT2, ifT1 is in the transitive membership ofU andT2 is one of the·member types· ofT1, thenT2 is also in the transitive membershipofU.
union
Union datatypesare (a) those whose·value spaces·,·lexical spaces·, and·lexical mappings· are the union of the·value spaces·,·lexical spaces·, and·lexical mappings· of one or more other datatypes, which are the·member types· of theunion, or (b) those derived by·facet-based restriction· of another union datatype.
unknown
Adatatype which is not available for use is said to beunknown.
unknown
An·constraining facet· which is not supported bythe processor in use isunknown.
user option
A choice left under the control of the user of a processor,rather than being fixed for all users or uses of the processor.
Statements in this specification that "Processorsmay at user option" behave in a certain way mean thatprocessorsmay provide mechanisms to allow users(i.e. invokers of the processor) to enable or disable thebehavior indicated. Processors which do not provide suchuser-operable controlsmust not behave in the way indicated.Processors which do provide such user-operable controlsmust make it possible for the user to disable the optional behavior.
Note: The normal expectation is that the default setting for such options will be to disable the optional behavior in question, enabling it only when the user explicitly requests it. This is not, however, a requirement of conformance: if the processor's documentation makes clear that the user can disable the optional behavior, then invoking the processor without requesting that it be disabled can be taken as equivalent to a request that it be enabled. It is required, however, that it in fact be possible for the user to disable the optional behavior.
Note: Nothing in this specification constrains the manner in which processors allow users to control user options. Command-line options, menu choices in a graphical user interface, environment variables, alternative call patterns in an application programming interface, and other mechanisms may all be taken as providing user options.
user-defined
User-defined datatypes are those datatypes that are defined by individual schema designers.
value space
Thevalue spaceof adatatype is the set of values for thatdatatype.
value-based
A constraining facet whichdirectly restricts the·value space· of a datatype is avalue-based facet.
wildcard character
Thewildcard character is a metacharacter which matchesalmost any single character:

K References

next sub-sectionK.1 Normative

IEEE 754-2008
IEEE.IEEE Standard for Floating-Point Arithmetic. 29August 2008.http://ieeexplore.ieee.org/servlet/opac?punumber=4610933
Namespaces in XML
World Wide Web Consortium. Namespaces in XML 1.1(Second Edition),ed. Tim Bray et al. W3C Recommendation 16 August 2006.Available at:http://www.w3.org/TR/xml-names11/The edition cited is the one current at the date of publication of thisspecification. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.For details of the dependency of this specification on Namespaces in XML 1.1, seeDependencies on Other Specifications (§1.3).
Namespaces in XML 1.0
World Wide Web Consortium. Namespaces in XML 1.0 (Third Edition),ed. Tim Bray et al.W3C Recommendation 8 December 2009.Available at:http://www.w3.org/TR/xml-names/The edition cited is the one current at the date of publication of thisspecification. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.For details of the dependency of this specification on Namespaces in XML 1.0, seeDependencies on Other Specifications (§1.3).
RFC 3548
S. Josefsson, ed.RFC 3548: The Base16, Base32, and Base64 Data Encodings.July 2003.  Available at:http://www.ietf.org/rfc/rfc3548.txt
Unicode Database
The Unicode Consortium.Unicode Character Database.Revision 3.1.0, ed. Mark Davis and Ken Whistler.2001-02-28.Available at:http://www.unicode.org/Public/3.1-Update/UnicodeCharacterDatabase-3.1.0.html.For later versions, seehttp://www.unicode.org/versions/.The edition cited is the one current at the date of publication of XSD 1.0. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.
XDM
World Wide Web Consortium.XQuery 1.0 and XPath 2.0 Data Model (XDM) (Second Edition),ed. Mary Fernández et al.W3C Recommendation 14 December 2010.Available at:http://www.w3.org/TR/xpath-datamodel/.
XML
World Wide Web Consortium.Extensible Markup Language (XML) 1.1(Second Edition), ed.Tim Bray et al.W3C Recommendation 16 August 2006, edited in place 29 September 2006.Available athttp://www.w3.org/TR/xml11/The edition cited is the one current at the date of publication of thisspecification. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.For details of the dependency of this specification on XML 1.1, seeDependencies on Other Specifications (§1.3).
XML 1.0
World Wide Web Consortium.Extensible Markup Language (XML) 1.0 (Fifth Edition), ed.Tim Bray et al.W3C Recommendation 26 November 2008.Available athttp://www.w3.org/TR/xml/.The edition cited is the one current at the date of publication of thisspecification. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.For details of the dependency of this specification on XML, seeDependencies on Other Specifications (§1.3).
XPath 2.0
World Wide Web Consortium.XML Path Language (XPath)2.0 (Second Edition),ed. Anders Berglund et al.W3C Recommendation 14 December 2010(Link errors corrected 3 January 2011).Available at:http://www.w3.org/TR/xpath20/.
XQuery 1.0 and XPath 2.0 Functions and Operators
World Wide Web Consortium.XQuery 1.0 and XPath 2.0 Functions and Operators(Second Edition),ed. Ashok Malhotra et al. W3C Recommendation 14 December 2010.Available at:http://www.w3.org/TR/xpath-functions/.
XSD 1.1 Part 1: Structures
World Wide Web Consortium.W3C XML Schema Definition Language (XSD) 1.1 Part 1:Structures, ed. Shudi (Sandy) Gao 高殊镝,C. M. Sperberg-McQueen,and Henry S. Thompson.W3C Recommendation 5 April 2012.Available at:http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/structures.htmlThe edition cited is the one current at the date of publication of thisspecification. Implementationsmay follow the edition cited and/orany later edition(s); it is implementation-defined which.

previous sub-sectionK.2 Non-normative

BCP 47
Internet Engineering Task Force (IETF). Best Current Practices 47.2006. Available at:http://tools.ietf.org/rfc/bcp/bcp47.Concatenation ofRFC 4646: Tags for Identifying Languages, ed. A. Phillips and M. Davis, September 2006,http://www.ietf.org/rfc/bcp/bcp47.txt,andRFC 4647: Matching of Language Tags, ed. A Phillips and M. Davis, September 2006,http://www.rfc-editor.org/rfc/bcp/bcp47.txt.
Clinger, WD (1990)
William D Clinger.How to Read Floating Point Numbers Accurately.InProceedings of Conference on Programming Language Design andImplementation, pages 92-101.Available at:ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps
HTML 4.01
World Wide Web Consortium. HTML 4.01Specification, ed. Dave Raggett,Arnaud Le Hors, andIan Jacobs.W3C Recommendation 24 December 1999.Available at:http://www.w3.org/TR/html401/
ISO 11404
ISO (International Organization for Standardization).Language-independent Datatypes. ISO/IEC 11404:2007.Seehttp://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39479
ISO 8601
ISO (International Organization for Standardization).Representations of dates and times, 1988-06-15.
ISO 8601:2000 Second Edition
ISO (International Organization for Standardization).Representations of dates and times, second edition, 2000-12-15.
ITU-R TF.460-6
International Telecommunication Union (ITU).Recommendation ITU-R TF.460-6: Standard-frequencyand time-signal emissions. [Geneva: ITU, February 2002.]
International Earth Rotation Service (IERS)
International Earth Rotation Service (IERS).Seehttp://maia.usno.navy.mil
LEIRI
Legacy extended IRIs for XML resource identification,ed. Henry S. Thompson, Richard Tobin, and Norman Walsh.W3C Working Group Note 3 November 2008(BNF comment style corrected in place 2009-07-09). Seehttp://www.w3.org/TR/leiri/
Perl
The Perl Programming Language.  Seehttp://www.perl.org/get.html
Precision Decimal
World Wide Web Consortium.An XSD datatype for IEEE floating-point decimal,ed. David Peterson and C. M. Sperberg-McQueen.W3C Working Group Note 9 June 2011.Available athttp://www.w3.org/TR/xsd-precisionDecimal/
RDF Schema
World Wide Web Consortium.RDF Vocabulary Description Language 1.0: RDF Schema,ed. Dan Brickley and R. V. Guha.W3C Recommendation 10 February 2004.Available at:http://www.w3.org/TR/rdf-schema/
RFC 2045
N. Freed and N. Borenstein.RFC 2045: Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies. 1996.  Available at:http://www.ietf.org/rfc/rfc2045.txt
RFC 3066
H. Alvestrand, ed.RFC 3066: Tags for the Identification of Languages1995. Available at:http://www.ietf.org/rfc/rfc3066.txt
RFC 3986
T. Berners-Lee,R. Fielding, and L. Masinter,RFC 3986: Uniform Resource Identifier (URI): Generic Syntax. January 2005.  Available at:http://www.ietf.org/rfc/rfc3986.txt
RFC 3987
M. Duerst and M. Suignard.RFC 3987: Internationalized Resource Identifiers (IRIs). January 2005.  Available at:http://www.ietf.org/rfc/rfc3987.txt
RFC 4646
A. Phillips and M. Davis, ed.RFC 4646: Tags for Identifying Languages2006. Available at:http://www.ietf.org/rfc/rfc4646.txt
RFC 4647
A. Phillips and M. Davis, ed.RFC 4647: Matching of Language Tags2006. Available at:http://www.ietf.org/rfc/rfc4647.txt
Ruby
World Wide Web Consortium.Ruby Annotation,ed. Marcin Sawicki et al. W3C Recommendation 31 May 2001 (Markup errors corrected 25 June 2008).Available at:http://www.w3.org/TR/ruby/
SQL
ISO (International Organization for Standardization). ISO/IEC9075-2:1999, Information technology --- Database languages ---SQL --- Part 2: Foundation (SQL/Foundation).[Geneva]: International Organization for Standardization, 1999.Seehttp://www.iso.org/iso/home.htm
Timezones
World Wide Web Consortium.Working with Time Zones,ed. Addison Phillips et al.W3C Working Group Note 5 July 2011.Available athttp://www.w3.org/TR/timezone/
U.S. Naval Observatory Time Service Department
Information about Leap SecondsAvailable at:http://tycho.usno.navy.mil/leapsec.html
USNO Historical List
U.S. Naval Observatory Time Service Department,Historical list of leap secondsAvailable at:ftp://maia.usno.navy.mil/ser7/tai-utc.dat
Unicode Regular Expression Guidelines
Mark Davis. Unicode Regular Expression Guidelines, 1988.Available at:http://www.unicode.org/unicode/reports/tr18/
Unicode block names
World Wide Web Consortium.Unicode block names for use in XSD regular expressions, ed. C. M. Sperberg-McQueen.W3C Working Group Note 9 June 2011.Available at:http://www.w3.org/TR/xsd-unicode-blocknames/
XML Schema Language: Part 0 Primer
World Wide Web Consortium. XML Schema Language: Part 0 Primer Second Edition,ed. David C. Fallside and Priscilla Walmsley. W3C Recommendation 28 October 2004.Available at:http://www.w3.org/TR/xmlschema-0/
XML Schema Requirements
XML Schema Requirements, ed.Ashok Malhotra and Murray Maloney.W3CNote 15 February 1999. Available at:http://www.w3.org/TR/NOTE-xml-schema-req
XSL
World Wide Web Consortium. Extensible Stylesheet Language (XSL),ed. Anders Berglund.W3C Recommendation 05 December 2006.Available at: http://www.w3.org/TR/xsl11/

L Acknowledgements (non-normative)

Along with theeditors thereof, the following contributed material to the first version of this specification:

Asir S. Vedamuthu, webMethods, Inc
Mark Davis, IBM

Co-editor Ashok Malhotra's work on this specification from March 1999 untilFebruary 2001 was supported by IBM, and from thenuntil May 2004 by Microsoft.  Since July 2004 his workon this specification has been supported by Oracle Corporation.

The work of Dave Petersonas a co-editor of this specification was supported by IDEAlliance(formerly GCA) through March 2004, and beginning in April 2004 by SGMLWorks!.

The work of C. M. Sperberg-McQueenas a co-editor of this specification was supported by the WorldWide Web Consortium through January 2009 and again from June 2010through May 2011, and beginning in February 2009 by Black Mesa Technologies LLC.

The XML Schema Working Group acknowledges with thanks the members of other W3C Working Groups and industry experts in otherforums who have contributed directly or indirectly to the creationof this document and its predecessor.

At the time this document is published, the members in good standing of the XML Schema Working Group are:

The XML Schema Working Group has benefited in its work from theparticipation and contributions of a number of people who are nolonger members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we notewith sadness the accidental death of Mario Jeckle shortly beforepublication of the first Working Draft of XML Schema 1.1.Affiliations given are (among) those current at the time of theindividuals' work with the WG.


[8]ページ先頭

©2009-2025 Movatter.jp