W3C

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

W3C Recommendation 20 October 2012

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

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

See also translations.

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.


...

Status of this Document

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

This is a member-only document for internal review, which will in due course be published as a W3C Recommendation specifying W3C Recommendation specifies the W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. It has no formal standing within W3C; it is here made available for review by W3C members and the public. This version of this document was created on 20 October 2012. It reflects (unless otherwise noted elsewhere) all decisions on this document made by the Working Group through 23 March 2012. The document thus incorporates all decisions made by the Working Group to date. Some additional changes made in preparation for publishing the final Recommendation are shown in color in the status-quo version of this document.

Changes since the previous public Working Draft include the following:

For those primarily interested in the changes since version 1.0, the appendix Changes since version 1.0 (§I) 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 at http://www.w3.org/XML/2006/01/public-bugzilla. If access to Bugzilla is not feasible, please send your comments to the W3C XML Schema comments mailing list, www-xml-schema-comments@w3.org (archive) 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.

Publication as a Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

An implementation report (member-accessible link) is available showing that the exit criteria specified in the Candidate Recommendation draft have been satisfied.

This document has been produced by the W3C XML Schema Working Group as part of the W3C XML Activity. The goals of the XML Schema language version 1.1 are discussed in the Requirements for XML Schema 1.1 document. The authors of this document are the members of the XML Schema Working Group. Different parts of this specification have different editors.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public 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 contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

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

The presentation of this document has been augmented to identify changes from a previous version, controlled by dg-errata-2012.xml, which shows the status-quo text without adornment. Changes which have Working Group consensus are marked thus: new, added text, changed text, and deleted text. Other changes, which do not now have Working Group consensus, are marked this way: tentative additions, changes, and deletions.


Table of Contents

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

Appendices

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

... ... ...

4 Datatype components

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

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

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

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

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

... ...

previous sub-section 4.3 Constraining Facets

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

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

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

Conforming processors must support all the facets defined in this section. It is ·implementation-defined· whether a processor supports other constraining facets. [Definition:]  An ·constraining facet· which is not supported by the processor in use is unknown.

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

The descriptions of individual facets given below include both constraints on Simple Type Definition components and rules for checking the datatype validity of a given literal against a given datatype. The validation rules typically depend upon having a full knowledge of the datatype; full knowledge of the datatype, in turn, depends on having a fully instantiated Simple Type Definition. A full instantiation of the Simple Type Definition, and the checking of the component constraints, require knowledge of the ·base type·. It follows that if a datatype's ·base type· is ·unknown·, the Simple Type Definition defining the datatype will be incompletely instantiated, 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 validation as defined here using ·unknown· datatypes.

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

4.3.14 explicitTimezone

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

Example
The following ·user-defined· datatype accepts only date values without a time zone offset, using the explicitTimezone facet.
<simpleType name='bare-date'>
  <restriction base='date'>
    <explicitTimezone value='prohibited'/>
  </restriction>
</simpleType>
The same effect could also be achieved using the pattern facet, as shown below, but it is somewhat less clear what is going on in this derivation, and it is better practice to use the more straightforward explicitTimezone for this purpose.
<simpleType name='bare-date'>
  <restriction base='date'>
    <pattern value='[^:Z]*'/>
  </restriction>
</simpleType>
4.3.14.1 The explicitTimezone Schema Component

If {fixed} is true, then datatypes for which the current type is the {base type definition} cannot specify a value for explicitTimezone other than {value}.

Note: It is a consequence of timezone valid restriction (§4.3.14.4) that the value of the explicitTimezone facet cannot be changed unless that value is optional, regardless of whether {fixed} is true or false.  Accordingly, {fixed} is relevant only when {value} is optional.
4.3.14.2 XML Representation of explicitTimezone Schema Components

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

XML Representation Summary: explicitTimezone Element Information Item
<explicitTimezone
  fixed = boolean : false
  id = ID

  value = NCName

  value = (optional | required | prohibited)

  {any attributes with non-schema namespace . . .}>
  Content: (annotation?)
</explicitTimezone>
explicitTimezone Schema Component
Property
Representation
 
The actual value of the value [attribute]
 
The actual value of the fixed [attribute], if present, otherwise false
 
4.3.14.3 explicitTimezone Validation Rules
Validation Rule: explicitOffset Valid
A dateTime value V is facet-valid with respect to ·explicitTimezone· if and only if one of the following is true
1 The {value} of the facet is required and V has a (non-absent) value for the ·timezoneOffset· property.
2 The {value} of the facet is prohibited and the value for the ·timezoneOffset· property in V is absent.
3 The {value} of the facet is optional.
4.3.14.4 Constraints on explicitTimezone Schema Components
Schema Component Constraint: timezone valid restriction
If the explicitTimezone facet on the {base type definition} has a {value} other than optional, then the {value} of the facet on the ·restriction· must be equal to the {value} on the {base type definition}; otherwise it is an ·error·.
Note: The effect of this rule is to allow datatypes with a explicitTimezone value of optional to be restricted by specifying a value of required or prohibited, and to forbid any other derivations using this facet.
...
...

B DTD for Datatype Definitions (non-normative)

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

...
<!--
        DTD for 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;
        test                     %XPathExpr; #REQUIRED
        id                       ID          #IMPLIED
        xpathDefaultNamespace    CDATA       #IMPLIED
        %assertionAttrs;>

<!ELEMENT %explicitTimezone; %facetModel;>
<!ATTLIST %explicitTimezone;
        %facetAttr;
        %explicitTimezoneAttrs;>
... ... ... ... ... ... ... ... ... ...