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.
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.
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.
The Working Group has two main goals for this version of W3C XMLSchema:
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:
The overall aim as regards compatibility is that
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 oriented | Document oriented |
---|---|
<invoice> <orderDate>1999-01-21</orderDate> <shipDate>1999-01-25</shipDate> <billingAddress> <name>Ashok Malhotra</name> <street>123 Microsoft Ave.</street> <city>Hawthorne</city> <state>NY</state> <zip>10532-0000</zip> </billingAddress> <voice>555-1234</voice> <fax>555-4321</fax></invoice> | <memo importance='high' date='1999-03-23'> <from>Paul V. Biron</from> <to>Ashok Malhotra</to> <subject>Latest draft</subject> <body> We need to discuss the latest draft <emph>immediately</emph>. Either email me at <email> mailto:paul.v.biron@kp.org</email> or call <phone>555-9876</phone> </body></memo> |
The invoice contains several dates and telephone numbers, the 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.
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.
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.
The[XML Schema Requirements] document spells outconcrete requirements to be fulfilled by this specification,which state that the XML Schema Language must:
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].
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:
This specification provides three different kinds of normativestatements about schema components, their representations in XML andtheir contribution to the schema-validation of information items:
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.
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.
[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.
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.
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.
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.
+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.
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.
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.
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 .
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.
[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.
[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·.
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·.
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.
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.
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)
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.
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.
An·atomic· datatype has a·value space·consisting of a set of "atomic" or elementary values.
The·lexical space· of an·atomic· datatype is a set of·literals·whose internal structure is specific to the datatype 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·.
·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·.
<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.
<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>
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.
<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·.
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.
<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.
[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.
<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.
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.
[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.
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.
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.
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.
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.
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·.
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·.
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.
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.
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.
Diagram showing the derivation relations in the built-in type hierarchy. (Along description of the diagram is available separately.)
http://www.w3.org/2001/XMLSchema#int
http://www.w3.org/2001/XMLSchema#maxInclusive
.
') followed by the name of the facethttp://www.w3.org/2001/XMLSchema#int.maxInclusive
The·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:
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:
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].)
The two datatypes at the root of the hierarchy of simpletypes areanySimpleType andanyAtomicType.
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).
The·value space· ofanySimpleTypeis the set of all·atomic values· and of all finite-lengthlists of zero or more·atomic values·.
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.
When a new datatype is defined by·facet-based restriction·,anySimpleTypemust not be usedas the·base type·.So no·constraining facets· aredirectly applicable toanySimpleType.
[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).
The·value space· ofanyAtomicType is the union of the·value spaces· of all the·primitive· datatypes defined hereor supplied as·implementation-defined··primitives·.
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.
When a new datatype is defined by·facet-based restriction·,anyAtomicTypemust not be usedas the·base type·.So no·constraining facets· aredirectly applicable toanyAtomicType.
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.
[Definition:] Thestring datatyperepresents character strings in XML.
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.
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.
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·:
[Definition:] booleanrepresents the values of two-valued logic.
boolean has the·value space· oftwo-valued logic: {true,false}.
The·lexical mapping·forboolean is·booleanLexicalMap·;the·canonical mapping· is·booleanCanonicalMap·.
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·:
[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.
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
'.
(\+|-)?([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·.
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·:
[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.
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.
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.NaN
').INF
', '+INF
','-INF
', and 'NaN
'
(\+|-)?([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)].
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].
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·:
[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.
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.
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.NaN
').INF
', '+INF
','-INF
', and 'NaN
'
(\+|-)?([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)].
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].
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·:
[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·.
Under the definition just given, twoduration values are equal if and only if they are identical.
T
' ((duHourFrag duMinuteFrag? duSecondFrag?) |(duMinuteFrag duSecondFrag?) |duSecondFrag)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.
matches only strings in which the fields occur in the proper order.
-?P[0-9]+Y?([0-9]+M)?([0-9]+D)?(T([0-9]+H)?([0-9]+M)?([0-9]+(\.[0-9]+)?S)?)?
.*[YMDHS].*
' matches onlystrings in which at least one field occurs..*[^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.-?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·.
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·:
The following·built-in· datatypes are·derived· fromduration
dateTime representsinstants of time, optionally markedwith a particular time zone offset. Values representingthe same instant but havingdifferent time zone offsets are equal but notidentical.
dateTime uses thedate/timeSevenPropertyModel, with no properties except·timezoneOffset·permitted to beabsent. The·timezoneOffset· property remains·optional·.
Equality and order are as prescribedinThe Seven-property Model (§D.2.1). dateTime values are orderedby their·timeOnTimeline· value.
-
' monthFrag '-
' dayFrag 'T
' ((hourFrag ':
' minuteFrag ':
' secondFrag) |endOfDayFrag)timezoneFrag? Constraint: Day-of-month Representations3
' 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.-
', 'T
', and':
', separate the various numerals.Z
' is an alternative representation of the time zone offset '00:00
', which is, of course, zero minutes from UTC.-?([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·.
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·:
timerepresents instants of time that recur at the same point in eachcalendar day, or that occur in some arbitrary calendar day.
time uses thedate/timeSevenPropertyModel, with·year·,·month·,and·day· required to beabsent. ·timezoneOffset· remains·optional·.
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.
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).Note that neitherthetimeLexicalRep productionnor this regularexpression alone enforce the constraintontimeLexicalRep given above.
(([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))?
The·lexical mapping·fortime is·timeLexicalMap·; the·canonical mapping· is·timeCanonicalMap·.
00:00:00
' and'24:00:00
' to the same value, namely midnight(·hour· = 0 ,·minute· = 0 ,·second· = 0).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·:
[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.
date uses thedate/timeSevenPropertyModel, with·hour·,·minute·,and·second· required to beabsent. ·timezoneOffset· remains·optional·.
Equality and order are as prescribed inThe Seven-property Model (§D.2.1).
-
' monthFrag '-
' dayFragtimezoneFrag? Constraint: Day-of-month Representations3
' 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.Note that neitherthedateLexicalRep productionnor this regularexpression alone enforce the constraintondateLexicalRep given above.
-?([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))?
The·lexical mapping·fordate is·dateLexicalMap·.The·canonical mapping· is·dateCanonicalMap·.
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·:
gYearMonth represents specific whole Gregorian months in specific Gregorian years.
gYearMonth uses thedate/timeSevenPropertyModel, with·day·,·hour·,·minute·, and·second· required to beabsent. ·timezoneOffset· remains·optional·.
Equality and order are as prescribed inThe Seven-property Model (§D.2.1).
-?([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·.
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·:
gYearrepresents Gregorian calendar years.
gYear uses thedate/timeSevenPropertyModel, with·month·,·day·,·hour·,·minute·, and·second· required to beabsent. ·timezoneOffset· remains·optional·.
Equality and order are as prescribed inThe Seven-property Model (§D.2.1).
-?([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·.
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·:
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.
gMonthDay uses thedate/timeSevenPropertyModel, with·year·,·hour·,·minute·, and·second· required to beabsent. ·timezoneOffset· remains·optional·.
Equality and order are as prescribed inThe Seven-property Model (§D.2.1).
--
' monthFrag '-
' dayFragtimezoneFrag? Constraint: Day-of-month Representations3
' 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.Note that neitherthegMonthDayLexicalRep productionnor this regularexpression alone enforce the constraintongMonthDayLexicalRep given above.
--(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))?
The·lexical mapping·forgMonthDay is·gMonthDayLexicalMap·.The·canonical mapping· is·gMonthDayCanonicalMap·.
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·:
[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.)
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.)
---(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·.
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·:
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).
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).
--(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·.
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·:
[Definition:] hexBinaryrepresents arbitrary hex-encoded binary data.
The·value space· ofhexBinaryis the set of finite-length sequences of zero or morebinary octets. Thelength of a value is the number of octets.
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.
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·.
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·:
[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].
The·value space· ofbase64Binary is the set of finite-length sequences ofzero or morebinary octets. Thelength of a value is the number of octets.
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.
Note that each '
((([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] ?= ?=))?
?
' 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].
The canonical·lexical representation· of abase64Binarydata value is the Base64 encoding of the value which matches theCanonical-base64Binary production in the following grammar:
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.
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].
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·:
[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.
The value space ofanyURI is the set of finite-lengthsequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].
The·lexical space· ofanyURIis the set of finite-lengthsequences of zero or morecharacters (as defined in[XML]) that·match· theChar production from[XML].
%20
').The·lexical mapping· foranyURI isthe identity mapping.
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·:
[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.
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·:
[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).
The lexical mapping rules forNOTATION are as given forQName inQName (§3.3.18).
For compatibility (seeTerminology (§1.6))NOTATIONshould be used only on attributesand should only be used in schemas with notarget namespace.
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.
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).
[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.
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·:
[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.
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·:
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.
[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*
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.xml:lang
defined by[XML] is one example; there, the empty stringoverrides a value which would otherwise be inherited, butwithout specifying a new value.xml: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>
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·:
[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.
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·:
[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.
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·:
[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).
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·:
[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).
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·:
[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.
For compatibility (seeTerminology (§1.6)),IDshould be used only on attributes.
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·:
[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.
For compatibility (seeTerminology (§1.6)) this datatypeshould be used only on attributes.
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·:
[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.
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·:
[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.
For compatibility (seeTerminology (§1.6))ENTITYshould be used only on attributes.
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·:
[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.
For compatibility (seeTerminology (§1.6))ENTITIESshould be used only on attributes.
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·:
[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.
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.
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.
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·:
The following·built-in· datatypes are·derived· frominteger
[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.
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.
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.
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·:
The following·built-in· datatype is·derived· fromnonPositiveInteger
[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.
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.
The·canonical representation· fornegativeIntegeris defined by prohibiting certain options from theLexical representation (§3.4.15.1). Specifically, leading zeroes are prohibited.
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·:
[Definition:] longis·derived· frominteger by setting thevalue of·maxInclusive· to be 9223372036854775807and·minInclusive· to be -9223372036854775808.The·base type· oflong isinteger.
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.
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.
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·:
[Definition:] intis·derived· fromlong by setting thevalue of·maxInclusive· to be 2147483647 and·minInclusive· to be -2147483648. The·base type· ofint islong.
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.
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.
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·:
[Definition:] short is·derived· fromint by setting thevalue of·maxInclusive· to be 32767 and·minInclusive· to be -32768. The·base type· ofshort isint.
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.
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.
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·:
[Definition:] byteis·derived· fromshortby setting the value of·maxInclusive· to be 127and·minInclusive· to be -128.The·base type· ofbyte isshort.
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.
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.
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·:
[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.
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.
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.
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·:
The following·built-in· datatypes are·derived· fromnonNegativeInteger
[Definition:] unsignedLong is·derived· fromnonNegativeInteger by setting the value of·maxInclusive· to be 18446744073709551615. The·base type· ofunsignedLong isnonNegativeInteger.
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.
The·canonical representation· forunsignedLongis defined by prohibiting certain options from theLexical representation (§3.4.21.1). Specifically,leading zeroes are prohibited.
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·:
[Definition:] unsignedInt is·derived· fromunsignedLong by setting the value of·maxInclusive· to be 4294967295. The·base type· ofunsignedInt isunsignedLong.
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.
The·canonical representation· forunsignedIntis defined by prohibiting certain options from theLexical representation (§3.4.22.1). Specifically,leading zeroes are prohibited.
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·:
The following·built-in· datatype is·derived· fromunsignedInt
[Definition:] unsignedShort is·derived· fromunsignedInt by setting the value of·maxInclusive· to be 65535. The·base type· ofunsignedShort isunsignedInt.
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.
The·canonical representation· forunsignedShortis defined by prohibiting certain options from theLexical representation (§3.4.23.1). Specifically, the leading zeroes are prohibited.
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·:
The following·built-in· datatype is·derived· fromunsignedShort
[Definition:] unsignedByte is·derived· fromunsignedShort by setting the value of·maxInclusive· to be 255. The·base type· ofunsignedByte isunsignedShort.
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.
The·canonical representation· forunsignedByteis defined by prohibiting certain options from theLexical representation (§3.4.24.1). Specifically,leading zeroes are prohibited.
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·:
[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.
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.
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.
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·:
[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.
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).
PT0S
') is not in the·lexical space· ofyearMonthDuration.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·:
[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.
The lexical space is reduced from that ofduration bydisallowingduYearFrag andduMonthFragfragments in the·lexical representations·.
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).
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·:
[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.
As a consequence of requiring an explicit time zone offset, thelexical space ofdateTimeStamp is reduced from thatofdateTime by requiring atimezoneFragfragment in the·lexical representations·.
-
' monthFrag '-
' dayFrag 'T
' ((hourFrag ':
' minuteFrag ':
' secondFrag) |endOfDayFrag)timezoneFrag Constraint: Day-of-month RepresentationsIn 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.
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·:
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.
Simple Type Definitions provide for:
The Simple Type Definition schema component has the following properties:
Either anAttribute Declaration, anElement Declaration, aComplex Type Definition or aSimple Type Definition.
With one exception, the{base type definition} of anySimple Type Definition is aSimple Type Definition. The exception is·anySimpleType·, which hasanyType, aComplex Type Definition, as its{base type definition}.
Ifnotabsent,must be a·primitive· built-in definition.
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.
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}.
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:
simpleType
Element Information Item et al.targetNamespace
[attribute]of the parentschema
element information item, if present,otherwiseabsent.base
[attribute] of<restriction>, if present, otherwise thetype definition corresponding to the<simpleType> amongthe[children] of<restriction>.{
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: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>
SKU
' is the name of the new·user-defined· datatype,string isits·base type· and·pattern· is the facet.itemType
[attribute] of<list>,or (b) corresponding to the<simpleType> amongthe[children] of<list>, whichever is present.itemType
[attribute] or a<simpleType>[child], but not both.<simpleType name='listOfFloat'> <list itemType='float'/></simpleType>
memberTypes
[attribute] of<union>, ifany, and (b) those corresponding to the<simpleType>samong the[children] of<union>, if any, in order.memberTypes
[attribute] or one or more<simpleType>[children],or both.<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·.
itemType
[attribute] or the<simpleType>[child] of the<list> elementmustbe present, but not both.base
[attribute] or thesimpleType
[child] of the<restriction>elementmustbe present, but not both.memberTypes
[attribute] of the<union>elementmustbe non-empty ortheremustbe at least onesimpleType
[child].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.
TheSimple Type Definition ofanySimpleType ispresent in every schema. It has the following properties:
anySimpleType
'http://www.w3.org/2001/XMLSchema
'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:
anyAtomicType
'http://www.w3.org/2001/XMLSchema
'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:
http://www.w3.org/2001/XMLSchema
'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).
http://www.w3.org/2001/XMLSchema
'[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·.
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.
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.
[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.
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.
{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.
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.
{value} depends on the·owner's·{variety},{facets}, and{member type definitions}.
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.
Some value spaces are made up of things thatare conceptuallynumeric, others arenot. Thenumeric facet value indicates which areconsidered numeric.
{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.
[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.
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.
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.
[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.
·length· provides for:
<simpleType name='productCode'> <restriction base='string'> <length value='8' fixed='true'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forlength other than{value}.
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:
length
Element Information ItemThe use of·length·onQName,NOTATION, and datatypes·derived· from themis deprecated. Future versions of thisspecification may remove this facet for these datatypes.
[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.
·minLength· provides for:
<simpleType name='non-empty-string'> <restriction base='string'> <minLength value='1'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminLength other than{value}.
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:
minLength
Element Information ItemThe use of·minLength·onQName,NOTATION, and datatypes·derived· from themis deprecated. Future versions of thisspecification may remove this facet for these datatypes.
[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.
·maxLength· provides for:
<simpleType name='form-input'> <restriction base='string'> <maxLength value='50'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxLength other than{value}.
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:
maxLength
Element Information ItemThe use of·maxLength·onQName,NOTATION, and datatypes·derived· from themis deprecated. Future versions of thisspecification may remove this facet for these datatypes.
[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·.
·pattern· provides for:
<simpleType name='better-us-zipcode'> <restriction base='string'> <pattern value='[0-9]{5}(-[0-9]{4})?'/> </restriction></simpleType>
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:
pattern
Element Information Itemvalue
[attribute]value
[attributes], in order,separated by '|
', so forming a single regular expression with multiple·branches·.value
[attribute] must be a·regular expression· asdefined inRegular Expressions (§G).[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:
<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>
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:
enumeration
Element Information Itemvalue
[attribute], interpreted as an instance of the{base type definition}.value
[attributes], interpreted as instances of the{base type definition}.value
[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}.value
[attribute] must beDatatype Valid (§4.1.4) with respect to the{base type definition} of theSimple Type Definitioncorresponding to the nearest<simpleType> ancestorelement.[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}.
hexadecimal A
(line feed), which is denoted byU+000A. This notation is to be distinguished from

, 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.
·whiteSpace· provides for:
<simpleType name='token'> <restriction base='normalizedString'> <whiteSpace value='collapse'/> </restriction></simpleType>
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.If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forwhiteSpace other than{value}.
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:
whiteSpace
Element Information Item[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:
<simpleType name='one-hundred-or-less'> <restriction base='integer'> <maxInclusive value='100'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxInclusive other than{value}.
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:
maxInclusive
Element Information Item[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:
<simpleType name='less-than-one-hundred-and-one'> <restriction base='integer'> <maxExclusive value='101'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue formaxExclusive other than{value}.
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:
maxExclusive
Element Information Item[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:
<simpleType name='more-than-ninety-nine'> <restriction base='integer'> <minExclusive value='99'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminExclusive other than{value}.
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:
minExclusive
Element Information Item[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:
<simpleType name='one-hundred-or-more'> <restriction base='integer'> <minInclusive value='100'/> </restriction></simpleType>
If{fixed} istrue, then types for whichthe current type is the{base type definition} cannot specify avalue forminInclusive other than{value}.
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:
minInclusive
Element Information Item[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.
If{fixed} istrue, then types for whichthe current type is the{base type definition}must not specify avalue fortotalDigits other than{value}.
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:
totalDigits
Element Information Item[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 ≤n ≤f.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.
<simpleType name='celsiusBodyTemp'> <restriction base='decimal'> <fractionDigits value='1'/> <minInclusive value='32'/> <maxInclusive value='41.7'/> </restriction></simpleType>
If{fixed} istrue, thentypes for which the current type is the{base type definition}must notspecify a value forfractionDigits otherthan{value}.
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:
fractionDigits
Element Information Item[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].
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>
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.
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:
assertion
Element Information ItemThe 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·.
xs:anySimpleType
· or·xs:anyAtomicType
· thenX isV,and thedynamictype ofX isxs:untypedAtomic
.true
under theconditions laid out below, without raising anydynamic error ortype error.expanded QName
of that member has no namespace URI and has 'value
' as the local name. The (static)type
of the member isanyAtomicType*
.anyAtomicType*
simply says that for static typing purposes the variable$value
will have a value consisting of a sequence of zero or more atomic values..
', 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.$value
" can be used to refer to the value being checked.expanded QName
of that member has no namespace URI and 'value
' as the local name. Thevalue
of the member is the·XDM representation· ofV underT.true
orfalse
as if by a call to the XPathfn:boolean function.[Definition:] explicitTimezone is a three-valued facet which can can be used to require or prohibit the time zone offset in date/time datatypes.
<simpleType name='bare-date'> <restriction base='date'> <explicitTimezone value='prohibited'/> </restriction></simpleType>
<simpleType name='bare-date'> <restriction base='date'> <pattern value='[^:Z]*'/> </restriction></simpleType>
If{fixed} istrue, then datatypes for whichthe current type is the{base type definition} cannot specify avalue forexplicitTimezone other than{value}.
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:
explicitTimezone
Element Information ItemXSD 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.
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.
In addition, host languagesmust require conforming implementations ofthe host language to obey all of the constraints and rulesspecified here.
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.
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.
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).
<?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>
The DTD for the datatypes-specificaspects of schema documents is given below. Note there isno implication here thatschema
must bethe root element of a document.
<!-- 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;>
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.
<?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>
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.
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.
<?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>
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.
e
' | 'E
')noDecimalPtNumeralThere 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.
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").
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.
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.
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.
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 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.
The following functions are used with various numeric and date/time datatypes.
d | : | matchesdigit |
0
' ,1
' ,2
' ,S | : | a finite sequence of·literals·, each term matchingdigit. |
S | : | a finite sequence of·literals·, each term matchingdigit. |
N | : | matchesfracFrag |
N | : | matchesunsignedNoDecimalPtNumeral |
N | : | matchesnoDecimalPtNumeral |
+
' or '-
') and thena·literal·U that matchesunsignedNoDecimalPtNumeral.-
' is present, andD | : | matchesunsignedDecimalPtNumeral |
N | : | matchesdecimalPtNumeral |
+
' or '-
') and thenan instanceU ofunsignedDecimalPtNumeral.-
' is present, andN | : | matchesscientificNotationNumeral |
e
' or an 'E
', and then an instanceE ofnoDecimalPtNumeral.i | : | between 0 and 9 inclusive |
0
' when i = 0 ,1
' when i = 1 ,2
' when i = 2 ,i | : | a nonnegative integer |
i | : | a nonnegative integer |
s | : | a sequence of nonnegative integers |
f | : | nonnegative and less than 1 |
f | : | nonnegative and less than 1 |
f | : | nonnegative and less than 1 |
i | : | a nonnegative integer |
i | : | an integer |
-
' & ·unsignedNoDecimalPtCanonicalMap·(−i) wheni is negative,n | : | a nonnegative decimal number |
.
' &·fractionDigitsCanonicalFragmentMap·(n·mod·1) .n | : | a decimal number |
-
' & ·unsignedDecimalPtCanonicalMap·(−i) wheni is negative,n | : | a nonnegative decimal number |
E
' &·noDecimalPtCanonicalMap·(log(n) ·div· 1)n | : | a decimal number |
-
' & ·unsignedScientificCanonicalMap·(−n) whenn is negative,For example:
123
'4567
'123.4567
'S | : | matchesnumericalSpecialRep |
INF
' or '+INF
',-INF
', andNaN
'c | : | one ofpositiveInfinity,negativeInfinity, andnotANumber |
INF
' whenc ispositiveInfinity-INF
' whenc isnegativeInfinityNaN
' whenc isnotANumberLEX | : | matchesdecimalLexicalRep |
Let | d be adecimal value. |
d | : | adecimal value |
nV | : | an initially non-zero decimal number(may beset to zero during calculations) |
cWidth | : | a positive integer |
eMin | : | an integer |
eMax | : | an integer greater thaneMin |
Let |
|
n | : | a decimal number |
k | : | a nonnegative integer |
c | : | a nonnegative integer |
e | : | an integer |
j | : | a nonnegative integer |
LEX | : | matchesfloatRep |
Let | nV be a decimal number or·special value· (INF or −INF). |
-
', andLEX | : | matchesdoubleRep |
Let | nV be a decimal number or·special value· (INF or −INF). |
-
', andf | : | afloat value |
Let |
|
0.0E0
' whenfispositiveZero;-0.0E0
' whenfisnegativeZero;f | : | adouble value |
Let |
|
0.0E0
' whenfispositiveZero;-0.0E0
' whenfisnegativeZero;Y | : | matchesduYearFrag |
Y
' followed by a numeralN:M | : | matchesduYearFrag |
M
' followed by a numeralN:D | : | matchesduDayFrag |
D
' followed by a numeralN:H | : | matchesduHourFrag |
D
' followed by a numeralN:M | : | matchesduMinuteFrag |
M
' followed by a numeralN:S | : | matchesduSecondFrag |
S
' followed by a numeralN:.
' occursinN, andYM | : | matchesduYearMonthFrag |
Let |
|
T | : | matchesduTimeFrag |
Let |
|
DT | : | matchesduDayTimeFrag |
Let |
|
DUR | : | matchesdurationLexicalRep |
-
', followed by 'P
' and then an instanceY ofduYearMonthFrag and/or an instanceD ofduDayTimeFrag:-
' andY are present, and-
' andD are present, andYM | : | matchesyearMonthDurationLexicalRep |
-
', followed by'P
' and then an instanceY ofduYearMonthFrag:-
' ispresent inYM andDT | : | adayTimeDuration value |
-
', followed by'P
' and then an instanceD ofduDayTimeFrag:-
' ispresent inDT andym | : | a nonnegative integer |
Y
' &·unsignedNoDecimalPtCanonicalMap·(m) & 'M
' when neithery norm is zero,Y
' wheny is not zero butm is, andM
' wheny is zero.d | : | a nonnegative integer |
D
' whend is not zero, andh | : | a nonnegative integer |
H
' whenh is not zero, andm | : | a nonnegative integer |
M
' whenm is not zero, ands | : | a nonnegative decimal number |
S
' whens is a non-zero integer,S
' whens is not an integer, andh | : | a nonnegative integer |
m | : | a nonnegative integer |
s | : | a nonnegative decimal number |
T
' &·duHourCanonicalFragmentMap·(h) &·duMinuteCanonicalFragmentMap·(m) &·duSecondCanonicalFragmentMap·(s) whenh,m, ands are not all zero, andss | : | a nonnegative decimal number |
Let |
T0S
' whenss is zero.v | : | a completeduration value |
Let |
P
' &·duYearMonthCanonicalFragmentMap·(| m |) &·duDayTimeCanonicalFragmentMap·(| s |) when neitherm nors is zero,P
' &·duYearMonthCanonicalFragmentMap·(| m |) whenm is not zero buts is, andP
' &·duDayTimeCanonicalFragmentMap·(| s |) whenm is zero.ym | : | a completeyearMonthDuration value |
Let |
|
P
' &·duYearMonthCanonicalFragmentMap·(| m |) .dt | : | a completedayTimeDuration value |
Let |
|
P
' &·duYearMonthCanonicalFragmentMap·(| s |) .yr | : | an integer |
mo | : | an integer |
yr | : | an integer |
mo | : | an integer |
da | : | an integer |
yr | : | an integer |
mo | : | an integer |
da | : | an integer |
hr | : | an integer |
mi | : | an integer |
yr | : | an integer |
mo | : | an integer |
da | : | an integer |
hr | : | an integer |
mi | : | an integer |
se | : | a decimal number |
y | : | an·optional· integer |
m | : | an integer between 1 and 12 |
Yr | : | an·optional·integer |
Mo | : | an·optional·integer between 1 and 12 inclusive |
Da | : | an·optional·integer between 1 and 31 inclusive |
Hr | : | an·optional·integer between 0 and 24 inclusive |
Mi | : | an·optional·integer between 0 and 59 inclusive |
Se | : | an·optional·decimal number greater than or equal to 0 and less than 60 |
Tz | : | an·optional·integerbetween −840 and 840 inclusive. |
Let |
|
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].
Let |
This algorithm may be applied to date/time typesother thandateTime, by
Examples:
dateTime | duration | result |
---|---|---|
2000-01-12T12:13:14Z | P1Y3M5DT7H10M3.3S | 2001-04-17T19:23:17.3Z |
2000-01 | -P3M | 1999-10 |
2000-01-12 | PT33H | 2000-01-13 |
((dateTime + duration1) + duration2) != ((dateTime +duration2) + duration1)
Example:
dt | : | adate/timeSevenPropertyModelvalue |
Let |
YR | : | matchesyearFrag |
MO | : | matchesmonthFrag |
DA | : | matchesdayFrag |
HR | : | matcheshourFrag |
MI | : | matchesminuteFrag |
SE | : | matchessecondFrag |
TZ | : | matchestimezoneFrag |
Z
', or a sign ('+
' or '-
') followed by an instanceH ofhourFrag, a colon, and an instanceM ofminuteFragZ
',LEX | : | matchesdateTimeLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
LEX | : | matchestimeLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent |
LEX | : | matchesdateLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent |
LEX | : | matchesgYearMonthLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
LEX | : | matchesgYearLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
LEX | : | matchesgMonthDayLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
LEX | : | matchesgDayLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
LEX | : | matchesgMonthLexicalRep |
Let | tzbe·timezoneFragValue·(T) whenTis present, otherwiseabsent. |
i | : | a nonnegative integer less than 100 |
i | : | an integer whose absolute value is less than 10000 |
-
' & ·unsTwoDigitCanonicalFragmentMap·(−i ·div· 100) &·unsTwoDigitCanonicalFragmentMap·(−i ·mod· 100) wheni is negative,y | : | an integer |
m | : | an integer between 1 and 12 inclusive |
d | : | an integer between 1 and 31 inclusive (may be limited further depending on associated·year· and·month·) |
h | : | an integer between 0 and 23 inclusive. |
m | : | an integer between 0 and 59 inclusive. |
s | : | a nonnegative decimal number less than 70 |
.
' &·fractionDigitsCanonicalFragmentMap·(s·mod·1) otherwise.t | : | an integer between −840 and 840 inclusive |
Z
' whent is zero,-
' & ·unsTwoDigitCanonicalFragmentMap·(−t ·div· 60) &':
' &·unsTwoDigitCanonicalFragmentMap·(−t ·mod· 60) whent is negative, and+
' & ·unsTwoDigitCanonicalFragmentMap·(t ·div· 60) &':
' &·unsTwoDigitCanonicalFragmentMap·(t ·mod· 60) otherwise.dt | : | a completedateTime value |
Let | DT be ·yearCanonicalFragmentMap·(dt's ·year·) &'- ' &·monthCanonicalFragmentMap·(dt's ·month·) &'- ' &·dayCanonicalFragmentMap·(dt's ·day·) &'T ' &·hourCanonicalFragmentMap·(dt's ·hour·) &': ' &·minuteCanonicalFragmentMap·(dt's ·minute·) &': ' &·secondCanonicalFragmentMap·(dt's ·second·) . |
ti | : | a completetime value |
Let | T be ·hourCanonicalFragmentMap·(ti's ·hour·) &': ' &·minuteCanonicalFragmentMap·(ti's ·minute·) &': ' &·secondCanonicalFragmentMap·(ti's ·second·) . |
da | : | a completedate value |
Let | D be ·yearCanonicalFragmentMap·(da's ·year·) &'- ' &·monthCanonicalFragmentMap·(da's ·month·) &'- ' &·dayCanonicalFragmentMap·(da's ·day·) . |
ym | : | a completegYearMonth value |
Let | YM be ·yearCanonicalFragmentMap·(ym's ·year·) &'- ' &·monthCanonicalFragmentMap·(ym's ·month·) . |
gY | : | a completegYear value |
md | : | a completegMonthDay value |
Let | MD be '-- ' &·monthCanonicalFragmentMap·(md's ·month·) &'- ' &·dayCanonicalFragmentMap·(md's ·day·) . |
gD | : | a completegDay value |
---
' &·dayCanonicalFragmentMap·(gD's ·day·) &·timezoneCanonicalFragmentMap·(gD's ·timezoneOffset·) otherwise.gM | : | a completegMonth value |
--
' &·monthCanonicalFragmentMap·(gM's ·day·) &·timezoneCanonicalFragmentMap·(gM's ·timezoneOffset·) otherwise.The following functions are used with various datatypes neither numericnor date/time related.
LEX | : | a·literal· matchingbooleanRep |
true
'or '1
' , andfalse
'or '0
').b | : | aboolean value |
true
' whenb istrue, andfalse
' otherwise (b isfalse).The·lexical mapping· forhexBinarymaps each pair of hexadecimal digits to an octet, in the conventional way:
Let | o be the sequence of octets formed by applying·hexOctetMap· to eachhexOctet inLEX, in order, and concatenating the results. |
The auxiliary functions·hexOctetMap· and·hexDigitMap· are used by·hexBinaryMap·.
Let | d0 be the first hexadecimal digit inLEX.Letd1 be the second hexadecimal digit inLEX. |
d | : | a hexadecimal digit |
0
',1
',2
',3
',E
' or 'e
',F
' or 'f
'.The·canonical mapping· forhexBinary uses only theuppercase forms of A-F.
o | : | ahexBinary value |
Let | h be the sequence of literals formed by applying·hexOctetCanonical· to each octet ino, in order, and concatenating the results. |
o | : | a binary octet |
Let | lo be the four low-order bits ofo,andhi be the four high-order bits. |
d | : | a sequence of four binary digits |
0
' whend = 0000,1
' whend = 0001,2
' whend = 0010,3
' whend = 0011,E
' whend = 1110,F
' whend = 1111.The following table shows the values of the fundamental facetsfor each·built-in· datatype.
Datatype | ordered | bounded | cardinality | numeric | ||
---|---|---|---|---|---|---|
primitive | string | false | false | countably infinite | false | |
boolean | false | false | finite | false | ||
float | partial | true | finite | true | ||
double | partial | true | finite | true | ||
decimal | total | false | countably infinite | true | ||
duration | partial | false | countably infinite | false | ||
dateTime | partial | false | countably infinite | false | ||
time | partial | false | countably infinite | false | ||
date | partial | false | countably infinite | false | ||
gYearMonth | partial | false | countably infinite | false | ||
gYear | partial | false | countably infinite | false | ||
gMonthDay | partial | false | countably infinite | false | ||
gDay | partial | false | countably infinite | false | ||
gMonth | partial | false | countably infinite | false | ||
hexBinary | false | false | countably infinite | false | ||
base64Binary | false | false | countably infinite | false | ||
anyURI | false | false | countably infinite | false | ||
QName | false | false | countably infinite | false | ||
NOTATION | false | false | countably infinite | false | ||
non-primitive | normalizedString | false | false | countably infinite | false | |
token | false | false | countably infinite | false | ||
language | false | false | countably infinite | false | ||
IDREFS | false | false | countably infinite | false | ||
ENTITIES | false | false | countably infinite | false | ||
NMTOKEN | false | false | countably infinite | false | ||
NMTOKENS | false | false | countably infinite | false | ||
Name | false | false | countably infinite | false | ||
NCName | false | false | countably infinite | false | ||
ID | false | false | countably infinite | false | ||
IDREF | false | false | countably infinite | false | ||
ENTITY | false | false | countably infinite | false | ||
integer | total | false | countably infinite | true | ||
nonPositiveInteger | total | false | countably infinite | true | ||
negativeInteger | total | false | countably infinite | true | ||
long | total | true | finite | true | ||
int | total | true | finite | true | ||
short | total | true | finite | true | ||
byte | total | true | finite | true | ||
nonNegativeInteger | total | false | countably infinite | true | ||
unsignedLong | total | true | finite | true | ||
unsignedInt | total | true | finite | true | ||
unsignedShort | total | true | finite | true | ||
unsignedByte | total | true | finite | true | ||
positiveInteger | total | false | countably infinite | true | ||
yearMonthDuration | partial | false | countably infinite | false | ||
dayTimeDuration | partial | false | countably infinite | false | ||
dateTimeStamp | partial | false | countably infinite | false |
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.
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>
where'
^A.*Z$
^
'anchors the pattern at the head and'$
'anchors at the tail..*
'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>
[Definition:] Aregular expression is composed from zero or more·branches·,separated by'|
'characters.
|
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 |
S | all strings inL(S) |
S | T | all strings inL(S)and all strings inL(T) |
[Definition:] Abranch consists of zero or more·pieces·,concatenated together.
|
For all·pieces·S, and for all·branches·T, valid·branches·R are: | Denoting the set of stringsL(R)containing: |
---|---|
S | all strings inL(S) |
ST | all stringsstwiths inL(S)andtinL(T) |
[Definition:] Apiece is an·atom·, possibly followed by a·quantifier·.
|
For all·atoms·S and non-negativeintegersn,msuch thatn≤m, valid·pieces·R are: | Denoting the set of stringsL(R)containing: |
---|---|
S | all 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 |
{,
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.
|
[Definition:] Anatom is either a·normal character·, a·character class·, ora parenthesized·regular expression·.
|
For all·normalcharacters·c,·characterclasses·C, and·regularexpressions·S, valid·atoms·R are: | Denoting the set of stringsL(R)containing: |
---|---|
c | the single string consisting only ofc |
C | all strings inL(C) |
( S ) | L(S) |
[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.
|
[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).
|
A character class is either a·single-character escape· ora·character class escape· or a·character class expression· ora·wildcard character·.
[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).
|
[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.
|
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 '^
'.
[^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.[^]
'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·C, G -
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·.
|
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: |
---|---|
R | all characters inC(R) |
E | all characters inC(E) |
RP | all characters inC(R)and all characters inC(P) |
EP | all 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).
|
[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).
|
[
',then the hyphen is not part of thecharGroupPart:instead, it is recognized as a character-class subtraction operator.]
',then the hyphen is recognized as asingleChar andis part of thecharGroupPart.-[
',then the hyphen is recognized as asingleChar andis part of thecharGroupPart.[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.
|
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.
|
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)).
[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·).
|
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·.
|
The valid·singlecharacter escapes·R are: | Identifying the set of characterscontaining: |
---|---|
\n | the newline character (#xA) |
\r | the return character (#xD) |
\t | the tab character (#x9) |
\\ | \ |
\| | | |
\. | . |
\- | - |
\^ | ^ |
\? | ? |
\* | * |
\+ | + |
\{ | { |
\} | } |
\( | ( |
\) | ) |
\[ | [ |
\] | ] |
[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}]
.
|
[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.
PropertyAliases.txt
andPropertyValueAliases.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
.
Cn
in its definition ofC
, so that definition cannot be used without modificationin conformant implementations.Category | Property | Meaning |
---|---|---|
Letters | L | All Letters |
Lu | uppercase | |
Ll | lowercase | |
Lt | titlecase | |
Lm | modifier | |
Lo | other | |
Marks | M | All Marks |
Mn | nonspacing | |
Mc | spacing combining | |
Me | enclosing | |
Numbers | N | All Numbers |
Nd | decimal digit | |
Nl | letter | |
No | other | |
Punctuation | P | All Punctuation |
Pc | connector | |
Pd | dash | |
Ps | open | |
Pe | close | |
Pi | initial quote(may behave like Ps or Pe depending on usage) | |
Pf | final quote(may behave like Ps or Pe depending on usage) | |
Po | other | |
Separators | Z | All Separators |
Zs | space | |
Zl | line | |
Zp | paragraph | |
Symbols | S | All Symbols |
Sm | math | |
Sc | currency | |
Sk | modifier | |
So | other | |
Other | C | All Others |
Cc | control | |
Cf | format | |
Co | private use | |
Cn | not assigned |
|
[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{Is
X}]
=[^\p{Is
X}]
.
|
·block escape·\p{IsBasicLatin}
BasicLatin
' and the string '-- basic LATIN --
' will match the block name "Basic Latin".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.
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).
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.
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.
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.
.|[\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.[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:
|
Character sequence | Equivalent·character class· |
---|---|
. | [^\n\r] |
\s | [#x20\t\n\r] |
\S | [^\s] |
\i | the set of initial name characters, those·matched· byNameStartChar in[XML] |
\I | [^\i] |
\c | the 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] |
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.
xs:facet
astheir substitution-group head.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.
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.
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.
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.
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.
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.
xs:anySimpleType
· or·xs:anyAtomicType
· thenX isV,and thedynamictype ofX isxs:untypedAtomic
.|
'characters.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.