<?xml version='1.0'?>
<?xml-stylesheet type='text/xsl' href='dtspec.xsl'?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification::19990205//EN" "xmlspec-19990429.dtd" [
 <!ENTITY cellback '#d0d9fa'>

 <!ENTITY xmlspec "http://www.w3.org/TR/2000/WD-xml-2e-20000814">
 <!ENTITY xmlnsspec "http://www.w3.org/TR/REC-xml-names/">
 <!ENTITY xsdl "http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/">

 <!ENTITY schemaWG "<loc href='http://www.w3.org/XML/Activity#schema-wg'>W3C XML Schema Working Group</loc>">

 <!ENTITY year "2000">
 <!ENTITY mm "10">
 <!ENTITY MM "October">
 <!ENTITY dd "24">
 <!ENTITY MMDD "&mm;&dd;">
 <!ENTITY iso.doc.date "&year;&MMDD;">

 <!ENTITY schema-language "XML Schema definition language">
 
 <!ENTITY thisversion "http://www.w3.org/TR/2000/CR-xmlschema/">
 <!ENTITY order "&#163;">
 <!ENTITY le "&#8804;"> <!-- less than or equal to, U+2264 ISOtech -->
 <!ENTITY ne "&#8800;"> <!-- not equal to, U+2260 ISOtech -->
 <!ENTITY infin "&#8734;"> <!-- infinity, U+221E ISOtech -->
 <!ENTITY times "&#215;"> <!-- multiplication, U+00D7 -->
 <!ENTITY sect   "&#xa7;">
 <!ENTITY eacute "&#xe9;">

<!-- we'll see if anyone has a sense of humor -->
<!-- note: I tried to do this with conditional sections,
     but XT seems to get confused and reports a syntax error -->
<!ENTITY % sense-of-humor "INCLUDE">
<!ENTITY % no-sense-of-humor "IGNORE">
<!--
<![%sense-of-humor[
 <!ENTITY long "Homer">
 <!ENTITY int "Sideshow-Bob">
 <!ENTITY short "Bart">
 <!ENTITY byte "Troy-McClure">
 <!ENTITY unsignedLong "Apu-Nahasapeemapetilon">
 <!ENTITY unsignedInt "Chief-Wiggums">
 <!ENTITY unsignedShort "Mr-Burns">
 <!ENTITY unsignedByte "Krusty-the-Clown">
-->
<!--
 ]]>
<![%no-sense-of-humor[
-->
 <!ENTITY long "long">
 <!ENTITY int "int">
 <!ENTITY short "short">
 <!ENTITY byte "byte">
 <!ENTITY unsignedLong "unsignedLong">
 <!ENTITY unsignedInt "unsignedInt">
 <!ENTITY unsignedShort "unsignedShort">
 <!ENTITY unsignedByte "unsignedByte">
<!--
 ]]> 
-->

 <!ATTLIST eg text CDATA #IMPLIED> <!-- experimental pointer to out-of-line
                                        example text -->

   <!ELEMENT propdef ANY> <!-- best we can do without editing xml-spec -->
   <!ATTLIST propdef id ID #REQUIRED
                     name CDATA #REQUIRED>
   <!ELEMENT propref EMPTY>
   <!ATTLIST propref ref IDREF #REQUIRED>
   <!ELEMENT xpropref (#PCDATA)>
   <!ATTLIST xpropref href CDATA #IMPLIED>
   <!ELEMENT compdef (proplist)>
   <!ATTLIST compdef name CDATA #REQUIRED
                     ref IDREF #REQUIRED>
   
   <!ELEMENT compref EMPTY>
   <!ATTLIST compref ref IDREF #REQUIRED>

   <!ELEMENT proplist (propdef*)>
   <!ELEMENT reprdef (reprelt*,reprcomp*)>
   <!ATTLIST reprdef eltname NMTOKENS #REQUIRED
                     local NMTOKEN #IMPLIED>
   <!ELEMENT reprelt EMPTY>
   <!ATTLIST reprelt eltname NMTOKENS #REQUIRED
                     type NMTOKEN #IMPLIED>
   <!ELEMENT reprcomp (reprdep?,propmap*)>
   <!ATTLIST reprcomp ref IDREF #REQUIRED
                      abstract CDATA #REQUIRED>
   <!ELEMENT reprdep ANY> <!-- best we can do without editing xml-spec -->
    <!ELEMENT propmap ANY> <!-- best we can do without editing xml-spec -->
   <!ATTLIST propmap name IDREF #REQUIRED>
   <!ELEMENT eltref EMPTY>
   <!ATTLIST eltref ref NMTOKEN #REQUIRED>
   <!ELEMENT stale ANY>
   <!ELEMENT dtref EMPTY>
   <!ATTLIST dtref ref NMTOKEN #REQUIRED>   
   <!ELEMENT baseref EMPTY>
   <!ELEMENT itemTyperef EMPTY>
   <!ELEMENT fundamental-facets EMPTY>
   
   <!ENTITY % local.p.class "|stale|facets|subtypes|
   		inverse-facets|open-issues|revisions|fundamental-facets|applicable-facets">
   <!ENTITY % local.termdef.class "|propdef">
   <!ENTITY % local.ref.class "|propref|xpropref|eltref|compref|dtref|baseref|itemTyperef">
   <!ENTITY % local.illus.class "|compdef|reprdef|proplist">
   
   <!ENTITY i-attribute "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>attribute</xpropref>">
   <!ENTITY i-children "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>children</xpropref>">
   <!ENTITY i-child "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>child</xpropref>">
   <!ENTITY i-attributes "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>attributes</xpropref>">
   <!ENTITY i-attrChildren "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>children</xpropref>">
   <!ENTITY i-value "&nbsp;<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>value</xpropref>">
   <!ENTITY i-ccode "&nbsp;<xpropref
href='http://www.w3.org/TR/xml-infoset#infoitem.character'>character code</xpropref>">

	<!ELEMENT applicable-facets EMPTY>
	<!ELEMENT facets EMPTY>
	<!ELEMENT subtypes EMPTY>
	<!ELEMENT inverse-facets EMPTY>
	<!ATTLIST inverse-facets
		name CDATA #REQUIRED>
	<!ELEMENT open-issues EMPTY>
	<!ELEMENT revisions EMPTY>
	
	<!ATTLIST table
		align CDATA #IMPLIED
		bgcolor CDATA #IMPLIED>
	]>
<spec>
<header>
<title>XML Schema Part 2: Datatypes</title>

<version></version>
    <w3c-designation>datatypes-&iso.doc.date;</w3c-designation>
    <w3c-doctype>W3C Candidate Recommendation</w3c-doctype>
<pubdate><day>&dd;</day><month>&MM;</month><year>&year;<!--
Point release id: <code>Id: datatypes.xml,v 1.52 2000/10/24 12:03:29 ht Exp </code>--></year></pubdate>
<notice role="publoc">
<p>
(in <loc href="http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/datatypes.xml">XML</loc> and
<loc href="http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/datatypes.html">HTML</loc>,	with a
<loc href="http://www.w3.org/2000/10/XMLSchema.xsd">schema</loc> and
<loc href="http://www.w3.org/2000/10/XMLSchema.dtd">DTD</loc> including datatype definitions,
as well as a <loc href="http://www.w3.org/2000/10/XMLSchema-datatypes.xsd">schema</loc>
for built-in datatypes only, in a separate namespace.)
</p>
</notice>
<publoc>
<loc href="http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/">http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/</loc>
</publoc>
<prevlocs>
	<loc href="http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/">
		http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/
	</loc>
</prevlocs>
<latestloc>
	<loc href="http://www.w3.org/TR/xmlschema-2/">
		http://www.w3.org/TR/xmlschema-2/
	</loc>
</latestloc>
<authlist>
<author>
<name>Paul V. Biron</name>
<affiliation>Kaiser Permanente, for Health Level Seven</affiliation>
<email href="mailto:Paul.V.Biron@kp.org">Paul.V.Biron@kp.org</email>
</author>
<author>
<name>Ashok Malhotra</name>
<affiliation>IBM</affiliation>
<email href="mailto:petsa@us.ibm.com">petsa@us.ibm.com</email>
</author>
</authlist>
    <status>
<p>This specification of the XML Schema language is a Candidate
Recommendation of the World Wide Web Consortium.  This means that the <loc href="http://www.w3.org/XML/Activity#schema-wg">XML 
Schema Working Group</loc>considers the specification to
be stable and encourages implementation and comment on the
specification during this period. The Candidate Recommendation review
period ends on 15 December 2000. Please send review comments before
the review period ends to <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> (<loc href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">public mailing list archive</loc>).</p>
     <p>During the Candidate Recommendation phase, although feedback based on
any aspect of implementation experience is welcome, there are certain aspects of the
design presented herein for which the Working Group is particularly
interested in feedback. These are designated <emph>priority feedback</emph> aspects
of the design, and identified as such in editorial notes throughout
this draft.</p>
     <p>Should this specification prove very difficult or impossible to
implement, the Working Group will return the document to Working Draft
status and make necessary changes. Otherwise, the Working Group
anticipates asking the W3C Director to advance this document to
Proposed Recommendation.</p>
     <p>This document has been produced as part of the W3C <loc href="http://www.w3.org/XML/">XML Activity</loc>. The
authors of this document are the XML Schema WG members. Different
parts of this specification have different editors.</p>
      <p>A list of current W3C working drafts can be found at
        <loc href="http://www.w3.org/TR/">http://www.w3.org/TR/</loc>. They may be
        updated, replaced, or obsoleted by other documents at any time. It is
        inappropriate to use W3C Working Drafts as reference material or to cite them
        as other than "work in progress". </p>
<p>
Several "note types" are used throughout this draft:
</p>
<glist>
<gitem><label>issue [Issue (issue-name): ]</label>
<def>
<p>something on which the editors are seeking comment.</p>
</def>
</gitem>
<gitem><label>editorial note [Ed. Note: ]</label>
<def>
<p>
something the editors wish to call to the attention of the
reader. To be removed prior to the recommendation becoming final.
</p>
</def>
</gitem>
<gitem><label>note [Note: ]</label>
<def>
<p>
something the editors wish to call to the attention of the reader.
To remain in the final recommendation as non-normative text.
</p>
</def>
</gitem>
</glist>
</status>
<abstract>
<p>
<emph>XML Schema: Datatypes</emph> is part 2 of the specification of the XML    
Schema language. It defines facilities for defining datatypes to be used
specifications.  The datatype language, which is itself represented in
XML 1.0, provides a superset of the capabilities found in XML 1.0
document type definitions (DTDs) for specifying datatypes on elements
and attributes.
</p>
</abstract>
<langusage>
<language id="EN">English</language>
</langusage>
<revisiondesc>
<slist>
<!--
     commenting these out means only that they won't show up in the
	 stylesheet generated "Revisions from previous draft" appendix
  -->
<!-- Changes before Sept public draft commented out...
<sitem>
19990521: PVB: corrected definition of length and maxLengths facet for strings to
be in terms of <emph>characters</emph> not <emph>bytes</emph>
</sitem>
<sitem>
19990521: PVB: removed issue "other-date-representations".  We don't
want other separators, left mention of aggregate reps for dates as
an ednote.
</sitem>
<sitem>
19990521: PVB: fixed "holidays" example, "-0101" ==> "==0101"
(where == in the correction should be two hyphens, but that would
not allow us to comment out this sitem)
</sitem>
<sitem>
19990521: PVB: fixed "common date" example, lexicalRepresenation ==> lexicalRepresentation
</sitem>
<sitem>
19990521: PVB: added note that -YY-MM-DD style dates are deprecated
</sitem>
<sitem>
19990521: PVB: added termdef element around definition of subtype
</sitem>
<sitem>
19990521: PVB: removed "whose basetype is a built-in" from definition of
"user-generated" datatype
</sitem>
<sitem>
19990521: PVB: clarified that the length facet for binary datatype is
length in bytes
</sitem>
<sitem>
19990521: PVB: fixed weird spacing problems introduced by ArborText
</sitem>
<sitem>
19990521: PVB: fixed references to non-terminals in productions
</sitem>
<sitem>
19990524: AM: changed "boolean" to have a single lexical representation.
</sitem>
<sitem>
19990524: AM: added issue: "should we add a facet to restrict a binary
datatype to a user-defined format such as audio, image, etc."
</sitem>
<sitem>
19990524: AM: corrected reference to SQL standard.
</sitem>
<sitem>
19990524: AM: corrected definition of length and maximum length
facets to be a positive integer.
</sitem>
<sitem>
19990524: AM: corrected default format for integer, decimal and real.
</sitem>
<sitem>
19990524: AM: rewrote issue definition-overiding.
</sitem>
<sitem>
19990524: AM: edited Conformance section to add example of lexical
errors and fix reference to above issue.
</sitem>
<sitem>
19990601: PVB: changed date formats in examples of Section 1 to be conformant
with the date datatype
</sitem>
<sitem>
19990601: PVB: added a "for compatibility" terminology entry
</sitem>
<sitem>
19990601: PVB: added a Name datatype and redefined the XML 1.0 attribute types
in terms of it
</sitem>
<sitem>
19990601: PVB: remove "for attributes only" restriction on XML 1.0  attribute types.
Added a "for compatibility" clause for attribute values.
</sitem>
<sitem>
19990601: PVB: added language datatype
</sitem>
<sitem>
19990602: PVB: added uuid datatype
</sitem>
<sitem>
19990602: PVB: added NCName datatype
</sitem>
<sitem>
19990604: AM: changed date and time formats to allow only ISO 8601
extended format. Impacted sections on the date, time datatypes,
section 4, Appendix C.
</sitem>
<sitem>
19990604: AM: added ednote to string datatype saying we need to harmonize
with I18N character model.
</sitem>
<sitem>
19990604: PVB: added "Revisions from previous draft" appendix
</sitem>
<sitem>
19990604: PVB: moved "built-in generated" datatype definitions into the
schema for datatype definitions (instead of it being in its own appendix).
</sitem>
<sitem>
19990604: PVB: upadted the schema for datatype definitions to point to
the correct (per xmlschema-1) DTD and schema
</sitem>
<sitem>
19990623: AM: added paragraph to conformance section which begins
to be more precise about how conforming processors should behave
</sitem>
<sitem>
19990623: AM: removed confusing statement from conformance section
which said that " checking for lexical conformance is all that is
expected of an XML processor."
</sitem>
<sitem>
19990623: PVB: removed section on "Characterizing Operations" and
all references to it (or its content) in the rest of the draft.
</sitem>
<sitem>
19990623: PVB: removed uuid datatype
</sitem>
<sitem>
19990623: PVB: made NMTOKEN a primitive datatype and Name a
subtype of NMTOKEN.
</sitem>
<sitem>
19990623: PVB: corrected the basetypes of following XML-related
generated datatypes: IDREFS (from ID to IDREF), ENTITY (from ID to Name),
ENTITIES (from ID to ENTITY), NMTOKENS (from Name to NMTOKEN).
</sitem>
<sitem>
19990623: PVB: changed name of section "User-Generated Datatypes" to
the more correct "Defining Generated Datatypes".  Also added some
explanatory text to the beginning of that section which explains
that the abstract syntax there is used both for defining built-in
and user-generated datatypes.
</sitem>
<sitem>
19990623: PVB: added explanations of abstract and concrete
syntax (mostly borrowed from the structural draft) to section
"Defining Generated Datatypes".
</sitem>
<sitem>
19990623: PVB: separated references into those that are normative
and those that are non-normative
</sitem>
<sitem>
19990623: PVB: added a pointer to the draft revision of ISO 8601
in its bib entry
</sitem>
<sitem>
19990623: PVB: added "no-consensus" issues to those all sections
except "Type System" and "Built-in datatypes" stating that no WG
consensus has been reached on the section (the exclusions above
are because those sections which granted consensus status at the
Ann Arbor f2f)
</sitem>
<sitem>
19990623: PVB: cleaned up productions for numeric literals
</sitem>
<sitem>
19990624: PVB: excluded subsections 1.1 and 1.2 from the "no-consusus"
issue for section 1
</sitem>
<sitem>
19990630: PVB: removed number datatype, made real into a built-in
primitive, changed the basetype of decimal to real and the basetype
of integer to decimal.  Also added NaN, INF and -INF to the lexical
space of all numeric types.
</sitem>
<sitem>
19990630: PVB: added 2 new subtypes of integer: nonPositiveInteger
and nonNegativeInteger, each of which has 1 subtype: negativeInteger
and positiveInteger, respectively.  Added generated datatype definitions
for these to the schema for datatypes.
</sitem>
<sitem>
19990630: PVB: fixed typos in definition of IDREF and IDREFS
(was "the lexical space of ID is .." now "the lexical space of IDREF is ...")
</sitem>
<sitem>
19990630: PVB: added issue(nonNegativeInteger-literals)
</sitem>
<sitem>
19990630: PVB: added links to known subtypes in all datatype
descriptions
</sitem>
<sitem>
19990630: PVB: changed "no-consensus" issues to "no-consensus"
ednotes
</sitem>
<sitem>
19990630: PVB: changed "no-consensus" ednote for section 1 to
exclude subsection 1.3, as voted on during the telcon today
</sitem>
<sitem>
19990630: PVB: corrected several interal cross-references: from termref's
to specref's
</sitem>
<sitem>
19990630: PVB: added all previous drafts (internal as well as public WDs)
to the "Previous Versions" section.  In future public WDs only those
"previous versions" which were public WDs will display
</sitem>
<sitem>
19990630: PVB: changed "collection" to "set" in definition of "value space"
(thought this had been changed long ago, sorry)
</sitem>
<sitem>
19990708: PVB: removed section 1.5 "Organization", per WG vote on telcon
</sitem>
<sitem>
19990708: PVB: removed "no-consensus" ednote from section 1
</sitem>
<sitem>
19990709: PVB: added (stub) subsections on "Precision", "Scale" and "Encoding" to
section 2.4.2 "Constraining Facets".  All facets mentioned in all datatype
definitions in section 3 should be listed in 2.4.2. (this is not intended to address
the standing issue <xspecref href='http://www.w3.org/XML/Group/xmlschema-current/issues.html#constraining-facet-definitions'>
constraining-facet-definitions</xspecref>, but was needed for the next revision item)
</sitem>
<sitem>
19990709: PVB: added "Datatypes and Facets" appendix which consists of
several tables which attempt to show which facets apply to which datatypes
</sitem>
<sitem>
19990713: PVB: fixed bug in schema for datatypes regarding modelGroup vs.
elementType Refs in unordered modelGroup
as per
<loc href='http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999AprJun/0088.html'>
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999AprJun/0088.html</loc>
</sitem>
<sitem>
19990726: AM: Changed example of user-generated datatype from
heightInInches to i4.
</sitem>
<sitem>
19990726: AM: Rewrote "Exact and Approximate".
</sitem>
<sitem>
19990812: PVB: Removed all mention of picture constraints as lexical-representations
for strings
</sitem>
<sitem>
19990819: AM: Amended Ed. Note on a URL for the datatypes namespace
referring to Dan Connolly's note "make up your own".
</sitem>
<sitem>
19990819: AM: Removed issue on NULLS, 2 occurrences.
</sitem>
<sitem>
19990819: AM: Changed Ed. Note on "Better Ref Mechs" associated with
IDREFS to "issue"..
</sitem>
<sitem>
19990819: AM: Removed issue on measurement units as WG decided to
defer to version 2.
</sitem>
<sitem>
19990919: HT: modifed abstract syntax to better reflect intent?
</sitem>
<sitem>
19990923: HT: modified schema for schemas to conform to the concrete
syntax in the latest Structures draft
</sitem>
<sitem>
19990923: PVB: added minAbsoluteValue and maxAbsoluteValue facets to
real, their intent is to allow generation of subtypes of real whose
value spaces correspond to comment float-point representations.
Added examples to section 4 to show how to generate IEEE 32-bit, etc.
</sitem>
<sitem>
19990923: PVB: replaced dateTime, date, time and timePeriod with all
new date/time related types: timeInstant, recurringInstant,
date and time.  Additionally, limited the lexical representations of each
of the new types to a single form (w/ the exception of still allowing both
left truncation and reduced [i.e., right truncated] representations).
Changed all examples which used date/time to use the new lexical representation
</sitem>
<sitem>
19990923: PVB: modified the abstract syntax, schema for datatypes and DTD
for datatypes to bring them in line with above changes.
</sitem>
<sitem>
19990924: HST: link housekeeping before publication</sitem>
<sitem>
19991020: AM: Rewrote "NOTATION".
</sitem>
<sitem>
19991020: AM: Made NMTOKEN a subtype of string.
</sitem>
<sitem>
19991020: AM: Changed lex reps for all date and time datatypes to ISO
extended format i.e. with separators.
</sitem>
<sitem>
19991020: AM: Removed issue on non-Gregorian dates.
</sitem>
<sitem>
19991020: AM: Renamed "lexical representation" facet for string to "pattern".
</sitem>
 <sitem>
19991026: AM: Added appendix discussing ISO 8601 formats.  Removed note
asking for such explanation.
</sitem>
<sitem>
1999-10-26: PVB: fixed errors in datatypes.xsd and datatypes.dtd as pointed
out by <loc href='http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999JulSep/0050.html'>
Curt Arnold</loc>
</sitem>
<sitem>
1999-10-26: PVB: added period to the facets production
</sitem>
<sitem>
1999-10-26: PVB: added a note on the basetype to the definition of
datatype NMTOKEN
</sitem>
<sitem>
1999-10-26: PVB: removed NaN, INF and -INF from the lexical space
of integer and decimal
</sitem>
<sitem>
1999-11-08: PVB: removed real datatype and all references to it
</sitem>
<sitem>
1999-11-08: PVB: added inital definitions for float and double datatypes.
This initial definition is not intended to be complete, we need a more
complete description of the round-to-nearest behavior of mapping literals
into the value space (i.e., a more readable description of "best approximation"
from the Clinger paper in the non-normative references section).
</sitem>
<sitem>
1999-11-08: PVB: corrected typos in the definitions of datatypes generated
from integer to corrected identify the generated type
</sitem>
<sitem>
1999-11-08: PVB: added specref elements to all mentions of constraining facets
</sitem>
<sitem>
1999-11-08: PVB: added term elements to all mentions of a datatype name in
the definition of that datatype
</sitem>
<sitem>
1999-11-12: PVB: changed lexical space of timeInstant to be more consistent
with ISO 8601, nYnMnDTnHnMnS (minus the 'P' designator).
</sitem>
<sitem>
1999-11-12: PVB fixed productions for decimalLiteral to allow forms such as
-.12 and -23.
</sitem>
<sitem>
19991122: AM: Added some more explanation to timeInstant format.  Fixed
Appendix D to reflect changes.
</sitem>
<sitem>
19991122: AM: Added "uncountable infinite and exact" value space to 2.4.1.3
</sitem>
<sitem>
19991122: AM: Removed issue "Better Reference Mechanisms".
</sitem>
<sitem>
19991122: AM: Added "collation sequence for strings is Unicode characater number".
</sitem>
<sitem>
19991122: AM: Added min/max facets to date/time datatypes.
</sitem>
<sitem>
19991122: AM: Removed issues on URI and binary datatypes.
</sitem>
<sitem>
19991122: AM: Added value space validation to conformance section.
</sitem>
<sitem>
19991122: AM: Added values space definitions to date/time datatypes.
</sitem>
<sitem>
1999-12-08: pvb: Added QName datatype
</sitem>
<sitem>
1999-12-08: pvb: changed language to be a subtype of string
</sitem>
<sitem>
1999-12-10: pvb: many small editorial changes for consistency
</sitem>
<sitem>
1999-12-10: pvb: Added pattern facet to all date/time types (should
have been there all along)
</sitem>
<sitem>
1999-12-10: pvb: Added full list of facets and subtypes to each type
definition
</sitem>
<sitem>
1999-12-10: pvb: replaced regex appendix with a brief summary of proposed
Unicode support, complete proposal coming shortly
</sitem>
<sitem>
1999-12-10: pvb: moved some references from normative to non-normative
</sitem>
<sitem>
1999-12-10: pvb: changed concrete syntax for datatype defns to more closely
match the structures draft: in particular, to allow annotations on the
datatype element and all facet elements.
</sitem>
<sitem>
1999-12-15: pvb: added normaitive reference to RTC 2045 for def of base64
</sitem>
<sitem>
1999-12-15: pvb: many more small editorial changes, for consistency in
style and presentation
</sitem>
<sitem>
1999-12-15: pvb: corrected small errors in table in appendix C.1, Fundamental
facets
</sitem>
<sitem>
1999-12-15: pvb: filled out list of datatypes for each facet in appendix C.2,
Constraining facets
</sitem>
<sitem>
1999-12-15: expanded abstract
</sitem>
<sitem>
1999-12-15: pvb: updated description of lexical space for float/double to
include literals for +- inf, +- 0, nan.
</sitem>
<sitem>
1999-12-16: pvb: modified defns of ID, IDREF, IDREFS, ENTITY, ENTITIES
and NOTATION to match NCName instead of Name as required by the Namespaces
in XML spec
</sitem>
<sitem>
1999-12-16: pvb: fully specified value space for decimal
</sitem>
<sitem>
2000-02-08: pvb: spell check
</sitem>
<sitem>
2000-02-08: pvb: added COS's for interaction between min/max-X facets
</sitem>
<sitem>
2000-02-08: pvb: changed datatype of length, min/maxLength facets from
positiveInteger to nonNegativeInteger
</sitem>
<sitem>
2000-02-08: pvb: corrected typo in date-lexical-representaion, where a
"specific century" was noted as YY (changed to CC)
</sitem>
<sitem>
2000-02-08: pvb: changed defn of atomic from being "intrinsically indivisible"
to "regarded as indivisible by this specification"
</sitem>
<sitem>
2000-02-08: pvb: clarified defn of facet, wrt value spaces and not "concepts
or objects"
</sitem>
<sitem>
2000-02-08: pvb: merged "terminology" sections from both part 1 and part 2
</sitem>
<sitem>
2000-02-08: pvb: fixed datatype of scale facet (from pos-int to non-neg-int)
</sitem>
<sitem>
2000-02-08: pvb: added "priority feedback note" for bigNums
</sitem>
<sitem>
2000-02-09: pvb: fixed circular defn of decimal, as suggested 
by DC
-->
<!--
<loc href='http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2000Jan/0365.html'>
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2000Jan/0365.html</loc>
-->
<!--
</sitem>
<sitem>
2000-02-09: pvb: added 1 and 0 to lexical space of boolean
</sitem>
<sitem>
2000-02-09: pvb: added subsections to section 4...this may get undone when I
dump the abstract syntax, we'll see
</sitem>
<sitem>
2000-02-10: pvb: added pattern facet to all datatypes
</sitem>
<sitem>
2000-02-10: pvb: updated several incorrect values in the constraining
facets "table" in Appendix C2.
</sitem>
<sitem>
2000-02-10: pvb: changed examples to use &lt;documentation> instead
of &lt;info> as the child of &lt;annotation>
</sitem>
<sitem>
2000-02-10: pvb: added the correct built-in datatypes namespace to
section 3.1 (closes the datatypes portion of issue 78)
</sitem>
<sitem>
2000-02-10: pvb: changed examples to use &lt;simpleType> instead of
&lt;datatype>, equivalent changes to the DTD and schema will come shortly
closes the datatypes portion of issue 157)
</sitem>
<sitem>
2000-02-10 : pvb: renamed uri datatype to uriReference; clarified the
defn wrt RFC 2396; included specific mention of absolute vs. relative
uriReferences; still need to be specific about the lexical representation
(closes some parts of issue 212)
</sitem>
<sitem>
2000-02-15: pvb: added SVC to binary, which says one must give a value for
the encoding facet (i.e., a hack to get around the problem that we don't
have the concept of "required" facets) [part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved ID to a primitive type (since it has validation requirements
above and beyond those provided for subtypes of string).  Also added a Note: to it
making explicit the fact that the value space is scoped to an instance document
(unlike the value space of types such as integer).  Also fixed a bug in the
definition, which referred to Name instead of NCName
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved IDREF to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Added an issue about whether this could be generated from ID.
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved IDREFS to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string)....this is
just a temporary home and it will become generated as list of IDREF when I get
the list stuff implemented
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved ENTITY to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
Also added a SVC that entity values must match a declared unparsed entity name.
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved ENTITIES to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string)....this is
just a temporary home and it will become generated as list of ENTITY when I get
the list stuff implemented
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved NOTATION to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
Also added a SVC that notation values must match a declared notation name.
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: updated table in appendix C1, to note that all datatypes
are exact
</sitem>
<sitem>
2000-02-16: pvb: added i4, i8, u4, u8, etc. subtypes of integer, using
editor's discretion in their naming as instructed at the berkeley f2f...changed the
first example in section 4 "Defining Generated Datatypes" to use the Sku
datatype from Part 0, instead of i4 since we now have i4 built-in
</sitem>
<sitem>
2000-02-16: pvb: removed issue: definition-overriding from the draft
</sitem>
<sitem>
2000-02-17: pvb: removed the exact vs. approximate distinction entirely
(since all our types turned out to be exact)
</sitem>
<sitem>
2000-02-17: pvb: removed all mention of aggregate datatypes.  Changed
the "atomic vs. aggregate" dichotomy to be: atomic vs. list.
[part of resolution to issue 112]
</sitem>
<sitem>
2000-02-17: pvb: clarified defns of value space and lexical space.  In
particular, moved the notion of a literal denoting a value from the defn
to LS to VS and noted that a literal is a character information item from
the info set.
</sitem>
<sitem>
2000-02-17: pvb: changed terminology of "generated" to "derived", to be
in alignment with the structures spec
[part of resolution to issue 204]
</sitem>
<sitem>
2000-02-17: pvb: removed definition of term subtype, changed all prose of the
form "for subtypes of X" to "for datatypes derived from X"
[part of resolution to issue 204]
</sitem>
<sitem>
2000-02-17: pvb: removed a para from Conformance section which mentioned
processor option of turning off validation of certain facets
</sitem>
<sitem>
2000-02-17: pvb: removed note that order-relations are not defined
</sitem>
<sitem>
2000-02-17: pvb: made IDREFS, ENTITIES and NMTOKENS derived by list from
IDREF, ENTITY and NMTOKENS respectively.
[part of resolution of issue 81]
</sitem>
<sitem>
2000-02-17: pvb: clarified what the values {hex,base64} mean for the
encoding facet
</sitem>
<sitem>
2000-02-17: pvb: added pointers from the 4 mechanisms to create a value space
to the places in the spec where those mechanisms are described
</sitem>
<sitem>
2000-02-17: pvb: all built-in generated types are now defined in the
schema for datatypes
</sitem>
<sitem>
2000-02-21: pvb: clarified list datatypes, wrt use of component type
which allows whitespace in its literals and wrt facets applicable for
deriving subtypes of a list type
</sitem>
<sitem>
2000-02-23: pvb: change defn of binary and meaning of length facet
for binary to be measured in octets, since both lexical encodings
are only defined for octet multiples.
</sitem>
<sitem>
2000-02-23: pvb: incorporated prose description of regex language
(thanx to Matt Timmermans!!!!)
</sitem>
<sitem>
2000-02-23: pvb: added appinfo's to built-in definitions in the
schema for datatypes, which are used to generate the list of
constraining facets for each built-in datatype in the html version
of the spec
</sitem>
<sitem>
2000-02-23: pvb: replaced abstract syntax with 2 new sections for
"schema components" and "xml representation" constructs, still needs
a lot of editorial work tho
</sitem>
<sitem>
2000-02-23: pvb: list of derived types for each built-in type
is now auto-generated from the builtins.xsd
</sitem>
<sitem>
2000-02-23: pvb: appendix C.2 (list of datatypes to which each
facet applies) is now auto-generated form the builtins.xsd
</sitem>
<sitem>
2000-02-24: pvb: put equality back in as a fundamental facet,
to help with the vote on today's telcon regarding key, unique
and keyref value matching.
</sitem>
<sitem>
2000-02-24: pvb: added 'datatype valid' validation constraint
</sitem>
<sitem>
2000-02-24: pvb: added stub for 'facet valid' validation constraint
</sitem>
<sitem>
2000-03-01: pvb: fixed inconsistency in specification of length related
facets for binary type: all are now specified in octets
</sitem>
<sitem>
2000-03-02: pvb: removed paragraph from section describing the ordered
facet/property which talked about the possibility of multiple order
relations on a value-space
</sitem>
<sitem>
2000-03-02: pvb: table in appendix C.1 is now auto-generated from
appinfo supplied info w/i the schema for built-ins (builtins.xsd)
</sitem>
<sitem>
2000-03-03: pvb: changed non-norm reference to SQL to be the
actual ISO bibref
</sitem>
<sitem>
2000-03-04: pvb: fixed bug in defn of regex, to allow for the
empty regex
</sitem>
<sitem>
2000-03-08: am: changed date and time datatypes completely (yet again).
</sitem>
<sitem>
2000-03-10: pvb: added separate appendix for schema for built-in types
</sitem>
<sitem>
2000-03-10: pvb: changed example for precision facet (old one didn't
apply)
</sitem>
<sitem>
2000-03-10: pvb: change case on facets and type names to be Pascal-like:
effected facets minlength and maxlength; and datatypes uri-reference,
non-positive-integer, non-negative-integer, negitive-integer,
positive-integer, unsigned-long, unsigned-int, unsigned-short,
unsigned-byte.
</sitem>
<sitem>
2000-03-10: pvb: fixed example for enumeration facet (to use
recurringDate instead of date for its basetype.
</sitem>
<sitem>
2000-03-14: am: updated date/time types (yet again): changed
recurringInstant into recurringDuration, made timeInstant
derived from recurringDuration instead of primitive, added timePeriod,
month, year, century, recurringDate, and recurringDay
</sitem>
<sitem>
2000-03-14: am: modified description of lists of atomic types
that allow whitespace in their literals so that it is clearer
</sitem>
<sitem>
2000-03-15: pvb: added text (written by Mark Reinhold) to float &amp;
double describing the "best approximation" required for mapping
from lexical to value space
</sitem>
<sitem>
2000-03-15: pvb: cleaned up description of lexical reps for numeric
types
</sitem>
<sitem>
2000-03-15: pvb: added some explanatory text to the beginning of
sections 4 and 5
</sitem>
<sitem>
2000-03-15: pvb: made it clear (in section 4.1) that a datatype's
facets consist of the facets directly specified in the defn as well
as the set inherited from its basetype
</sitem>
<sitem>
2000-03-15: pvb: cleaned up datatype-valid "validity constribution".
</sitem>
<sitem>
2000-03-15: pvb: added facet-valid "validity contributions" for each
facet in section 4 (some just stubs at this point)
</sitem>
<sitem>
2000-03-15: pvb: moved bibl for clinger1990 from non-normative to
normative, since we are now requiring his "best approximation" for
float/double
</sitem>
<sitem>
2000-03-16: am: Changed section 2.5.1.2 List Datatypes
</sitem>
<sitem>
2000-03-16: am: Changed section 5.1.2 List Datatype
</sitem>
<sitem>
2000-03-16: am: Changed section 5.2.1 Length example
</sitem>
<sitem>
2000-03-16: am: Fixed sections 5.1.13 and 5.2.14
</sitem>
<sitem>
2000-03-16: am: Changed section on lex rep for
unsignedLong, unsignedInt, unsignedShort and unsignedByte to remove
optional sign (after all, they are "unsigned").  Also fixed examples. 
</sitem>
<sitem>
2000-03-16: am: Changed lex rep section for timePeriod.
</sitem>
<sitem>
2000-03-16: am: Changed section on timePeriod.
</sitem>
<sitem>
2000-03-16: am: Removed 2 ednotes from date section.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from month.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from year.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from century.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from recurringDate.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from recurringDay. 
</sitem>
<sitem>
2000-03-16: am: Added wording to 4.2.4 and 4.2.5
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from section 4 sections on min/max
inclusive/exclusive.  dates and times compare chronologically.
</sitem>
<sitem>
2000-03-16: pvb: fixed several problems with the regex appx:
a) a branch is 0 or more (not 1 or more) (empty regex matches the empty
string);
b) added numeric quantifiers ({n,m}, etc.);
c) fixed bug if meaning of S*;
d) added { and } to list of metacharacters and "single character escapes";
e) noted that a "normal character" can be represented as a character
reference;
f) added syntax for identifying blocks (e.g., \p{IsBasicLatin})
</sitem>
<sitem>
2000-03-16: pvb: make QName into a primitive, with value space the
set of tuples {namespace URI, localPart}.  Semantically, this is how it
should be defined, but it kind of breaks our type system: QName is now
clearly not an atomic type (it is an aggregate defined in terms of two
other existing types), which means that it shouldn't be primitive and
should be derived, but we don't have type generators...oh, well.
</sitem>
<sitem>
2000-03-16: pvb: uriReference lexical space now specified as strings
matching the URI-reference production from RFC 2396...still need to
generate a regex corresponding to that production
</sitem>
<sitem>
2000-03-17: pvb: moved all COS constraints into the appropriate
subsection of section 4 "datatype components"
</sitem>
<sitem>
2000-03-17: pvb: clarified statement in enumeration facet that it
imposes no order on the value space constructed
</sitem>
<sitem>
2000-03-17: pvb: clarified precision/scale to be a maximum number
of digits
</sitem>
<sitem>
2000-03-17: pvb: completed most of the facet-valid
"validity contributions" which began as just stubs, still a few more
to go
</sitem>
<sitem>
2000-03-17: pvb: explicitly defined the notion of an order relation
(which was mentioned, but not defined)
</sitem>
<sitem>
2000-03-17: pvb: corrected defn of string to state that the
order relation (and not the ordered property) as unicode code point
</sitem>
<sitem>
2000-03-17: pvb: clarified length, minLength and maxLength facets;
namely, that string is measured in code points (rather than the ambiguous
"character"), that binary is measured in octets of the binary data 
(not the lexical/encoded data), and specified meaning of these facets
for lists (only length was specified before)
</sitem>
<sitem>
2000-03-17: pvb: added defns for "constraint on schema", "schema
representation constraint" and "validation contribution" (largely stolen
from structures) to terminology section
</sitem>
<sitem>
2000-03-17: pvb: replaced Conformance section with a subset of the
equivalent section from structures
</sitem>
<sitem>
2000-03-17: pvb: added schema representation constraints for
multiple patterns and enumerations
</sitem>
<sitem>
2000-03-17: pvb: explicitly defined order relations for
float, double, timeDuration and recurringDuration
</sitem>
<sitem>
2000-04-03: pvb: corrected NOTE on ENTITY datatype to say 'defined in a DTD'
rather than a schema
</sitem>
<sitem>
2000-04-03: pvb: fixed presentation of table in "Constraint on Schemas: applicable facets"
</sitem>
<sitem>
2000-04-03: pvb: replaced empty validity contributions on encoding, duration and
period facet components with NOTEs that they don't participate in validation
</sitem>
<sitem>
2000-04-03: pvb: removed "open issues" appendix
</sitem>
<sitem>
2000-04-03: pvb: removed all terms in the "terminology" section which weren't used...also
made all *uses* of the remaining terms into links to their definitions
</sitem>
<sitem>
2000-04-03: pvb: styled constraints on schema, etc. in tables, with the table header color
coded to indicate the type of constraint
</sitem>
<sitem>
2000-04-03: pvb: modified section on Equality, to note that equality is defined (to be
not equal) across value spaces not related via restriction.
</sitem>
<sitem>
2000-04-03: pvb: incorporated new {schema,dtd} for datatypes
</sitem>
<sitem>
2000-04-04: pvb: replaced ednotes in 5.1.2 with some simple expository text, probably will
need to be expanded on before CR
</sitem>
<sitem>
2000-04-04: pvb: rewrote description of truncated forms of timeDuration, so that
it was more explicit about what is allowed
</sitem>
<sitem>
2000-07-12: pvb: removed note from DTD/Schema for datatypes included in
Appendices A&amp;B which says they aren't normative but that they ones
included in Appednices A&amp;B are:-)
</sitem>
<sitem>
2000-07-12: pvb: added \| as a single character escape in the regex language
</sitem>
<sitem>
2000-07-12: pvb: changed all wording of the form "X is derived from Y by
fixing the value of facet Z to a" to be "X is derived from Y by
setting the value of facet Z to a", to avoid confusion (since we can't [yet]
"fix" a facet value).
</sitem>
<sitem>
2000-07-13: pvb: updated the status of this document section for internal
point release
</sitem>
<sitem>
2000-07-13: pvb: added note to section on order relations, to the effect that
just because this spec doesn't say that a type is ordered doesn't mean that
down-stream apps can't specify some order relation.
</sitem>
<sitem>
2000-07-13: pvb: modified stylesheet to make "priority feedback" issues
more prevalent
</sitem>
<sitem>
200007-13: pvb: modified markup around PFI for decimal to take advantage of
the new stylesheet template for PFIs
</sitem>
<sitem>
2000-07-13: pvb: removed the order relation from string, and hence, the
min/max facets
</sitem>
<sitem>
2000-07-13: pvb: turned the &lt;note> in decimal about wanting feedback
about arbitrary precision into an &lt;ednote role='pf'>, which displays
specially with new stylesheet
</sitem>
<sitem>
2000-07-14: pvb: fixed the stylesheet so that it put a space between
the links "built-in" and "derived" in the auto-generated "Derived types"
subsection of each type definition.
</sitem>
<sitem>
2000-07-14: pvb: created a schema for has-facet and has-property used
in the appinfo of type definitions in the schema for datatypes
</sitem>
<sitem>
2000-07-14: pvb: modified stylesheet to generate the spec from the
modified has-facet and has-property appinfo items
</sitem>
<sitem>
2000-07-15 and 2000-07-16: pvb: my allergies had me in bed all day and
couldn't get anything done
</sitem>
<sitem>
2000-07-17: pvb: almost fixed the bugs introduced by the stylesheet
modifications for has-facet and has-property.  Appendix C still contains
a few type names duplicated under some facets...I'll get that later.
</sitem>
<sitem>
2000-07-18: AM: Fixed typos caught by Susan Lesch in her note to schema-comments of May 12.
</sitem>
<sitem>
2000-07-18: AM: Changed line in date formats to say year 0 not allowed.
</sitem>
<sitem>
2000-07-18: AM: Changed value space for decimal.
</sitem>
<sitem>
2000-07-18: AM: Changed text for recurringDuration.
</sitem>
<sitem>
2000-07-18: AM: Fixed typos in "time".
</sitem>
<sitem>
2000-07-18: pvb: changed has-facet and has-property to hasFacet and hasProperty
</sitem>
<sitem>
2000-07-18: pvb: changed definition of decimal again, to give separate defs
of value space without any facet being valued, with only precision and
with only scale.  This is intended to clarify what is and is not meant by
precision and scale.  Also fixed long standing typo in the equation for
the value space of decimal: i x 10^n corrected to i x 10^-n.
</sitem>
<sitem>
2000-08-07: pvb: finally found error in stylesheet which was causing XT to
have a stackOverflow, preventing the release of this version.
</sitem>
<sitem>
2000-08-15: pvb: added a fixed property to each facet component
</sitem>
<sitem>
2000-08-15: pvb: removed redundant "if"s in many of the Validation Contributions
in section 4
</sitem>
<sitem>
2000-08-15: pvb: removed mention of string from the Validation Contributions
of the order-related facets (min/max inc/exc) in section 4.  This should have been
done in a previous draft when string became unordered.
</sitem>
<sitem>
2000-08-16: pvb: added fixed property to each facet component; added fixed
attribute to each facet element.  Possible problems with the XML repr for
pattern and enumeration still to be worked out.
</sitem>
<sitem>
2000-08-21: pvb: fixed schema dump file, so that stylesheet correctly formats
the value attribute of all facets as being required.
</sitem>
<sitem>
2000-08-21: pvb: fixed stylesheet so that "hex | base64" in the XML Rep for
encoding no longer formated as "| hex | base64"...this also fixed a long standing
bug in the stylesheet such surrounding properly formating of &lt;choice> in content
models
</sitem>
<sitem>
2000-08-22: pvb: added union types
</sitem>
<sitem>
2000-08-23: pvb: changed defn syntax to conform to union proposal, including
changes to stylesheet to get autogenerated text from datatypes.xsd to format
correctly
</sitem>
<sitem>
2000-08-24: pvb: cleaned up a few sections so that they are consistent with
the (now) 3 forms of derivation (where there used to be only 2)
</sitem>
<sitem>
2000-08-24: pvb: marked app B (DTD) as non-normative
</sitem>
<sitem>
2000-08-30: AM: added definition of canonical form as 2.4.
</sitem>
<sitem>
2000-08-30: AM: added canonical forms for all built-in datatypes.
</sitem>
<sitem>
2000-08-30: AM: changed lex space for boolean to {true, false}.
</sitem>
<sitem>
2000-08-31: AM: removed fixed property from pattern and enumeration
pending resolution of how to handle these two cases.
</sitem>
<sitem>
2000-08-31: AM: fixed syntax for examples.  Added "fixed" for 2 examples.
</sitem>
<sitem>
2000-08-31: AM: removed pattern facet from binary.
</sitem>
<sitem>
2000-08-31: AM: changed value space for timeDuration.  Some bug fixes to
Appendix D.  
</sitem>
 End of commented out section -->
<sitem>
2000-09-28: PVB: fixed syntax errors in example schemas for "Derivation by Union"
and "enumeration" facet.
</sitem>
<sitem>
2000-09-28: PVB: fixed typos in content models of restriction, list and union
in section "XML Representation of Datatype Definitions".  Still need to fix stylesheet
to correctly generate "List of QName" for the type of the memberTypes attribute
on union.
</sitem>
<sitem>
2000-09-28: PVB: fixed typo in section on equality, where "restriction" was left
out of the final sentence, beginning "By definition".
</sitem>
<sitem>
2000-09-28: PVB: added appropriate definitions for a list's "itemType" and
a union's "memberTypes".
</sitem>
<sitem>
2000-09-28: PVB: folded old Constraint on Schemas: length and maxLength into
the existing Constraint on Schemas: length and minLength
</sitem>
<sitem>
2000-09-28: PVB: fixed many typos as reported by Wayne Carr in post on
2000-09-17.
</sitem>
<sitem>
2000-09-29: PVB: fixed NOTATION datatype, by requiring at least one enumeration
facet and further requiring that all enumeration facets name a declared notation.
Folded the old "NOTATION declared" constraint into a new COS: "enumeration required
for NOTATION"
</sitem>
<sitem>
2000-09-29: PVB: changed SVC "encoding required" to a COS.
</sitem>
<sitem>
2000-09-29: PVB: implemented WG decision in LC-7: minimum number of
decimal digits for precision.
</sitem>
<sitem>
2000-09-29: PVB: started removing inconsistencies introduced by the presence
of list and union as derivation methods: i.e., it is no longer the case that
all derived types have a base type, it is only those types derived by
restriction that do (lists have itemType's, while unions have memberTypes).
Still have much more to clean up in this regard tho, including rework in
sections 4.1 and 5.1.
</sitem>
<sitem>
2000-09-29: PVB: updated the schema and datatypes namespaces to be consistent
with the Hawthorne votes
</sitem>
<sitem>
2000-10-02: AM: fixed value space for recurring duration.
</sitem>
<sitem>
2000-10-02: AM: added info about timeDuration to Appendix D.
</sitem>
<sitem>
2000-10-02: AM: rewrote order property for timeDuration and recurringDuration.
</sitem>
<sitem>
2000-10-02: AM: added canonical lexical forms for list and union.
</sitem>
<sitem>
2000-10-04: PVB: minor editorial fix in prose describing recurringDuration
and timeDuration
</sitem>
<sitem>
2000-10-04: PVB: fixed lexical space of NOTATION to be the set of names of
declared NOTATIONs and added the fact that NOTATION is derived from QName.
</sitem>
<sitem>
2000-10-05: PVB: added S{n} to the regex language, which should have been
there all the time (equiv to S{n,n})
</sitem>
<sitem>
2000-10-06: PVB: added whiteSpace facet, component def and XML Rep for it.
</sitem>
<sitem>
2000-10-06: PVB: changed the initial wording of CVC Datatype Valid to
say that "a string is..." instead of "a sequence of char info items is...".
Makes the spec more generally applicable.
</sitem>
<sitem>
2000-10-06: PVB: flushed out schema components and XML representation/
property mapping, to encorporate derivation by restriction, list
and union
</sitem>
<sitem>
2000-10-06: PVB: sync'd the acknowledgement sections with Part 1
</sitem>
<sitem>
2000-10-06: PVB: flushed out the schema for datatypes, such that all
datatype definitions have an id attribute, all  elements involved in 
datatype definitions also now have an id attribute.  Each
built-in datatype definition has a documentation annotation that
points to the section of the spec where that datatype is described;
each element used for facets also has a documentation annotation
that points to the section of the spec where that facet is defined.
</sitem>
<sitem>
2000-10-11: PVB: fixed bug in SVC that said that union/@memberTypes and
union/child::simpleType were mutually exclusive...the corrected constraint
is simply that at least one of them must be valued.
</sitem>
<sitem>
2000-10-11: PVB: fixed the broken link on the XML Rep for union, to point
to the Datatype Definition component (there is no union component).
</sitem>
<sitem>
2000-10-16: PVB: clarified property mapping for memberTypes property
in the XML Rep of the Union Element Information Item for Datatype Definitions.
</sitem>
<sitem>
2000-10-16: PVB: fixed typo on the XML Rep of the Union Element Information Item
that incorrectly referred to a "union" schema component.
</sitem>
<sitem>
2000-10-16: PVB: fixed many broken links
</sitem>
<sitem>
2000-10-16: PVB: added xml:lang='en' to all documentation elements in
the schema for datatypes
</sitem>
<sitem>
2000-10-18: PVB: fixed typo in century which said that 20 was the lexical
for the 19th century...it is now 19 is the literal for 20th century
</sitem>
<sitem>
2000-10-18: PVB: fixed copy-paste typos in specification of min/maxLength
facet, which said just "length" in several places
</sitem>
<sitem>
2000-10-18: PVB: removed mention of character info items in the definition
of lexical space (and literal)
</sitem>
<sitem>
2000-10-18: PVB: cleared up ambiguous (many) uses of the word "may" that were
not used in the sense of the term "may" in the Terminology section...made sure
that all correct uses of "may" were linked to the definition
</sitem>
<sitem>
2000-10-18: PVB: definition of match aligned with XML 1.0 2e
</sitem>
<sitem>
2000-10-18: PVB: changed string length-related facets to be measured in
terms of XML 1.0 characters instead of code points
</sitem>
<sitem>
2000-10-18: PVB: added note to string length-related facets stating that
length may not be what some users perceive as the "string length"
</sitem>
<sitem>
2000-10-18: PVB: changed example in description of hex encoding to something
more "binary"
</sitem>
<sitem>
2000-10-18: PVB: clarified value space of string in terms of XML 1.0 characters.
</sitem>
<sitem>
2000-10-18: PVB: fixed (thought this was already done, but I guess not) Appdx
D to note that hours range form 0-23, minutes from 0-59 and seconds from 0-59 or
0-60 in the case of leap seconds.
</sitem>
<sitem>
2000-10-18: PVB: definition of language now references the "Language Identifiers"
section in XML 1.02e instead of the LanguageID production (which is gone in 2e).
</sitem>
<sitem>
2000-10-18: PVB: added a PFR requesting advice on whether future versions should
allow embedded white space in regex's.
</sitem>
<sitem>
2000-10-18: PVB: removed Cs property from regex language and added note stating
why it is the only property not allowed
</sitem>
<sitem>
2000-10-18: PVB: fixed typo in character range expansion of \w escape in
the regex language
</sitem>
<sitem>
2000-10-18: PVB: now sites XML 1.0 2e and Unicode 3 normatively, and ISO 10646
and Unicode 2 non-normatively.
</sitem>
<sitem>
2000-10-18: PVB: added note stating that conforming processors are only required
to support the Unicode char props and block names in the regex language are are
current at the time this spec goes to Rec, but that implementors are encouraged
to provide access to future revisions to Unicode.
</sitem>
<sitem>
2000-10-18: PVB: added note about possible future support for "Level 2" in
regex's
</sitem>
<sitem>
2000-10-18: PVB: changed body-temp example from fahrenheit to celsius
</sitem>
<sitem>
2000-10-18: PVB: added xml:lang='en' to all documentation annotations in
the schema for datatypes
</sitem>
<sitem>
2000-10-19: PVB: added note to the effect that recurringDuration won't meet
the needs of all calendaring/scheduling applications
</sitem>
<sitem>
2000-10-19: PVB: added PFR to recurringDuration asking for interop feedback
not just between schema processors but with other date/time systems
</sitem>
<sitem>
2000-10-19: PVB: added PFR regarding order-relation on timeDuration
</sitem>
<sitem>
2000-10-19: PVB: added note on uriReference about hex encoding and
possible "out-of-sync" problems with XMl 1.0, XPointer and CharMod.
</sitem>
<sitem>
2000-10-19: PVB: removed ednote on pattern for binary
</sitem>
<!--
<sitem>
2000-10-19: PVB: 
</sitem>
-->
</slist>
</revisiondesc>
</header>
<body>
<div1 id="Intro">
<head>Introduction</head>
<div2 id="purpose">
<head>Purpose</head>
<p>
The <bibref ref="XML"/> specification defines limited
facilities for applying datatypes to document content in that documents
may contain or refer to DTDs that assign types to elements and attributes.
However, document authors, including authors of traditional
<emph>documents</emph> and those transporting <emph>data</emph> in XML,
often require a higher degree of type checking to ensure robustness in
document understanding and data interchange.
</p>
<p>
The table below offers two typical examples of XML instances
in which datatypes are implicit: the instance on the left
represents a billing invoice, the instance on the
right a memo or perhaps an email message in XML.
</p>
<table border="1" bgcolor="&cellback;">
<thead>
<tr>
<th align="center">Data oriented</th>
<th align="center">Document oriented</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<eg><![CDATA[<invoice>
   <orderDate>1999-01-21</orderDate>
   <shipDate>1999-01-25</shipDate>
   <billingAddress>
      <name>Ashok Malhotra</name>
      <street>123 IBM Ave.</street>
      <city>Hawthorne</city>
      <state>NY</state>
      <zip>10532-0000</zip>
   </billingAddress>
   <voice>555-1234</voice>
   <fax>555-4321</fax>
</invoice>]]></eg>
</td>
<td>
<eg><![CDATA[<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>]]></eg>
</td>
</tr>
</tbody>
</table>
<p>
The invoice contains several dates and telephone numbers, the postal
abbreviation for a state
(which comes from an enumerated list of sanctioned values), and a ZIP code
(which takes a definable regular form).  The memo contains many
of the same types of information: a date, telephone number, email address
and an "importance" value (from an enumerated
list, such as "low", "medium" or "high").  Applications which process
invoices and memos need to raise exceptions if something that was
supposed to be a date or telephone number does not conform to the rules
for valid dates or telephone numbers.
</p>
<p>
In both cases, validity constraints exist on the content of the
instances that are not expressible in XML DTDs.  The limited datatyping
facilities in XML have prevented validating XML processors from supplying
the rigorous type checking required in these situations.  The result
has been that individual applications writers have had to implement type
checking in an ad hoc manner.  This specification addresses
the need of both document authors and applications writers for a robust,
extensible datatype system for XML which could be incorporated into
XML processors.  As discussed below, these datatypes could be used in other
XML-related standards as well.
</p>
</div2>
<div2 id="requirements">
<head>Requirements</head>
<p>
The <bibref ref="schema-requirements"/> document spells out
concrete requirements to be fulfilled by this specification,
which state that the XML Schema Language must:
</p>
<olist>
<item>
<p>
provide for primitive data typing, including byte, date,
integer, sequence, SQL &amp; Java primitive data types, etc.;
</p>
</item>
<item>
<p>
define a type system that is adequate for import/export
from database systems (e.g., relational, object, OLAP);
</p>
</item>
<item>
<p>
distinguish requirements relating to lexical data representation
vs. those governing an underlying information set;
</p>
</item>
<item>
<p>
allow creation of user-defined datatypes, such as
datatypes that are derived from existing datatypes and which
may constrain certain of its properties (e.g., range,
precision, length, format).
</p>
</item>
</olist>
</div2>
<div2 id="scope">
<head>Scope</head>
<p>
This portion of the XML Schema Language discusses datatypes that can be
used in an XML Schema.  These datatypes can be specified for element
content that would be specified as
<xspecref href="&xmlspec;#dt-chardata">#PCDATA</xspecref> and attribute
values of <xspecref href="&xmlspec;#sec-attribute-types">various
types </xspecref> in a DTD.  It is the intention of this specification
that it be usable outside of the context of XML Schemas for a wide range
of other XML-related activities such as <bibref ref="XSL"/> and
<bibref ref="RDFSchema"/>.
</p>
</div2>
<div2 id="terminology">
<head>Terminology</head>
<p>
The terminology used to describe XML Schema Datatypes is defined in the
body of this specification. The terms defined in the following list are
used in building those definitions and in describing the actions of a
datatype processor:
</p>
<glist>
<gitem>
<label>
<termdef id="dt-compatibility" term="for compatibility">
for compatibility</termdef>
</label>
<def>
<p>
A feature of this specification included solely to ensure that schemas
which use this feature remain compatible with <bibref ref="XML"/>
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-may" term="may"><term>may</term></termdef>
</label>
<def>
<p>
Conforming documents and processors are permitted to but need
not behave as described.
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-match" term="match"><term>match</term></termdef>
</label>
<def>
<p>
(Of strings or names:) Two strings or names being compared must be
identical. Characters with multiple possible representations in ISO/IEC 10646 (e.g.
characters with both precomposed and base+diacritic forms) match only if they have
the same representation in both strings. No case folding is performed. (Of strings and
rules in the grammar:) A string matches a grammatical production if it belongs to the
language generated by that production. 
</p>
</def>
</gitem>
<gitem>
<label>
 <termdef id="dt-must" term="must"><term>must</term></termdef>
</label>
<def>
<p>
Conforming documents and processors are required to behave as
described; otherwise they are in <termref def="dt-error">error</termref>.
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-error" term="error"><term>error</term></termdef>
</label>
<def>
<p>
A violation of the rules of this specification; results are undefined.
Conforming software <termref def="dt-may"/> detect and report an
<term>error</term> and <termref def="dt-may"/> recover from it.
</p>
</def>
</gitem>
<!--
<gitem>
<label>
<termdef id='dt-fatal-error' term='fatal error'><term>fatal error</term>
</termdef>
</label>
<def>
<p>
An <termref def='dt-error'>error</termref> which a conforming
processor <termref def='dt-must'/> detect and report to the application.
</p>
</def>
</gitem>
-->
</glist>
</div2>

<div2 id="constraints-and-contributions">
<head>Constraints and Contributions</head>
<p>
This specification provides three different kinds of normative
statements about schema components, their representations in XML and
their contribution to the schema-validation of information items:
</p>
<glist>
<gitem>
<label>
<termdef id="dt-cos" term="Constraint on Schemas">
<term>Constraint on Schemas</term>
</termdef>
</label>
<def>
<p>
Constraints on the schema components themselves, i.e. conditions
components <termref def="dt-must"/> satisfy to be components at all.
Largely to be found in <specref ref="datatype-components"/>.
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-src" term="Schema Representation Constraint">
<term>Schema Representation Constraint</term>
</termdef>
</label>
<def>
<p>
Constraints on the representation of schema components in XML.  Some but
not all of these are expressed in <specref ref="schema"/> and
<specref ref="dtd-for-datatypeDefs"/>.  Largely to be found in
<specref ref="xr-datatype-definitions"/>.
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-cvc" term="Validation Rule">
<term>Validation Rule</term>
</termdef>
</label>
<def>
<p>
Constraints expressed by schema components which information
items <termref def="dt-must"/> satisfy to be schema-valid.  Largely
to be found in <specref ref="datatype-components"/>.
</p>
</def>
</gitem>
</glist>
</div2>
</div1>
<div1 id="typesystem">
<head>Type System</head>
<p>
This section describes the conceptual framework behind the type system
defined in this specification.  The framework has been influenced by the
<bibref ref="ISO11404"/> standard on language-independent datatypes as
well as the datatypes for <bibref ref="SQL"/> and for programming
languages such as Java.
</p>
<p>
The datatypes discussed in this specification are computer
representations of well known abstract concepts such as
<emph>integer</emph> and <emph>date</emph>. It is not the place of this
specification to define these abstract concepts; many other publications
provide excellent definitions.
</p>
<div2 id="datatype">
<head>Datatype</head>
<p>
<termdef id="dt-datatype" term="datatype">In this specification,
a <term>datatype</term> is a 3-tuple, consisting of
a) a set of distinct values, called its <termref def="dt-value-space"/>,
b) a set of lexical representations, called its
<termref def="dt-lexical-space"/>, and c) a set of <termref def="dt-facet"/>s
that characterize properties of the <termref def="dt-value-space"/>,
individual values or lexical items.
</termdef>
</p>
</div2>
<div2 id="value-space">
<head>Value space</head>
<p>
<termdef id="dt-value-space" term="value space">A <term>value
space</term> is the set of values for a given datatype.
Each value in the <term>value space</term> of a datatype is denoted by
one or more literals in its <termref def="dt-lexical-space"/>.
</termdef>
</p>
<p>
The <termref def="dt-value-space"/> of a given datatype can
be defined in one of the following ways:
<ulist>
<item>
<p>
defined axiomatically from fundamental notions (intensional definition)
[see <termref def="dt-primitive"/>]
</p>
</item>
<item>
<p>
enumerated outright (extensional definition)
[see <termref def="dt-enumeration"/>]
</p>
</item>
<item>
<p>
defined by restricting the <termref def="dt-value-space"/> of
an already defined datatype to a particular subset with a given set
of properties [see <termref def="dt-derived"/>]
</p>
</item>
<item>
<p>
defined as a combination of values from one or more already defined
<termref def="dt-value-space"/>(s) by a specific construction procedure
[see <termref def="dt-list"/> and <termref def="dt-union"/>]
</p>
</item>
</ulist>
</p>
<p>
<termref def="dt-value-space"/>s have certain properties.  For example,
they always have the property of <termref def="dt-cardinality"/>,
some definition of <emph>equality</emph>
and might be <termref def="dt-ordered"/>, by which individual
values within the <termref def="dt-value-space"/> can be compared to
one another.  The properties of <termref def="dt-value-space"/>s that
are recognized by this specification are defined in
<specref ref="fundamental-facets"/>.
</p>
</div2>
<div2 id="lexical-space">
<head>Lexical space</head>
<p>
In addition to its <termref def="dt-value-space"/>, each datatype also
has a lexical space.
</p>
<p>
<termdef term="lexical space" id="dt-lexical-space">A
<term>lexical space</term> is the set of valid <emph>literals</emph>
for a datatype.
</termdef>
</p>
<p>
For example, "100" and "1.0E2" are two different literals from the
<termref def="dt-lexical-space"/> of <dtref ref="float"/> which both
denote the same value. The type system defined in this specification
provides a mechanism for schema designers to control the set of values
and the corresponding set of acceptable literals of those values for
a datatype.
</p>
<note>
<p>
The literals in the <termref def="dt-lexical-space"/>s defined in this specification
have the following characteristics:
</p>
<glist>
<gitem>
<label>
Interoperability:
</label>
<def>
<p>
The number of literals for each value has been kept small; for many
datatypes there is a one-to-one mapping between literals and values.
This makes it easy to exchange the values between different systems.
In many cases, conversion from locale-dependent representations will
be required on both the originator and the recipient side, both for
computer processing and for interaction with humans.
</p>
</def>
</gitem>
<gitem>
<label>
Basic readability:
</label>
<def>
<p>
Textual, rather than binary, literals are used.
This makes hand editing, debugging, and similar activities possible.
</p>
</def>
</gitem>
<gitem>
<label>
Ease of parsing and serializing:
</label>
<def>
<p>
Where possible, literals correspond to those found in common
programming languages and libraries.
</p>
</def>
</gitem>
</glist>
</note>
<div3 id="canonical-lexical-representation">
<head>Canonical Lexical Representation</head>
<p>
While the datatypes defined in this specification have, for the most part, 
a single lexical representation i.e. each value in the datatype's
<termref def="dt-value-space"/> is denoted by a single literal in its
<termref def="dt-lexical-space"/>, this is not always the case.  The
example in the previous section showed two literals for the datatype
<dtref ref="float"/> which denote the same value.  Similarly, there
<termref def="dt-may"/> be
several literals for one of the date or time datatypes that denote the
same value using different timezone indicators.
</p>
<!--
In such cases, this
specification defines a
-->
<p>
<termdef term="canonical lexical representation" id="dt-canonical-representation">A <term>canonical lexical representation</term>
is a set of literals from among the valid set of literals
for a datatype such that there is a one-to-one mapping between literals
in the <term>canonical lexical representation</term> and
values in the <termref def="dt-value-space"/>.
</termdef>
</p>
</div3>
</div2>
<div2 id="facets">
<head>Facets</head>
<p>
<termdef id="dt-facet" term="facet">A <term>facet</term> is a single
defining aspect of a <termref def="dt-value-space"/>.  Generally
speaking, each facet characterizes a <termref def="dt-value-space"/>
along independent axes or dimensions.</termdef>
</p>
<p>
The facets of a datatype serve to distinguish those aspects of
one datatype which <emph>differ</emph> from other datatypes.
Rather than being defined solely in terms of a prose description
the datatypes in this specification are defined in terms of
the <emph>synthesis</emph> of facet values which together determine the
<termref def="dt-value-space"/> and properties of the datatype.
</p>
<p>
Facets are of two types: <emph>fundamental</emph> facets that define
the datatype and <emph>non-fundamental</emph> or <emph>constraining
</emph> facets that constrain the permitted values of a datatype.
</p>
<div3 id="fundamental-facets">
<head>Fundamental facets</head>
<p>
<termdef id="dt-fundamental-facet" term="fundamental facet">
A <term>fundamental facet</term> is an abstract property which
serves to semantically characterize the values in a
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
These properties are discussed in this section.
</p>
<div4 id="equal">
<head>Equal</head>
<p>
Every <termref def="dt-value-space"/> supports the notion of equality,
with the following rules:
</p>
<ulist>
<item>
<p>
for any two instances of values from the <termref def="dt-value-space"/>
<emph role="eq">(a,b)</emph>, either <emph role="eq">a</emph> is equal
to <emph role="eq">b</emph>, denoted <emph role="eq">a = b</emph>, or
<emph role="eq">a</emph> is not equal to <emph role="eq">b</emph>,
denoted <emph role="eq">a != b</emph>;
</p>
</item>
<item>
<p>
there is no pair of instances (<emph role="eq">a, b</emph>) of values
from the <termref def="dt-value-space"/> such that both
<emph role="eq">a = b</emph> and <emph role="eq">a != b</emph>;
</p>
</item>
<item>
<p>
for every value a from the <termref def="dt-value-space"/>,
<emph role="eq">a = a</emph>;
</p>
</item>
<item>
<p>
for any two instances <emph role="eq">(a, b)</emph> of values from the
<termref def="dt-value-space"/>, <emph role="eq">a = b</emph> if and
only if <emph role="eq">b = a</emph>;
</p>
</item>
<item>
<p>
for any three instances <emph role="eq">(a, b, c)</emph> of values from
the <termref def="dt-value-space"/>, if <emph role="eq">a = b</emph>
and <emph role="eq">b = c</emph>, then <emph role="eq">a = c</emph>.
</p>
</item>
</ulist>
<p>
On every datatype, the operation Equal is defined in terms of the equality
property of the <termref def="dt-value-space"/>: for any values
<emph role="eq">a, b</emph> drawn from the
<termref def="dt-value-space"/>, <emph role="eq">Equal(a,b)</emph> is
true if <emph role="eq">a = b</emph>, and false otherwise.
</p>

<p>
By definition, given <termref def="dt-value-space"/>
&nbsp;<emph role="eq">A</emph> and <termref def="dt-value-space"/>
&nbsp;<emph role="eq">B</emph> where <emph role="eq">A</emph> and
<emph role="eq">B</emph> are not related by restriction,
for every pair of values <emph role="eq">a</emph> from
<emph role="eq">A</emph> and <emph role="eq">b</emph> from
<emph role="eq">B</emph>, <emph role="eq">a != b</emph>.
</p>

</div4>

<div4 id="order">
<head>Order</head>
<p>
<termdef id="dt-order-relation" term="order-relation">An
<term>order relation</term> on a <termref def="dt-value-space"/>
is a mathematical relation which imposes a total order on the
members of the <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-ordered" term="ordered">A
<termref def="dt-value-space"/>, and hence a datatype, is said to be
<term>ordered</term> if there exists an
<termref def="dt-order-relation"/> defined for that
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<term>order relations</term> have the following rules:
</p>
<ulist>
<item>
<p>
for every pair <emph role="eq">(a, b)</emph> from the
<termref def="dt-value-space"/>, either <emph role="eq">a &lt; b</emph>
or <emph role="eq">b &lt; a</emph>, or <emph role="eq">a = b</emph>;
</p>
</item>
<item>
<p>
for every triple <emph role="eq">(a, b, c)</emph> from the
<termref def="dt-value-space"/>, if <emph role="eq">a &lt; b</emph> and
<emph role="eq">b &lt; c</emph>, then <emph role="eq">a &lt; c</emph>.
</p>
</item>
</ulist>
<note>
<p>
The fact that this specification does not define an
<termref def="dt-order-relation"/> for some datatype does not
mean that some other application cannot treat that datatype as
being ordered.
</p>
</note>
</div4>

<div4 id="bounds">
<head>Bounds</head>
<p>
<termdef id="dt-bounded-above" term="bounded above">
A <termref def="dt-value-space"/> is <term>bounded above</term> if there
exists a unique value <emph role="eq">U</emph> in the
<termref def="dt-value-space"/> such that, for all values
<emph role="eq">v</emph> in the <termref def="dt-value-space"/>,
<emph role="eq">v</emph> &lt;= <emph role="eq">U</emph>.
</termdef>
<termdef id="dt-upper-bound" term="upper bound"> The value
<emph role="eq">U</emph> is said to be an <term>upper bound</term> of the
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-bounded-below" term="bounded below">A
<termref def="dt-value-space"/> is <term>bounded below</term> if there
exists a unique value <emph role="eq">L</emph> in the space such that,
for all values <emph role="eq">v</emph> in the
<termref def="dt-value-space"/>, <emph role="eq">L</emph> &lt;=
<emph role="eq">v</emph>.
</termdef>
<termdef id="dt-lower-bound" term="lower bound">
The value <emph role="eq">L</emph> is then said to be a
<term>lower bound</term> of the <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-bounded" term="bounded">A datatype is <term>bounded</term>
if its <termref def="dt-value-space"/> has both an
<termref def="dt-upper-bound"/> and a <termref def="dt-lower-bound"/>.
</termdef>
</p>
</div4>
<div4 id="cardinality">
<head>Cardinality</head>
<p>
<termdef id="dt-cardinality" term="cardinality">Every
<termref def="dt-value-space"/> has associated with it the concept of
<term>cardinality</term>.  Some <termref def="dt-value-space"/>s
are finite, some are countably infinite while still others are uncountably
infinite. A datatype is said to have the cardinality of its
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
It
is sometimes useful to categorize <termref def="dt-value-space"/>s
(and hence, datatypes) as to their cardinality.  There are two
significant cases:
</p>
<ulist>
<item>
<p>
<termref def="dt-value-space"/>s that are finite
</p>
</item>
<item>
<p>
<termref def="dt-value-space"/>s that are countably infinite
</p>
</item>
</ulist>
</div4>
<div4 id="numeric">
<head>Numeric</head>
<p>
<termdef id="dt-numeric" term="numeric">A datatype is said to be
<term>numeric</term> if its values are conceptually quantities (in some
mathematical number system).
</termdef>
</p>
<p>
<termdef id="dt-non-numeric" term="non-numeric">A datatype whose values
are not <termref def="dt-numeric"/> is said to be
<term>non-numeric</term>.
</termdef>
</p>
</div4>
</div3>
<div3 id="non-fundamental">
<head>Constraining or Non-fundamental facets</head>
<p>
<termdef id="dt-constraining-facet" term="constraining facet">A
<term>constraining facet</term> is an optional property that can be
applied to a datatype to constrain its <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
Constraining the <termref def="dt-value-space"/> consequently constrains
the <termref def="dt-lexical-space"/>.  Adding
<termref def="dt-constraining-facet"/>s to a <termref def="dt-basetype"/>
is described in <specref ref="derivation-by-restriction"/>.
</p>
<p>
In this section we define all <termref def="dt-constraining-facet"/>s
that are available for use when defining <termref def="dt-derived"/>
datatypes.
</p>

<div4 id="length">
<head>length</head>
<p>
<termdef id="dt-length" term="length"><term>length</term> is the number
of <emph>units of length</emph>, where <emph>units of length</emph>
varies depending on the type that is being <termref def="dt-derived"/> from.
The value of
<term>length</term>&nbsp;<termref def="dt-must"/> be a
<dtref ref="nonNegativeInteger"/>.
</termdef>
</p>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>length</term> is measured in units of <xtermref href="&xmlspec;#dt-character">
character</xtermref>s as defined in <bibref ref="XML"/>.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>length</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>length</term> is measured in list items.
</p>
<note>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>length</term> will not always coincide with "string length" as perceived
by some users or with the number of storage units in some digital representation.
Therefore, care should be taken when specifying a value for <term>length</term>
and in attempting to infer storage requirements from a given value for
<term>length</term>.
</p>
</note>
</div4>

<div4 id="minLength">
<head>minLength</head>
<p>
<termdef id="dt-minLength" term="minLength"><term>minLength</term> is
the minimum number of <emph>units of length</emph>, where
<emph>units of length</emph> varies depending on the type that is being
<termref def="dt-derived"/> from.
The value of <term>minLength</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="nonNegativeInteger"/>.
</termdef>
</p>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>minLength</term> is measured in units of <xtermref href="&xmlspec;#dt-character">
character</xtermref>s as defined in <bibref ref="XML"/>.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>minLength</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>minLength</term> is measured in list items.
</p>
<note>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>minLength</term> will not always coincide with "string length" as perceived
by some users or with the number of storage units in some digital representation.
Therefore, care should be taken when specifying a value for <term>minLength</term>
and in attempting to infer storage requirements from a given value for
<term>minLength</term>.
</p>
</note>
</div4>

<div4 id="maxLength">
<head>maxLength</head>
<p>
<termdef id="dt-maxLength" term="maxLength"><term>maxLength</term> is
the maximum number of <emph>units of length</emph>, where
<emph>units of length</emph> varies
depending on the type that is being <termref def="dt-derived"/> from.
The value of <term>maxLength</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="nonNegativeInteger"/>.
</termdef>
</p>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>maxLength</term> is measured in units of <xtermref href="&xmlspec;#dt-character">
character</xtermref>s as defined in <bibref ref="XML"/>.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>maxLength</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>maxLength</term> is measured in list items.
</p>
<note>
<p>
For <dtref ref="string"/> and datatypes <termref def="dt-derived"/> from <dtref ref="string"/>,
<term>maxLength</term> will not always coincide with "string length" as perceived
by some users or with the number of storage units in some digital representation.
Therefore, care should be taken when specifying a value for <term>maxLength</term>
and in attempting to infer storage requirements from a given value for
<term>maxLength</term>.
</p>
</note>
</div4>

<div4 id="pattern">
<head>pattern</head>
<p>
<termdef id="dt-pattern" term="pattern">
<term>pattern</term> is a constraint on the
<termref def="dt-value-space"/> of a datatype which is achieved by
constraining the <termref def="dt-lexical-space"/> to literals
which match a specific pattern.  The value of <term>pattern</term>
&nbsp;<termref def="dt-must"/> be a <termref def="dt-regex"/>.
</termdef>
</p>
</div4>
<div4 id="enumeration">
<head>enumeration</head>
<p>
<termdef id="dt-enumeration" term="enumeration">
<term>enumeration</term> constrains the <termref def="dt-value-space"/>
to a specified set of values.
</termdef>
</p>
<p>
<term>enumeration</term> does not impose an order relation on the
<termref def="dt-value-space"/> it creates; the value of the
<termref def="dt-ordered"/> property of the <termref def="dt-derived"/>
datatype remains that of the datatype that from which it is
<termref def="dt-derived"/>.
<!--
No order or any other relationship is implied between the individual
items of the enumeration set.
-->
</p>
</div4>
<div4 id="whiteSpace">
<head>whiteSpace</head>
<p>
<termdef id="dt-whiteSpace" term="whiteSpace">
<term>whiteSpace</term> constrains the <termref def="dt-value-space"/>
of types <termref def="dt-derived"/> from <dtref ref="string"/> such that
the various behaviors
specified in <xspecref href="&xmlspec;#AVNormalize">Attribute Value Normalization</xspecref>
in <bibref ref="XML"/> are realized.  The value of
<term>whiteSpace</term> must be one of {preserve, replace, collapse}.
</termdef>
</p>
<glist>
<gitem>
<label>preserve</label>
<def>
<p>
No normalization is done, the value is not changed (this is the
behavior required  by <bibref ref="XML"/> for element content)
</p>
</def>
</gitem>
<gitem>
<label>replace</label>
<def>
<p>
All occurrences of #x9 (tab), #xA (linefeed) and #xD (carriage return)
are replaced with #x20 (space)
</p>
</def>
</gitem>
<gitem>
<label>collapse</label>
<def>
<p>
After the processing implied by <term>replace</term>, contiguous
sequences of #x20's are collapsed to a single #x20, and leading and
trailing #x20's are removed.
</p>
</def>
</gitem>
</glist>
<note>
<p>
The notation #xA used here (and elsewhere in this specification) represents
the Universal Code Set (UCS) code point <code>hexidecimal A</code> (linefeed), which is denoted by
U+000A in <bibref ref="Unicode3"/>.  This notation is to be distinguished from <code>&amp;#xA;</code>,
which is the XML <xnt href="&xmlspec;#NT-CharRef">character reference</xnt>
to that same UCS code point.
</p>
</note>
<p>
<term>whiteSpace</term> is applicable to all <termref def="dt-atomic"/> and
<termref def="dt-list"/> datatypes.  For all <termref def="dt-atomic"/>
datatypes other than <dtref ref="string"/> (and types <termref def="dt-derived"/>
by restriction from it) the value of <term>whiteSpace</term> is
<code>collapse</code> and cannot be changed by a schema author; for
<dtref ref="string"/> the value of <term>whiteSpace</term> is
<code>preserve</code>; for any type <termref def="dt-derived"/> by restriction from
<dtref ref="string"/> the value of <term>whiteSpace</term> can
be any of the three legal values.  For all datatypes
<termref def="dt-derived"/> by <termref def="dt-list"/> the
value of <term>whiteSpace</term> is <code>collapse</code> and cannot
be changed by a schema author.  For all datatypes
<termref def="dt-derived"/> by <termref def="dt-union"/>
&nbsp;<term>whiteSpace</term> does not apply directly; however, the
normalization behavior of <termref def="dt-union"/> types is controlled by
the value of <term>whiteSpace</term> on that one of the
<termref def="dt-memberTypes"/> against which the <termref def="dt-union"/>
is successfully validated.
</p>
<note>
<p>
For more information on <term>whiteSpace</term>, see the
discussion on white space normalization in
<xspecref href="&xsdl;#components">Schema Component Details</xspecref>
in <bibref ref="structural-schemas"/>.
</p>
</note>
</div4>

<div4 id="maxInclusive">
<head>maxInclusive</head>
<p>
<termdef id="dt-maxInclusive" term="maxInclusive">
<term>maxInclusive</term> is the <termref def="dt-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>inclusive</emph> in the sense that the value is itself included
in the <termref def="dt-value-space"/>.  The value of
<term>maxInclusive</term>&nbsp;<termref def="dt-must"/> be of the same
type as the
<termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="maxExclusive">
<head>maxExclusive</head>
<p>
<termdef id="dt-maxExclusive" term="maxExclusive">
<term>maxExclusive</term> is the <termref def="dt-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is <emph>exclusive</emph>
in the sense that the value is itself excluded from the
<termref def="dt-value-space"/>.  The value of <term>maxExclusive</term>
must be of the same type as the <termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="minInclusive">
<head>minInclusive</head>
<p>
<termdef id="dt-minInclusive" term="minInclusive">
<term>minInclusive</term> is the <termref def="dt-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>inclusive</emph> in the sense that the value is itself included
in the <termref def="dt-value-space"/>.  The value of
<term>minInclusive</term> must be of the same type as the
<termref def="dt-basetype"/>.
</termdef>
</p>
</div4>
<div4 id="minExclusive">
<head>minExclusive</head>
<p>
<termdef id="dt-minExclusive" term="minExclusive">
<term>minExclusive</term> is the <termref def="dt-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>exclusive</emph> in the sense that the value is itself excluded
from the <termref def="dt-value-space"/> for the datatype.
The value of <term>minExclusive</term>&nbsp;<termref def="dt-must"/>
be of the same type as the <termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="precision">
<head>precision</head>
<p>
<termdef id="dt-precision" term="precision"><term>precision</term>
is the maximum number of decimal digits in values of datatypes
<termref def="dt-derived"/> from <dtref ref="decimal"/>.  The value of
<term>precision</term>&nbsp;<termref def="dt-must"/> be a
<dtref ref="positiveInteger"/>.
</termdef>
</p>
</div4>
<div4 id="scale">
<head>scale</head>
<p>
<termdef id="dt-scale" term="scale"><term>scale</term>
is the maximum number of decimal digits in the fractional part
of values of datatypes <termref def="dt-derived"/> from
<dtref ref="decimal"/>. The value of <term>scale</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="nonNegativeInteger"/> .
</termdef>
</p>
</div4>

<div4 id="encoding">
<head>encoding</head>
<p>
<termdef id="dt-encoding" term="encoding"><term>encoding</term> is the
encoded form of the <termref def="dt-lexical-space"/> of 
datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>.
The value of <term>encoding</term>&nbsp;<termref def="dt-must"/> be one
of {hex, base64}.
</termdef>
</p>
<p>
If the value of <term>encoding</term> is <emph>hex</emph> then each
binary octet is encoded as a character tuple, consisting the two
hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example,
"0FB7" is the <emph>hex</emph> encoding for the 16-bit integer 4023
(whose binary representation is 111110110111).
</p>
<p>
If the value of <term>encoding</term> is <emph>base64</emph> then the
entire binary stream is encoding using the Base64
Content-Transfer-Encoding defined in Section 6.8 <bibref ref="RFC2045"/>.
</p>
</div4>
<div4 id="duration">
<head>duration</head>
<p>
<termdef id="dt-duration" term="duration"><term>duration</term> is
the duration of values for the datatype <dtref ref="recurringDuration"/>
and datatypes <termref def="dt-derived"/> from
<dtref ref="recurringDuration"/>. The value of <term>duration</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="timeDuration"/>.
</termdef>
</p>
</div4>
<div4 id="period">
<head>period</head>
<p>
<termdef id="dt-period" term="period"><term>period</term> is the frequency
of recurrence for values for the datatype <dtref ref="recurringDuration"/>
and datatypes <termref def="dt-derived"/> from
<dtref ref="recurringDuration"/>. The value of <term>period</term>
&nbsp;<termref def="dt-must"/> be <dtref ref="timeDuration"/>.
</termdef>
</p>
</div4>
</div3>
</div2>
<div2 id="datatype-dichotomies">
<head>Datatype dichotomies</head>
<p>
It is useful to categorize the datatypes defined in this specification
along various dimensions, forming a set of characterization dichotomies.
</p>
<div3 id="atomic-vs-list">
<head>Atomic vs. list vs. union datatypes</head>
<ednote>
<edtext>
I know, now this is a trichotomy and not a dichotomy...hopefully no one
will be picky enough to complain
</edtext>
</ednote>
<p>
The first distinction to be made is that between
<termref def="dt-atomic"/>, <termref def="dt-list"/> and <termref def="dt-union"/>
datatypes.
</p>
<ulist>
<item>
<p>
<termdef id="dt-atomic" term="atomic"><term>Atomic</term> datatypes
are those having values which are regarded by this specification as
being indivisible.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-list" term="list"><term>List</term>
datatypes are those having values each of which which consists of a
finite-length sequence of values of an <termref def="dt-atomic"/> datatype.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-union" term="union"><term>Union</term>
datatypes are those whose <termref def="dt-value-space"/>s and
<termref def="dt-lexical-space"/>s are the union of
the <termref def="dt-value-space"/>s and
<termref def="dt-lexical-space"/>s of two or more other datatypes.
</termdef>
</p>
</item>
</ulist>
<p>
For example, a single token which <termref def="dt-match"/>es
<xspecref href="&xmlspec;#NT-Nmtoken">Nmtoken</xspecref> from
<bibref ref="XML"/> could be the value of an <termref def="dt-atomic"/>
datatype (<dtref ref="NMTOKEN"/>); while a sequence of such tokens
could be the value of a <termref def="dt-list"/> datatype
(<dtref ref="NMTOKENS"/>).
</p>
<div4 id="atomic">
<head>Atomic datatypes</head>
<p>
<termref def="dt-atomic"/> datatypes can be either
<termref def="dt-primitive"/> or <termref def="dt-derived"/>.  The
<termref def="dt-value-space"/> of an <termref def="dt-atomic"/> datatype
is a set of "atomic" values, which for the purposes of this specification,
are not further decomposable.  The <termref def="dt-lexical-space"/> of
an <termref def="dt-atomic"/> datatype is a set of <emph>literals</emph>
whose internal structure is specific to the datatype in question.
</p>
</div4>
<div4 id="list-datatypes">
<head>List datatypes</head>
<!-- question: are lists ordered? answer should be NO...the sequence
within a single value is ordered, but the value space is a list type
is not ordered
-->
<p>
Several type systems (such as the one described in
<bibref ref="ISO11404"/>) treat <termref def="dt-list"/> datatypes as
special cases of the more general notions of aggregate or collection
datatypes.
</p>
<p>
<termref def="dt-list"/> datatypes are always <termref def="dt-derived"/>.
The <termref def="dt-value-space"/> of a <termref def="dt-list"/>
datatype is a set of finite-length sequences of <termref def="dt-atomic"/>
values. The <termref def="dt-lexical-space"/> of a
<termref def="dt-list"/> datatype is a set of literals whose internal
structure is a whitespace separated sequence of literals of the
<termref def="dt-atomic"/> datatype of the items in the
<termref def="dt-list"/>
(where whitespace <termref def="dt-match"/>es
<xspecref href="&xmlspec;#NT-S">S</xspecref> in <bibref ref="XML"/>).
</p>
<p>
<termdef id="dt-itemType" term="itemType">
The <termref def="dt-atomic"/> datatype that participates in the
definition of a <termref def="dt-list"/> datatype is known as the
<term>itemType</term> of that <termref def="dt-list"/> datatype.
</termdef>
</p>
<note role="example">
<eg><![CDATA[
<simpleType name='sizes'>
  <list itemType='decimal'/>
</simpleType>
]]></eg>
<eg><![CDATA[
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
]]></eg>
</note>
<p>
A <termref def="dt-list"/> datatype can be <termref def="dt-derived"/>
from an <termref def="dt-atomic"/> datatype whose
<termref def="dt-lexical-space"/> allows whitespace. In such a case,
regardless of the input, list items will be separated at whitespace
boundaries.
</p>

<note role="example">
<eg><![CDATA[
<simpleType name='listOfString'>
  <list itemType='string'/>
</simpleType>
]]></eg>
<eg>
&lt;someElement xsi:type='listOfString'>
this is not list item 1
this is not list item 2
this is not list item 3
&lt;/someElement>
</eg>
<p>
In the above example, the value of the <emph>someElement</emph> element
is not a <termref def="dt-list"/> of <termref def="dt-length"/> 3;
rather, it is a <termref def="dt-list"/> of <termref def="dt-length"/>
18.
</p>
</note>
<!--
     somehow need to get the <has-facets> concept for abstract lists
	 into builtin.xsd, so that the following can be auto-generated
  -->
<p>
When a datatype is <termref def="dt-derived"/> from a
<termref def="dt-list"/> datatype, the following
<termref def="dt-constraining-facet"/>s can be used:
</p>
<ulist>
<item><p><termref def="dt-length"/></p></item>
<item><p><termref def="dt-maxLength"/></p></item>
<item><p><termref def="dt-minLength"/></p></item>
<item><p><termref def="dt-enumeration"/></p></item>
</ulist>
<p>
For each of the above <termref def="dt-facet"/>s, the
<emph>unit of length</emph> is measured in number of list items.
</p>
<p> The <dtref ref="canonical-lexical-representation"/> for the
<termref def="dt-list"/> datatype is defined as the lexical form in which
each item in the <termref def="dt-list"/> has the canonical lexical
representation of its  <termref def="dt-itemType"/>.</p>
</div4>
<div4 id="union-datatypes">
<head>Union datatypes</head>
<p>
The <termref def="dt-value-space"/> and <termref def="dt-lexical-space"/>
of a <termref def="dt-union"/> datatype are the union of the
<termref def="dt-value-space"/>s and <termref def="dt-lexical-space"/>s of
its <termref def="dt-memberTypes"/>.
<termref def="dt-union"/> datatypes are always <termref def="dt-derived"/>.
Currently, there are no <termref def="dt-built-in"/>&nbsp;<termref def="dt-union"/>
datatypes.
</p>
<note role="example">
<p>
A prototypical example of a <termref def="dt-union"/> type is the
<xspecref href="&xsdl;#p-max_occurs">maxOccurs attribute</xspecref> on the
<xspecref href="&xsdl;#element-element">element element</xspecref>
in XML Schema itself: it is a union of nonNegativeInteger
and an enumeration with the single member, the string "unbounded", as shown below.
</p>
<eg><![CDATA[
  <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger" use="default" value="1"/>
    <attribute name="maxOccurs">
      <simpleType>
        <union>
          <simpleType>
            <restriction base='nonNegativeInteger'/>
          </simpleType>
          <simpleType>
            <restriction base='string'>
              <enumeration value='unbounded'/>
            </restriction>
          </simpleType>
        </union>
      </simpleType>
    </attribute>
  </attributeGroup>
]]></eg>
</note>
<p>
Any number (greater than 1) of <termref def="dt-atomic"/> or <termref def="dt-list"/>
<termref def="dt-datatype"/>s can participate in a <termref def="dt-union"/> type.  
</p>
<p>
<termdef id="dt-memberTypes" term="memberTypes">
The datatypes that participate in the
definition of a <termref def="dt-union"/> datatype are known as the
<term>memberTypes</term> of that <termref def="dt-union"/> datatype.
</termdef>
</p>
<p>
The order in which the <termref def="dt-memberTypes"/> are specified in the
definition (that is, the order of the &lt;simpleType> children of the &lt;union>
element, or the order of the <dtref ref="QName"/>s in the <emph>memberTypes</emph>
attribute) is significant.
During validation, an element or attribute's value is validated against the
<termref def="dt-memberTypes"/> in the order in which they appear in the
definition until a match is found.  The evaluation order can be overridden
with the use of <xspecref href="&xsdl;#xsi_type">xsi:type</xspecref>. See
<specref ref="dc-defn"/> and <specref ref="xr-datatype-definitions"/> for
more details.
</p>
<ednote>
<name>PVB</name>
<edtext>
Do we want to make the restriction that there has to be more than one type
in a union?  It was in the proposal, but I don't think it should be an
error if only one appears.
</edtext>
</ednote>
<note>
<p>
For example, given the definition below, the first instance of the &lt;size> element
validates correctly as an <specref ref="integer"/>, the second and third as
<specref ref="string"/>.
</p>
<eg><![CDATA[
  <xsd:element name='size'>
    <xsd:simpleType>
      <xsd:union>
        <xsd:simpleType>
          <xsd:restriction base='integer'/>
        </xsd:simpleType>
        <xsd:simpleType>
          <xsd:restriction base='string'/>
        </xsd:simpleType>
      </xsd:union>
    </xsd:simpleType>
  </xsd:element>
]]></eg>
<eg><![CDATA[
  <size>1</size>
  <size>large</size>
  <size xsi:type='xsd:string'>1</size>
]]></eg></note>
<p> The <dtref ref="canonical-lexical-representation"/> for a
<termref def="dt-union"/> datatype is defined as the lexical form in which
the values have the canonical lexical representation
of the appropriate  <termref def="dt-memberTypes"/>.</p>
<note>
<p>
A datatype which is <termref def="dt-atomic"/> in this specification
need not be an "atomic" datatype in any programming language used to
implement this specification.  Likewise, a datatype which is a
<termref def="dt-list"/> in this specification need not be a "list"
datatype in any programming language used to implement this specification.
Furthermore, a datatype which is a <termref def="dt-union"/> in this
specification need not be a "union" datatype in any programming
language used to implement this specification.
</p>
</note>
</div4>
</div3>
<div3 id="primitive-vs-derived">
<head>Primitive vs. derived datatypes</head>
<p>
Next, we distinguish between <termref def="dt-primitive"/> and 
<termref def="dt-derived"/> datatypes.
</p>
<ulist>
<item>
<p>
<termdef id="dt-primitive" term="primitive"><term>Primitive</term>
datatypes are those that are not defined in terms of other datatypes;
they exist <emph>ab initio</emph>.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-derived" term="derived"><term>Derived</term>
datatypes are those that are defined in terms of other datatypes.
</termdef>
</p>
</item>
</ulist>
<p>
For example, in this specification, <dtref ref="float"/> is a well-defined
mathematical
<!-- find example other than float -->
concept that cannot be defined in terms of other datatypes, while
a <dtref ref="date"/> is a special case of the more general datatype
<dtref ref="recurringDuration"/>.
</p>
<p>
The datatypes defined by this specification fall into both
the <termref def="dt-primitive"/> and <termref def="dt-derived"/>
categories.  It is felt that a judiciously chosen set of
<termref def="dt-primitive"/> datatypes will serve the widest
possible audience by providing a set of convenient datatypes that
can be used as is, as well as providing a rich enough base from
which the variety of datatypes needed by schema designers can be
<termref def="dt-derived"/>.
</p>
<!--
<p>
<termdef id="dt-basetype" term="base type">Every
<termref def="dt-derived"/> datatype is defined in terms of an
existing datatype, referred to as the <term>base type</term>.
<term>base type</term>s can be either <termref def="dt-primitive"/>
or <termref def="dt-derived"/>.</termdef>
</p>
<ednote>
<edtext>
The introduction of <termref def='dt-list'/> and <termref def='dt-union'/>
types makes the above statement incorrect.  <termref def='dt-basetype'/>
only applies for restrictions.
</edtext>
</ednote>
-->
<p>
In the example above, <dtref ref="date"/> is <termref def="dt-derived"/>
from <dtref ref="recurringDuration"/>.
</p>
<note>
<p>
A datatype which is <termref def="dt-primitive"/> in this specification
need not be a "primitive" datatype in any programming language used to
implement this specification.  Likewise, a datatype which is
<termref def="dt-derived"/> in this specification need not be a
"derived" datatype in any programming language used to implement
this specification.
</p>
</note>
</div3>
<div3 id="built-in-vs-user-derived">
<head>Built-in vs. user-derived datatypes</head>
<ulist>
<item>
<p>
<termdef id="dt-built-in" term="built-in"><term>Built-in</term>
datatypes are those which are defined in this specification,
and can be either <termref def="dt-primitive"/> or
<termref def="dt-derived"/>;
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-user-derived" term="user-derived">
<term>User-derived</term> datatypes are those <termref def="dt-derived"/>
datatypes that are defined by individual schema designers.
</termdef>
</p>
</item>
</ulist>
<p>
Conceptually there is no difference between the
<termref def="dt-built-in"/>&nbsp;<termref def="dt-derived"/> datatypes
included in this specification and the <termref def="dt-user-derived"/>
datatypes which will be created by individual schema designers.
The <termref def="dt-built-in"/>&nbsp;<termref def="dt-derived"/> datatypes
are those which are believed to be so common that if they were not
defined in this specification many schema designers would end up
"reinventing" them.  Furthermore, including these
<termref def="dt-derived"/> datatypes in this specification serves to
demonstrate the mechanics and utility of the datatype generation
facilities of this specification.
</p>
<note>
<p>
A datatype which is <termref def="dt-built-in"/> in this specification
need not be a "built-in" datatype in any programming language used
to implement this specification.  Likewise, a datatype which is
<termref def="dt-user-derived"/> in this specification need not
be a "user-derived" datatype in any programming language used to
implement this specification.
</p>
</note>
</div3>
</div2>
</div1>
<div1 id="built-in-datatypes">
<head>Built-in datatypes</head>
<div2 id="namespaces">
<head>Namespace considerations</head>
<p>
The <termref def="dt-built-in"/> datatypes defined by this specification
are designed to be used with the &schema-language; as well as other
XML specifications. To facilitate such usage the <termref def="dt-built-in"/>
datatypes in this specification have the namespace URI:
<!-- should the "namespace URI" be a link to the uriReference type?-->
</p>
<ulist>
<item><p>http://www.w3.org/2000/10/XMLSchema-datatypes</p></item>
</ulist>
<p>
This applies to both
<termref def="dt-built-in"/> <termref def="dt-primitive"/> and
<termref def="dt-built-in"/> <termref def="dt-derived"/> datatypes.
</p>
<p>
Each <termref def="dt-user-derived"/> datatype is also associated with a
unique namespace.  However, <termref def="dt-user-derived"/> datatypes
do not come from the namespace defined by this specification; rather,
they come from the namespace of the schema in which they are defined
(see <xspecref href="&xsdl;#declare-schema">XML Representation of
Schemas</xspecref> in <bibref ref="structural-schemas"/>).
</p>
<p>
As described in more detail in <specref ref="xr-defn"/>,
each <termref def="dt-user-derived"/> datatype <termref def="dt-must"/>
be defined in terms of another datatype in one of three ways: 1) by assigning
<termref def="dt-constraining-facet"/>s which serve to <emph>restrict</emph> the
<termref def="dt-value-space"/> of the <termref def="dt-user-derived"/>
datatype to a subset of the <termref def="dt-basetype"/>; 2) by creating
a <termref def="dt-list"/> datatype whose <termref def="dt-value-space"/>
consists of finite-length sequences of values of its
<termref def="dt-itemType"/>; or 3) by creating a <termref def="dt-union"/>
datatype whose <termref def="dt-value-space"/> consists of the union of the
<termref def="dt-value-space"/> its <termref def="dt-memberTypes"/>.
</p>
</div2>
<div2 id="built-in-primitive-datatypes">
<head>Primitive datatypes</head>
<p>
The <termref def="dt-primitive"/> datatypes defined by this specification
are described below.  For each datatype, the
<termref def="dt-value-space"/> and <termref def="dt-lexical-space"/>
are defined, <termref def="dt-constraining-facet"/>s which apply
to the datatype are listed and any datatypes <termref def="dt-derived"/>
from this datatype are specified.
</p>
<p>
<termref def="dt-primitive"/> datatypes can only be added by revisions
to this specification.
</p>
<div3 id="string">
<head>string</head>
<p>
<termdef id="dt-string" term="string">The <term>string</term> datatype
represents character strings in XML.  The <termref def="dt-value-space"/>
of <term>string</term> is the set of finite-length sequences of
<xtermref href="&xmlspec;#dt-character">character</xtermref>s (as defined in
<bibref ref="XML"/>) that <termref def="dt-match"/> the
<xnt href="&xmlspec;#NT-Char">Char</xnt> production from <bibref ref="XML"/>.
A <xtermref href="&xmlspec;#dt-character">character</xtermref> is an atomic unit of
communication; it is not further specified except to note that every
<xtermref href="&xmlspec;#dt-character">character</xtermref> has a corresponding
Universal Code Set code point (<bibref ref="ISO10646"/>, <bibref ref="Unicode"/>
and <bibref ref="Unicode3"/>), which is an integer.
</termdef>
</p>
<note>
<p>
As noted in <specref ref="order"/>, the fact that this specification does
not specify an <termref def="dt-order-relation"/> for <termref def="dt-string"/>
does not preclude other applications from treating strings as being ordered.
</p>
</note>
<div4 id="string-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="string-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="boolean">
<head>boolean</head>
<p>
<termdef id="dt-boolean" term="boolean"><term>boolean</term> has the
<termref def="dt-value-space"/> required to support the mathematical
concept of binary-valued logic: {true, false}.</termdef>
</p>
<div4 id="boolean-lexical-representation">
<head>Lexical Representation</head>
<p>
An instance of a datatype that is defined as <termref def="dt-boolean"/>
can have the following legal lexical values {true, false}.
</p>
</div4>
<div4 id="boolean-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="float">
<head>float</head>
<p>
<termdef id="dt-float" term="float"><term>float</term> corresponds
to the IEEE single-precision 32-bit floating point type
<bibref ref="ieee754"/>.  The basic <termref def="dt-value-space"/> of
<term>float</term> consists of the values
<emph role="eq">m &times; 2^e</emph>, where <emph role="eq">m</emph>
is an integer whose absolute value is less than
<emph role="eq">2^24</emph>, and <emph role="eq">e</emph> is an integer
between -149 and 104, inclusive.  In addition to the basic
<termref def="dt-value-space"/> described above, the
<termref def="dt-value-space"/> of <term>float</term> also contains the
following <emph>special values</emph>: positive and negative zero,
positive negative infinity and not-a-number.
The <termref def="dt-order-relation"/> on <term>float</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
A literal in the <termref def="dt-lexical-space"/> representing a
decimal number <emph role="eq">d</emph> maps to the normalized value
in the <termref def="dt-value-space"/> of <term>float</term> that is
closest to <emph role="eq">d</emph>; if <emph role="eq">d</emph> is
exactly halfway between two such values then the even value is chosen.
This is the <emph>best approximation</emph> of <emph role="eq">d</emph>
<bibref ref="clinger1990"/> <bibref ref="gay1990"/>, which is more
accurate than the mapping required by <bibref ref="ieee754"/>.
</p>
<div4 id="float-lexical-representation">
<head>Lexical representation</head>
<p>
<term>float</term> values have a lexical representation
consisting of a mantissa followed, optionally, by the character
"E" or "e", followed by an exponent.  The exponent <termref def="dt-must"/>
be an <dtref ref="integer"/>. The mantissa must be a  <dtref ref="decimal"/> number. The representations
for exponent and mantissa must follow the lexical rules for
<dtref ref="integer"/> and <dtref ref="decimal"/>.  If the "E" or "e" and
the following exponent are omitted, an exponent value of 0 is assumed.
</p>
<p>
The <emph>special values</emph> positive and negative zero, positive
and negative infinity and not-a-number have <code>0</code>,
<code>-0</code>, <code>INF</code>, <code>-INF</code> and
<code>NaN</code>, respectively.
</p>
<p>
For example, <code>-1E4, 1267.43233E12, 12.78e-2, 12 and INF</code>
are all legal literals for <term>float</term>.
</p>
</div4>
<div4 id="float-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>float</term> is defined by
prohibiting certain options from the
<specref ref="float-lexical-representation"/>.  Specifically, the preceding optional "+" sign is prohibited from the 
mantissa.  The exponent must be indicated by "E" and number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point.  Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.  
</p>
</div4>
<div4 id="float-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="double">
<head>double</head>
<p>
<termdef id="dt-double" term="double">The <term>double</term>
datatype corresponds to IEEE double-precision 64-bit floating point
type <bibref ref="ieee754"/>.  The basic <termref def="dt-value-space"/>
of <term>double</term> consists of the values
<emph role="eq">m &times; 2^e</emph>, where <emph role="eq">m</emph>
is an integer whose absolute value is less than
<emph role="eq">2^53</emph>, and <emph role="eq">e</emph> is an
integer between -1075 and 970, inclusive.  In addition to the basic
<termref def="dt-value-space"/> described above, the
<termref def="dt-value-space"/> of <term>double</term> also contains
the following <emph>special values</emph>: positive and negative zero,
positive negative infinity and not-a-number.
The <termref def="dt-order-relation"/> on <term>double</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
A literal in the <termref def="dt-lexical-space"/> representing a
decimal number <emph role="eq">d</emph> maps to the normalized value
in the <termref def="dt-value-space"/> of <term>double</term> that is
closest to <emph role="eq">d</emph>; if <emph role="eq">d</emph> is
exactly halfway between two such values then the even value is chosen.
This is the <emph>best approximation</emph> of <emph role="eq">d</emph>
(<bibref ref="clinger1990"/>, <bibref ref="gay1990"/>), which is more
accurate than the mapping required by <bibref ref="ieee754"/>.
</p>
<div4 id="double-lexical-representation">
<head>Lexical representation</head>
<p>
<term>double</term> values have a lexical representation
consisting of a mantissa followed, optionally, by the character "E" or
"e", followed by an exponent.  The exponent <termref def="dt-must"/> be
an integer.  The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
<dtref ref="integer"/> and <dtref ref="decimal"/>.  If the "E" or "e"
and the following exponent are omitted, an exponent value of 0 is assumed.
</p>
<p>
The <emph>special values</emph> positive and negative zero, positive
and negative infinity and not-a-number have <code>0</code>,
<code>-0</code>, <code>INF</code>, <code>-INF</code> and
<code>NaN</code>, respectively.
</p>
<p>
For example, <code>-1E4, 1267.43233E12, 12.78e-2, 12 and INF</code>
are all legal literals for <term>double</term>.
</p>
</div4>
<div4 id="double-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>double</term> is defined by
prohibiting certain options from the
<specref ref="double-lexical-representation"/>.  Specifically, the preceding optional "+" sign is prohibited from the 
mantissa.  The exponent must be indicated by "E" and number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point.  Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.  
</p>
</div4>
<div4 id="double-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="decimal">
<head>decimal</head>
<p>
<termdef id="dt-decimal" term="decimal"><term>decimal</term>
represents arbitrary precision decimal numbers.
The <termref def="dt-value-space"/> of <term>decimal</term>
is the set of the values <emph role="eq">i &times; 10^-n</emph>,
where <emph role="eq">i</emph> and <emph role="eq">n</emph> are integers
such that <emph role="eq">n >= 0</emph>.
The <termref def="dt-order-relation"/> on <term>decimal</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
<termdef id="dt-decimal-with-precision" term="decimal-with-precision">
The <termref def="dt-value-space"/> of types derived from <term>decimal</term>
with a value for <termref def="dt-precision"/> of <emph role="eq">p</emph>
is the set of values <emph role="eq">i &times; 10^-n</emph>, where
<emph role="eq">n</emph> and <emph role="eq">i</emph> are integers such that
<emph role="eq">p >= n >= 0</emph> and the number of significant decimal digits
in <emph role="eq">i</emph> is less than or equal to <emph role="eq">p</emph>.
</termdef>
</p>
<p>
<termdef id="dt-decimal-with-scale" term="decimal-with-scale">
The <termref def="dt-value-space"/> of types derived from <term>decimal</term>
with a value for <termref def="dt-scale"/> of <emph role="eq">s</emph>
is the set of values <emph role="eq">i &times; 10^-n</emph>, where
<emph role="eq">i</emph> and <emph role="eq">n</emph> are integers such
that <emph role="eq">0 &lt;= n &lt;= s</emph>.
</termdef>
</p>
<note>
<p>
All <termref def="dt-minimally-conforming"/> processors <termref def="dt-must"/>
support decimal numbers with a minimum of 18 decimal digits (i.e., with a
<termref def="dt-precision"/> of 18).  However,
<termref def="dt-minimally-conforming"/> processors <termref def="dt-may"/>
set an application-defined limit on the maximum number of decimal digits
they are prepared to support, in which case that application-defined
maximum number <termref def="dt-must"/> be clearly documented.
</p>
</note>
<ednote role="pf">
<edtext>
As in all such cases, the minimum number of decimal digits that all
<termref def="dt-minimally-conforming"/> processors <termref def="dt-must"/>
support is too small for some applications and, perhaps, too large for
others.  We welcome further input from implementors whether the minimum
value of 18 is acceptable.
</edtext>
</ednote>
<!--
<ednote role='pf'>
<edtext>
The use of arbitrary precision decimal numbers, including all
datatypes derived from decimal (e.g., <dtref ref="integer"/>) in this
design impacts the implementation of schema processors in
a number of places: checking <termref def="dt-maxLength"/> constraints on
<dtref ref="string"/>s, for example. It can impact interchange between
XML schemas and programming languages, databases, etc.
Our design discussions did not reveal convincing evidence of undue
burden because of arbitrary precision decimal numbers in this design,
but we welcome further input from implementors.
</edtext>
</ednote>
-->
<div4 id="decimal-lexical-representation">
<head>Lexical representation</head>
<p>
<term>decimal</term> has a lexical representation
consisting of a finite-length sequence of decimal digits (#x30-#x39) separated
by a period as a decimal indicator, in accordance with the scale and
precision facets, with an optional leading sign. If the sign is
omitted, "+" is assumed.  Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example: <code>-1.23, 12678967.543233, +100000.00</code>.
</p>
</div4>
<div4 id="decimal-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>decimal</term> is defined by
prohibiting certain options from the
<specref ref="decimal-lexical-representation"/>.  Specifically, the preceding optional "+" sign is prohibited.  Leading zeroes are prohibited.  Trailing
zeroes to the right of the decimal point are also prohibited.  
</p>
</div4>
<div4 id="decimal-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="decimal-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>

<div3 id="timeDuration">
<head>timeDuration</head>
<p>
<termdef id="dt-timeDuration" term="timeDuration">
<term>timeDuration</term> represents a duration of time.
The <termref def="dt-value-space"/> of <term>timeDuration</term> is 
<!-- space of time durations as defined in &sect; 5.5.3.2 of
<bibref ref="ISO8601"/>.
The <termref def="dt-order-relation"/> on <term>timeDuration</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.  -->
a six-dimensional space where the coordinates
designate the Gregorian year, month, day, hour, minute, and second components defined in
&sect; 5.5.3.2 of <bibref ref="ISO8601"/>,
respectively.  These components are ordered
in their significance by their order of appearance i.e. as year, month, day,
hour, minute, and second.
The <termref def="dt-order-relation"/> on <term>timeDuration</term> is defined
as follows.
For <term>timeDuration</term>&nbsp;<emph role="eq">t</emph> and starting
<dtref ref="timeInstant"/>&nbsp;<emph role="eq">s</emph>, compute an
end <dtref ref="timeInstant"/>&nbsp;<emph role="eq">t[s]</emph> whose
components CCYY, MM, DD, etc. are computed by adding to those components of
<emph role="eq">s</emph> the corresponding components of <emph role="eq">t</emph>
and handling the carry-overs correctly.  Then, the <termref def="dt-order-relation"/>
of two <term>timeDuration</term> values <emph role="eq">x</emph> and
<emph role="eq">y</emph> is <emph role="eq">x > y iff x[s] > y[s]</emph>
for any starting instant <emph role="eq">s</emph>, <emph role="eq">x &lt;
y iff x[s] &lt; y[s]</emph> for any <emph role="eq">s</emph> and
<emph role="eq">x = y iff x[s] = y[s]</emph> for any <emph role="eq">s</emph>.
</termdef>
</p>
<p>
Note that the <termref def="dt-order-relation"/> on <term>timeDuration</term>
holds for some <emph role="eq">s</emph> but not for all <emph role="eq">s</emph>.
In such cases the the order relation in said to be indeterminate.  For example, while P1M25D > P50D and
P1M10D &lt; P50 the order relation between P1M20D and P50D is indeterminate. 
</p>
<ednote role="pf">
<edtext>
The complexity of real world durations of time introduces difficulties into
any design that attempts to support them.
The <loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working
Group</loc> acknowledges the undesirability of an <termref def="dt-order-relation"/>
that specifies a partial (as opposed to a total) order; however, it has found
no other solution that garnered consensus.  Therefore, the 
<loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working Group</loc>
welcomes feedback from implementors and schema authors on alternative designs.
Specifically, we are interested in knowing whether <term>timeDuration</term>
needs to be <termref def="dt-ordered"/> at all and in hearing how other
implemented systems which provide a total order for durations of time have
defined that total order.
</edtext>
</ednote>
<div4 id="timeDuration-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>timeDuration</term> is the
<bibref ref="ISO8601"/> extended format P<emph>n</emph>Y<emph>n</emph>
M<emph>n</emph>DT<emph>n</emph>H <emph>n</emph>M<emph>n</emph>S, where
<emph>n</emph>Y represents the number of years, <emph>n</emph>M the
number of months, <emph>n</emph>D the number of days, 'T' is the
date/time separator, <emph>n</emph>H the number of hours,
<emph>n</emph>M the number of minutes and <emph>n</emph>S the
number of seconds.  The number of seconds can include decimal digits
to arbitrary precision.</p>
<p>
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but 
allow an arbitrary integer.  Similarly, the value of the Seconds component
allows an arbitrary decimal.  Thus, the lexical representation of
<term>timeDuration</term> does not follow the alternative 
format of &sect; 5.5.3.2.1 of <bibref ref="ISO8601"/>.</p>
<p>
An optional preceding minus sign ('-') is
allowed, to indicate a negative duration.  If the sign is omitted a
positive duration is indicated. See also <specref ref="isoformats"/>.
</p>
<p>
For example, to indicate a duration of 1 year, 2 months, 3 days, 10
hours, and 30 minutes, one would write: <code>P1Y2M3DT10H30M</code>.
One could also indicate a duration of minus 120 days as:
<code>-P120D</code>.
</p>
<p>
Reduced precision and truncated representations of this format are allowed
provided they conform to the following:
</p>
<ulist>
<item>
<p>
The lowest order items <termref def="dt-may"/> be omitted.  If omitted their value is
assumed to be zero.
</p>
</item>
<item>
<p>
The lowest order item <termref def="dt-may"/> have a decimal fraction.
</p>
</item>
<item>
<p>
If the number of years, months, days, hours, minutes, or seconds in any
expression equals zero, the number and its corresponding designator <termref def="dt-may"/>
be omitted.  However, at least one number and its designator must be present.
</p>
</item>
<item>
<p>
The designator 'T' shall be absent if all of the time items are absent.
The designator 'P' must always be present.
</p>
</item>
</ulist>
<p>
For example, P1347Y, P1347M and P1Y2MT2H are all allowed;
P0Y1347M and P0Y1347M0D are allowed. P-1347M is not allowed although
-P1347M is allowed.  P1Y2MT is not allowed.
</p>

<!--
<p>
Both left and right truncated forms of the above representation are
allowed.  In the left truncated form, the truncation occurs after the
leading "P".
For example, <code>P1347Y</code> and <code>P1347M</code> are both
allowed; <code>P0Y1347M</code> is also allowed. <code>P0Y1347M0D</code>
is not allowed and <code>P-1347M</code> is not allowed although
<code>-P1347M</code> is allowed.
</p>
-->
<!-- this is unclear and needs to be rewritten -->
<!-- 
<p>
Time periods, i.e. durations of time with a specific start and end,
 can be represented by
supplying two items of information: a start instant and a duration
or a start instant and an end instant or an end instant and a duration.
</p>
-->
</div4>
<div4 id="timeDuration-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="recurringDuration">
<head>recurringDuration</head>
<p>
<termdef id="dt-recurringDuration" term="recurringDuration">
<term>recurringDuration</term> represents a specific period of time
that recurs with a specific frequency, starting from a specific point in time.
The value that appears in an instance document is
interpreted as the point in time when the recurrence begins.
The <termref def="dt-value-space"/> of <term>recurringDuration</term> is the
set of sets of <dtref ref="timeDuration"/>s that recur with a specific
<dtref ref="timeDuration"/> starting from a specific <dtref ref="timeInstant"/>.
The <termref def="dt-order-relation"/> on <term>recurringDuration</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive where x and y
are starting <dtref ref="timeInstant"/>s.   <term>recurringDurations</term>
which have different values for the <term>duration</term> and
<term>period</term> cannot be compared.
</termdef>
</p>
<p>
<term>recurringDuration</term> has two constraining facets
<termref def="dt-duration"/> and <termref def="dt-period"/> whose values
 <termref def="dt-must"/> be specified when the datatype is defined.
These facets specify the
length of the duration and after what duration it recurs.  The lexical
format used to specify these facet values is the lexical format for
<dtref ref="timeDuration"/>. A value of 0 for the facet
<termref def="dt-period"/> means that the duration does not recur i.e.
there is but a single occurrence.  A value of 0 for the facet
<termref def="dt-duration"/> means that the duration is, in fact, a
single instant of time.
</p>
<p>
<term>recurringDuration</term> is a conceptual datatype which serves as a
<termref def="dt-basetype"/>
from which the other date and time datatypes are <termref def="dt-derived"/>.
It can also be
used as a <termref def="dt-basetype"/> for <termref def="dt-user-derived"/>
datatypes.  A <termref def="dt-user-derived"/> datatype
can be <termref def="dt-derived"/> from <term>recurringDuration</term> by
specifying values for
<termref def="dt-duration"/> and <termref def="dt-period"/>.
</p>
<note>
<p>
While <term>recurringDuration</term> is capable of serving as the
<termref def="dt-basetype"/> of datatypes used in many different
date and time related applications beyond those supplied by its use
as the <termref def="dt-basetype"/> of the
<termref def="dt-built-in"/> datatypes <termref def="dt-derived"/>
from it, <term>recurringDuration</term> is not intended as a general-purpose
solution to calendaring and scheduling applications.
</p>
</note>
<ednote role="pf">
<edtext>
The <loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working
Group</loc> is particularly interested in feedback from implementors and
schema authors as to how <dtref ref="timeDuration"/>, <term>recurringDuration</term>
and the other date and time related datatypes <termref def="dt-derived"/>
from <term>recurringDuration</term> interoperate with other date and
time related systems.
</edtext>
</ednote>
<constraintnote type="cos" id="duration-and-period-required">
<head>duration and period required for recurringDuration</head>
<p>
It is an <termref def="dt-error"/> for <term>recurringDuration</term>
to be used directly in a schema.  Only datatypes that are
<termref def="dt-derived"/> from <term>recurringDuration</term> by
specifying a value for <termref def="dt-duration"/> and
<termref def="dt-period"/> can be used in a schema.
</p>
</constraintnote>
<div4 id="recurringDuration-lexical-repr">
<head>Lexical representation</head>
<p>
A single lexical representation, which is a subset of the lexical
representations allowed by <bibref ref="ISO8601"/>, is allowed for
<term>recurringDuration</term>.  This lexical representation is the
<bibref ref="ISO8601"/> extended format CCYY-MM-DDThh:mm:ss.sss
where "CC" represents the century, "YY" the year, "MM" the month and
"DD" the day, preceded by an optional leading sign to indicate a
negative number. If the sign is omitted, "+" is assumed. The letter
"T" is the date/time separator and "hh", "mm", "ss.sss" represent hour,
minute and second respectively.  Additional digits can be used to
increase the precision of fractional seconds if desired. To accommodate
year values greater than 9999 additional digits can be added to the
left of this representation.  The year 0000 is prohibited.
</p>
<p>
This representation can be immediately followed by a "Z" to indicate
Coordinated Universal Time (UTC).  To indicate the time zone, i.e. the
difference between the local time and Coordinated Universal Time,
the difference immediately follows the time and consists of a sign,
+ or -, followed by hh:mm.  See also <specref ref="isoformats"/>.
</p>
<p>
The derived datatype <dtref ref="timeInstant"/> uses the same lexical
representation. Other derived datatypes <dtref ref="date"/>, 
<dtref ref="time"/>, <dtref ref="timePeriod"/> and
<dtref ref="recurringDate"/> use truncated versions of this lexical
representation. 
</p>
</div4>
<div4 id="recurringDuration-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>recurringDuration</term> is defined
by prohibiting certain options from the
<specref ref="recurringDuration-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="recurringDuration-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="recurringDuration-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>

<div3 id="binary">
<head>binary</head>
<p>
<termdef id="dt-term" term="binary"><term>binary</term> represents
arbitrary binary data.  The <termref def="dt-value-space"/> of
<term>binary</term> is the set of finite-length sequences of binary
octets.
</termdef>
</p>
<constraintnote type="cos" id="encoding-required">
<head>encoding required for binary</head>
<p>
It is an <termref def="dt-error"/> for <term>binary</term> to be used
directly in a schema.  Only datatypes that are <termref def="dt-derived"/>
from <term>binary</term> by minimally specifying a value for
<termref def="dt-encoding"/> can be used in a schema.
</p>
</constraintnote>
<div4 id="binary-facets">
<head>Constraining facets</head>
<facets/>
<!--
<ednote>
<edtext>
What does the pattern facet on binary really mean?  Since pattern
operates on the lexical space, one would have to give a regex for the
base64 or hex that would result for a specific binary sequence that one
wanted to constrain...this is not too far fetched for hex, but almost
impossible for base64, isn't it?
</edtext>
</ednote>
-->
</div4>
</div3>
<div3 id="uriReference">
<head>uriReference</head>
<p>
<termdef id="dt-uriReference" term="uriReference">
<term>uriReference</term> represents a Uniform Resource Identifier (URI)
Reference as defined in Section 4 of <bibref ref="RFC2396"/>, as amended
by <bibref ref="RFC2732"/>.
A <term>uriReference</term> can be an <termref def="dt-absolute-uriReference"/>
or a <termref def="dt-relative-uriReference"/>, and <termref def="dt-may"/> have
an optional fragment identifier.
</termdef>
</p>
<note>
<p>
URI References require certain ASCII characters and all
non-ASCII characters be hex encoded, sometimes called URI-escaping
(see Section 2 of <bibref ref="RFC2396"/>, as amended by Section
3 of <bibref ref="RFC2732"/>).  Therefore, schema authors need to
exercise caution in the use of <term>uriReference</term>.  Specifically,
schema authors should avoid <term>uriReference</term> in cases where
literals should be allowed to directly contain characters that
<bibref ref="RFC2396"/>, as amended by <bibref ref="RFC2732"/>, require
to be hex encoded.
</p>
</note>
<!--
<ednote role="pf">
<edtext>
There is some question whether <term>uriReference</term> as defined
here is in accord with the treatment of URI's in <bibref ref="CharMod"/>,
<xtermref href="&xmlspec;#dt-sysid">
system identifier</xtermref>s in <bibref ref="XML"/> and XPointers
in Section 4.1 of <bibref ref="Xptr"/>.
The <loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working
Group</loc> welcomes feedback from implementors and schema authors on
whether further harmonization between these specifications is necessary.
Changes resulting from such further harmonization might result in
additional changes to the XML Schema Language in cases where
<term>uriReference</term> in used (e.g., <xspecref href="&xsdl;#xsi_schemaLocation">
xsi:schemaLocation</xspecref> in <bibref ref="structural-schemas"/>).
</edtext>
</ednote>
-->
<ednote role="pf">
<edtext>
There is ongoing discussion about how to
treat URI References that might contain non-ASCII characters.
It is extremely important that all W3C specifications
that deal
with such URI References (at least this specification, <bibref ref="CharMod"/>, <bibref ref="XML"/>
and <bibref ref="Xptr"/>, probably others) be aligned; however, it is not clear
how best to achieve that alignment with this specification.
In addition to the current
design, where both the <termref def="dt-lexical-space"/> and
<termref def="dt-value-space"/> of <term>uriReference</term>
are considered to be hex encoded, there are at least 3 alternative
designs that could be considered: 1) have 2 types, the current
type and another type (not strictly speaking, a URI Reference)
where both the <termref def="dt-lexical-space"/> and
<termref def="dt-value-space"/> where allowed to contain non-ASCII
characters; 2) a single type whose <termref def="dt-lexical-space"/>
is allowed to contain non-ASCII characters, but whose
<termref def="dt-value-space"/> was the set of hex-encoded literals;
3) a single type whose <termref def="dt-lexical-space"/> was hex-encoded,
but whose <termref def="dt-value-space"/> was allowed to contain
non-ASCII characters (i.e., the set of hex-decoded literals).
The <loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working
Group</loc> welcomes feedback from implementors and schema authors on
how to further harmonize the effected specifications; in particular,
we seek advice on which of the above alternatives (or some other
alternative not yet considered) is most desirable.
Changes resulting from such further harmonization might result in
additional changes to the XML Schema Language in cases where
<term>uriReference</term> in used (e.g., <xspecref href="&xsdl;#xsi_schemaLocation">
xsi:schemaLocation</xspecref> in <bibref ref="structural-schemas"/>).
</edtext>
</ednote>
<p>
<termdef id="dt-absolute-uriReference" term="absolute uriReference">
An <term>absolute uriReference</term> refers to a resource
in a manner which is independent of the context in which the
<termref def="dt-uriReference"/> occurs.
</termdef>
</p>
<p>
<termdef id="dt-relative-uriReference" term="relative uriReference">
A <term>relative uriReference</term> refers to a resource
by describing the difference within a hierarchy of resources between the
context in which the <term>relative uriReference</term> occurs and 
the <termref def="dt-absolute-uriReference"/> of the resource.
</termdef>
</p>
<div4 id="uriReference-lexical-representation">
<head>Lexical representation</head>
<p>
The <termref def="dt-lexical-space"/> of <term>uriReference</term> is
the set of strings that <termref def="dt-match"/> the URI-reference
production in Section 4 of <bibref ref="RFC2396"/>.
</p>

</div4>
<div4 id="uriReference-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="ID">
<head>ID</head>
<p>
<termdef id="dt-ID" term="ID"><term>ID</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">ID attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>ID</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been used in an XML document.  The
<termref def="dt-lexical-space"/> of <term>ID</term> is the set of all
strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>ID</term> is scoped to
a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>)
<term>ID</term> should be used only on attributes.
</p>
<constraintnote type="svc" id="id">
<head>ID Unique</head>
<p>
An <term>ID</term>&nbsp;<termref def="dt-must"/> not appear more than once
in an XML document as a value of this type; i.e., <term>ID</term> values
must uniquely identify the elements which bear them.
</p>
</constraintnote>
<div4 id="ID-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="IDREF">
<head>IDREF</head>
<p>
<termdef id="dt-IDREF" term="IDREF"><term>IDREF</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">IDREF attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>IDREF</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been used in an XML document as the
value of an element or attribute of type <dtref ref="ID"/>.  The
<termref def="dt-lexical-space"/> of <term>IDREF</term> is the set of 
strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>

<note>
<p>
The <termref def="dt-value-space"/> of <term>IDREF</term> is scoped to
a specific instance document.
<!--
and is a restriction of the instance document scoped
<termref def='dt-value-space'/> of <dtref ref='ID'/>.
-->
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) this datatype
should be used only on attributes.
</p>
<constraintnote type="svc" id="idref">
<head>IDREF</head>
<p>
An <term>IDREF</term>&nbsp;<termref def="dt-must"/>&nbsp;<termref def="dt-match"/>
the value of an <dtref ref="ID"/> in the XML document in which it occurs.
</p>
</constraintnote>
<div4 id="IDREF-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="IDREF-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="ENTITY">
<head>ENTITY</head>
<p>
<termdef id="dt-ENTITY" term="ENTITY"><term>ENTITY</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">ENTITY</xnt> attribute type from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>ENTITY</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been declared as an
<xspecref href="&xmlspec;#dt-unparsed">unparsed entity</xspecref> in
a <xspecref href="&xmlspec;#dt-doctype">document type definition</xspecref>.
The <termref def="dt-lexical-space"/> of <term>ENTITY</term> is the set
of all strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>
<note>
<p>
<!-- isn't this really scoped to a schema? -->
The <termref def="dt-value-space"/> of <term>ENTITY</term> is scoped
to a specific instance document.
</p>
</note>
<constraintnote type="svc" id="entity">
<head>ENTITY declared</head>
<p>
<term>ENTITY</term> values <termref def="dt-must"/>&nbsp;<termref def="dt-match"/>
an unparsed entity name that is declared in the schema.
</p>
</constraintnote>
<p>
For compatibility (see <specref ref="terminology"/>) <term>ENTITY</term>
should be used only on attributes.
</p>
<div4 id="ENTITY-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="ENTITY-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="QName">
<head>QName</head>
<p>
<termdef id="dt-QName" term="QName"><term>QName</term> represents
<xspecref href="&xmlnsspec;#dt-qname">XML qualified names</xspecref>.
The <termref def="dt-value-space"/> of <term>QName</term> is the set of
tuples {<xspecref href="&xmlnsspec;#dt-NSName">namespace name</xspecref>,
<xspecref href="&xmlnsspec;#dt-localname">local part</xspecref>},
where <xspecref href="&xmlnsspec;#dt-NSName">namespace name</xspecref>
is a <dtref ref="uriReference"/>
and <xspecref href="&xmlnsspec;#dt-localname">local part</xspecref> is
an <dtref ref="NCName"/>.

The <termref def="dt-lexical-space"/> of <term>QName</term> is the set
of strings that <termref def="dt-match"/> the <xspecref href="&xmlnsspec;#NT-QName">
QName</xspecref> production of <bibref ref="XMLNS"/>.
</termdef>
</p>
<div4 id="QName-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="QName-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
</div2>
<div2 id="built-in-derived">
<head>Derived datatypes</head>
<p>
This section gives conceptual definitions for all
<termref def="dt-built-in"/>&nbsp;<termref def="dt-derived"/> datatypes
defined by this specification. The XML Representation used to define
<termref def="dt-derived"/> datatypes (whether
<termref def="dt-built-in"/> or <termref def="dt-user-derived"/>) is
given in section <specref ref="xr-defn"/> and the complete
definitions of the <termref def="dt-built-in"/>&nbsp;
<termref def="dt-derived"/> datatypes are provided in Appendix
<specref ref="schema"/>.
</p>
<div3 id="CDATA">
<head>CDATA</head>
<p>
<termdef id="dt-CDATA" term="CDATA"><term>CDATA</term>
represents white space normalized strings.
The <termref def="dt-value-space"/> of <term>CDATA</term> is the 
set of strings that do not
contain the carriage-return (#xD), line-feed (#xA) nor tab (#x9) characters.
The <termref def="dt-lexical-space"/> of <term>CDATA</term> is the 
set of strings that do not
contain the newline (#xD) nor tab (#x9) characters.
The <termref def="dt-basetype"/> of <term>CDATA</term> is <baseref/>.
</termdef>
</p>
<div4 id="CDATA-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="CDATA-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="token">
<head>token</head>
<p>
<termdef id="dt-token" term="token"><term>token</term>
represents tokenized strings.
The <termref def="dt-value-space"/> of <term>token</term> is the 
set of strings that do not
contain the line-feed (#xA) nor tab (#x9) characters, that have no
leading or trailing spaces (#x20) and that have no internal sequences
of two or more spaces.
The <termref def="dt-lexical-space"/> of <term>token</term> is the 
set of strings that do not
contain the line-feed (#xA) nor tab (#x9) characters, that have no
leading or trailing spaces (#x20) and that have no internal sequences
of two or more spaces.
The <termref def="dt-basetype"/> of <term>token</term> is <baseref/>.
</termdef>
</p>
<div4 id="token-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="token-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="language">
<head>language</head>
<p>
<termdef id="dt-language" term="language"><term>language</term>
represents natural language identifiers as defined by
<bibref ref="RFC1766"/>.  The <termref def="dt-value-space"/> of
<term>language</term> is the set of all strings that are valid
language identifiers as defined in the
<xspecref href="&xmlspec;#sec-lang-tag">language identification</xspecref>
section of <bibref ref="XML"/>.  The <termref def="dt-lexical-space"/> of
<term>language</term> is the set of all strings that are valid
language identifiers as defined in the
<xspecref href="&xmlspec;#sec-lang-tag">language identification</xspecref>
section of <bibref ref="XML"/>.
The <termref def="dt-basetype"/> of <term>language</term> is <baseref/>.
</termdef>
</p>
<div4 id="language-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="IDREFS">
<head>IDREFS</head>
<p>
<termdef id="dt-IDREFS" term="IDREFS"><term>IDREFS</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">IDREFS attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>IDREFS</term> is the set of finite-length sequences of
<termref def="dt-IDREF"/>s that have been used in an XML document.
The <termref def="dt-lexical-space"/> of <term>IDREFS</term> is the
set of whitespace separated tokens, each of which is in the
<termref def="dt-lexical-space"/> of <dtref ref="IDREF"/>.
The <termref def="dt-itemType"/> of <term>IDREFS</term> is
<itemTyperef/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>IDREFS</term> is scoped
to a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) <term>IDREFS</term>
should be used only on attributes.
</p>

<div4 id="IDREFS-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<!--
<constraintnote type='svc' id='idref'>
<head>IDREF</head>
<p>
Each <term>IDREF</term>&nbsp;<termref def='dt-must'/>&nbsp;<termref def='dt-match'/>
the value of an <dtref ref='ID'/> in the XML document.
</p>
</constraintnote>
-->
</div3>
<div3 id="ENTITIES">
<head>ENTITIES</head>
<p>
<termdef id="dt-ENTITIES" term="ENTITIES"><term>ENTITIES</term>
represents the <xnt href="&xmlspec;#NT-TokenizedType">ENTITIES attribute
type</xnt> from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>ENTITIES</term> is the set of finite-length sequences of
<termref def="dt-ENTITY"/>s that have been declared as
<xspecref href="&xmlspec;#dt-unparsed">unparsed entities</xspecref>
in a <xspecref href="&xmlspec;#dt-doctype">document type definition</xspecref>.
The <termref def="dt-lexical-space"/> of <term>ENTITIES</term> is the
set of white space separated tokens, each of which is in the
<termref def="dt-lexical-space"/> of <dtref ref="NMTOKEN"/>.
The <termref def="dt-itemType"/> of <term>ENTITIES</term> is
<itemTyperef/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>ENTITIES</term> is scoped
to a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) <term>ENTITIES</term>
should be used only on attributes.
</p>
<div4 id="ENTITIES-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="NMTOKEN">
<head>NMTOKEN</head>
<p>
<termdef id="dt-NMTOKEN" term="NMTOKEN"><term>NMTOKEN</term> represents
the <xnt href="&xmlspec;#NT-TokenizedType">NMTOKEN attribute type</xnt>
from <bibref ref="XML"/>. The <termref def="dt-value-space"/> of
<term>NMTOKEN</term> is the set of tokens that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Nmtoken">Nmtoken</xnt> production in
<bibref ref="XML"/>. The <termref def="dt-lexical-space"/> of
<term>NMTOKEN</term> is the set of strings that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Nmtoken">Nmtoken</xnt> production in
<bibref ref="XML"/>.  The <termref def="dt-basetype"/> of
<term>NMTOKEN</term> is <baseref/>.
</termdef>
</p>
<p>
For compatibility (see <specref ref="terminology"/>) <term>NMTOKEN</term>
should be used only on attributes.
</p>
<div4 id="NMTOKEN-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="NMTOKEN-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="NMTOKENS">
<head>NMTOKENS</head>
<p>
<termdef id="dt-NMTOKENS" term="NMTOKENS"><term>NMTOKENS</term>
represents the <xnt href="&xmlspec;#NT-TokenizedType">NMTOKENS attribute
type</xnt> from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>NMTOKENS</term> is the set of finite-length sequences of
<termref def="dt-NMTOKEN"/>s.  The <termref def="dt-lexical-space"/>
of <term>NMTOKENS</term> is the set of white space separated tokens,
each of which is in the <termref def="dt-lexical-space"/> of
<dtref ref="NMTOKEN"/>.  The <termref def="dt-itemType"/> of
<term>NMTOKENS</term> is <itemTyperef/>.
</termdef>
</p>
<p>
For compatibility (see <specref ref="terminology"/>)
<term>NMTOKENS</term> should be used only on attributes.
</p>
<div4 id="NMTOKENS-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="Name">
<head>Name</head>
<p>
<termdef id="dt-Name" term="Name"><term>Name</term>
represents <xspecref href="&xmlspec;#dt-name">XML Names</xspecref>.
The <termref def="dt-value-space"/> of <term>Name</term> is
the set of all strings which <termref def="dt-match"/> the
<xspecref href="&xmlspec;#NT-Name"> Name</xspecref> production of
<bibref ref="XML"/>.  The <termref def="dt-lexical-space"/> of
<term>Name</term> is the set of all strings which <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Name">Name</xnt> production of
<bibref ref="XML"/>. The <termref def="dt-basetype"/> of <term>Name</term>
is <baseref/>.
</termdef>
</p>
<div4 id="Name-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="Name-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="NCName">
<head>NCName</head>
<p>
<termdef id="dt-NCName" term="NCName"><term>NCName</term> represents XML
"non-colonized" Names.  The <termref def="dt-value-space"/> of
<term>NCName</term> is the set of all strings which <termref def="dt-match"/>
the <xspecref href="&xmlnsspec;#NT-NCName"> NCName</xspecref> production of
<bibref ref="XMLNS"/>.  The <termref def="dt-lexical-space"/> of
<term>NCName</term> is the set of all strings which <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production of
<bibref ref="XMLNS"/>.  The <termref def="dt-basetype"/> of
<term>NCName</term> is <baseref/>.
</termdef>
</p>
<div4 id="NCName-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="NOTATION">
<head>NOTATION</head>
<p>
<termdef id="dt-NOTATION" term="NOTATION"><term>NOTATION</term>
represents the <xnt href="&xmlspec;#NT-NotationType">NOTATION</xnt> attribute
type from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>NOTATION</term> is the set of all names of
<xspecref href="&xsdl;#declare-notation">notations</xspecref> declared
in the current schema.  The <termref def="dt-lexical-space"/> of
<term>NOTATION</term>is the set of all names of
<xspecref href="&xsdl;#declare-notation">notations</xspecref> declared
in the current schema.
The <termref def="dt-basetype"/> of <term>NOTATION</term> is <baseref/>.
</termdef>
</p>
<constraintnote type="cos" id="enumeration-required-notation">
<head>enumeration facet value required for NOTATION</head>
<p>
It is an <termref def="dt-error"/> for <term>NOTATION</term>
to be used directly in a schema.  Only datatypes that are
<termref def="dt-derived"/> from <term>NOTATION</term> by
specifying a value for <termref def="dt-enumeration"/> can be used
in a schema.  Furthermore, the value of all <termref def="dt-enumeration"/>
facets must <termref def="dt-match"/> the name of a
<xspecref href="&xsdl;#declare-notation">notation</xspecref>
declared in the current schema.
</p>
</constraintnote>
<note>
<p>
The <termref def="dt-value-space"/> of <term>NOTATION</term> is scoped
to a specific schema, given the requirement that all values of the
<termref def="dt-enumeration"/> facet must be the name of a declared
<xspecref href="&xsdl;#declare-notation">notation</xspecref>.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) <term>NOTATION</term>
should be used only on attributes.
</p>
<div4 id="NOTATION-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="integer">
<head>integer</head>
<p>
<termdef id="dt-integer" term="integer"><term>integer</term> is
<termref def="dt-derived"/> from <dtref ref="decimal"/> by fixing the
value of <termref def="dt-scale"/> to be 0. This results in the standard
mathematical concept of the integer numbers. The
<termref def="dt-value-space"/> of <term>integer</term> is the infinite
set {...,-2,-1,0,1,2,...}.  The <termref def="dt-basetype"/> of
<term>integer</term> is <baseref/>.
</termdef>
</p>
<div4 id="integer-lexical-representation">
<head>Lexical representation</head>
<p>
<term>integer</term> has a lexical representation consisting of a finite-length sequence
of decimal digits (#x30-#x39) with an optional leading sign.  If the sign is omitted,
"+" is assumed.  For example: -1, 0, 12678967543233, +100000.
</p>
</div4>
<div4 id="integer-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>integer</term> is defined
by prohibiting certain options from the
<specref ref="integer-lexical-representation"/>.  Specifically, the preceding optional "+" sign is prohibited and leading zeroes are prohibited.  
</p>
</div4>
<div4 id="integer-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="integer-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="nonPositiveInteger">
<head>nonPositiveInteger</head>
<p>
<termdef id="dt-nonPositiveInteger" term="nonPositiveInteger">
<term>nonPositiveInteger</term> is <termref def="dt-derived"/> from
<dtref ref="integer"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 0.  This results in the
standard mathematical concept of the non-positive integers.
The <termref def="dt-value-space"/> of <term>nonPositiveInteger</term>
is the infinite set {...,-2,-1,0}.  The <termref def="dt-basetype"/>
of <term>nonPositiveInteger</term> is <baseref/>.
</termdef>
</p>
<div4 id="nonPositiveInteger-lexical-representation">
<head>Lexical representation</head>
<p>
<term>nonPositiveInteger</term> has a lexical representation consisting
of a negative sign ("-") followed by a finite-length
sequence of decimal digits (#x30-#x39).  If the sequence of digits consists of all
zeros then the sign is optional.
For example: -1, 0, -12678967543233, -100000.
</p>
</div4>
<div4 id="nonPositiveInteger-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>nonPositiveInteger</term> is defined
by prohibiting certain options from the
<specref ref="nonPositiveInteger-lexical-representation"/>.  Specifically, the
negative sign ("-") is required with the token "0" and leading zeroes are prohibited.  
</p>
</div4>
<div4 id="nonPositiveInteger-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="nonPositiveInteger-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="negativeInteger">
<head>negativeInteger</head>
<p>
<termdef id="dt-negativeInteger" term="negativeInteger">
<term>negativeInteger</term> is <termref def="dt-derived"/> from
<dtref ref="nonPositiveInteger"/> by setting the value of
<termref def="dt-maxInclusive"/> to be -1.  This results in the
standard mathematical concept of the negative integers.  The
<termref def="dt-value-space"/> of <term>negativeInteger</term>
is the infinite set {...,-2,-1}.  The <termref def="dt-basetype"/>
of <term>negativeInteger</term>  is <baseref/>.
</termdef>
</p>
<div4 id="negativeInteger-lexical-representation">
<head>Lexical representation</head>
<p>
<term>negativeInteger</term> has a lexical representation consisting
of a negative sign ("-") followed by a finite-length
sequence of decimal digits (#x30-#x39).  For example: -1, -12678967543233, -100000.
</p>
</div4>
<div4 id="negativeInteger-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>negativeInteger</term> is defined
by prohibiting certain options from the
<specref ref="negativeInteger-lexical-representation"/>.  Specifically,  leading zeroes are prohibited.  
</p>
</div4>
<div4 id="negativeInteger-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="long">
<head>&long;</head>
<p>
<termdef id="dt-long" term="long"><term>&long;</term> is
<termref def="dt-derived"/> from <dtref ref="integer"/> by setting the
value of <termref def="dt-maxInclusive"/> to be 9223372036854775807
and <termref def="dt-minInclusive"/> to be -9223372036854775808.
The <termref def="dt-basetype"/> of <term>&long;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="long-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&long;</term> has a lexical representation consisting
of an optional sign followed by a finite-length
sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.
For example: -1, 0,
12678967543233, +100000.
</p>
</div4>
<div4 id="long-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>long</term> is defined
by prohibiting certain options from the
<specref ref="long-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="long-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="long-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="int">
<head>&int;</head>
<p>
<termdef id="dt-int" term="int"><term>&int;</term>
is <termref def="dt-derived"/> from <dtref ref="long"/> by setting the
value of <termref def="dt-maxInclusive"/> to be 2147483647 and
<termref def="dt-minInclusive"/> to be -2147483648.  The
<termref def="dt-basetype"/> of <term>&int;</term> is <baseref/>.
</termdef>
</p>
<div4 id="int-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&int;</term> has a lexical representation consisting
of an optional sign followed by a finite-length
sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.
For example: -1, 0,
126789675, +100000.
</p>
</div4>
<div4 id="int-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>&int;</term> is defined
by prohibiting certain options from the
<specref ref="int-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="int-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="int-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="short">
<head>&short;</head>
<p>
<termdef id="dt-short" term="short"><term>&short;</term> is
<termref def="dt-derived"/> from <dtref ref="int"/> by setting the
value of <termref def="dt-maxInclusive"/> to be 32767 and
<termref def="dt-minInclusive"/> to be -32768.  The
<termref def="dt-basetype"/> of <term>&short;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="short-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&short;</term> has a lexical representation consisting
of an optional sign followed by a finite-length sequence of decimal
digits (#x30-#x39).  If the sign is omitted, "+" is assumed.
For example: -1, 0, 12678, +10000.
</p>
</div4>
<div4 id="short-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>&short;</term> is defined
by prohibiting certain options from the
<specref ref="short-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="short-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="short-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="byte">
<head>&byte;</head>
<p>
<termdef id="dt-byte" term="byte"><term>&byte;</term>
is <termref def="dt-derived"/> from <dtref ref="short"/>
by setting the value of <termref def="dt-maxInclusive"/> to be 127
and <termref def="dt-minInclusive"/> to be -128.
The <termref def="dt-basetype"/> of <term>&byte;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="byte-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&byte;</term> has a lexical representation consisting
of an optional sign followed by a finite-length
sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.
For example: -1, 0,
126, +100.
</p>
</div4>
<div4 id="byte-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>&byte;</term> is defined
by prohibiting certain options from the
<specref ref="byte-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="byte-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="nonNegativeInteger">
<head>nonNegativeInteger</head>
<p>
<termdef id="dt-nonNegativeInteger" term="nonNegativeInteger">
<term>nonNegativeInteger</term> is <termref def="dt-derived"/> from
<dtref ref="integer"/> by setting the value of
<termref def="dt-minInclusive"/> to be 0.  This results in the
standard mathematical concept of the non-negative integers. The
<termref def="dt-value-space"/> of <term>nonNegativeInteger</term>
is the infinite set {0,1,2,...}.  The <termref def="dt-basetype"/> of
<term>nonNegativeInteger</term> is <baseref/>.
</termdef>
</p>
<div4 id="nonNegativeInteger-lexical-representation">
<head>Lexical representation</head>
<p>
<term>nonNegativeInteger</term> has a lexical representation consisting
of an optional sign followed by a finite-length
sequence of decimal digits (#x30-#x39).  If the sign is omitted, "+" is assumed.
For example:
1, 0, 12678967543233, +100000.
</p>
</div4>
<div4 id="nonNegativeInteger-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>nonNegativeInteger</term> is defined
by prohibiting certain options from the
<specref ref="nonNegativeInteger-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="nonNegativeInteger-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="nonNegativeInteger-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="unsignedLong">
<head>&unsignedLong;</head>
<p>
<termdef id="dt-unsignedLong" term="unsignedLong">
<term>&unsignedLong;</term> is <termref def="dt-derived"/> from
<dtref ref="nonNegativeInteger"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 18446744073709551615.
The <termref def="dt-basetype"/> of <term>&unsignedLong;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="unsignedLong-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&unsignedLong;</term> has a lexical representation consisting
of a finite-length sequence of decimal digits (#x30-#x39).
For example: 0,
12678967543233, 100000.
</p>
</div4>
<div4 id="unsignedLong-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>unsignedLong</term> is defined
by prohibiting certain options from the
<specref ref="unsignedLong-lexical-representation"/>.  Specifically, 
leading zeroes are prohibited.
</p>
</div4>
<div4 id="unsignedLong-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="unsignedLong-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="unsignedInt">
<head>&unsignedInt;</head>
<p>
<termdef id="dt-unsignedInt" term="unsignedInt">
<term>&unsignedInt;</term> is <termref def="dt-derived"/> from
<dtref ref="unsignedLong"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 4294967295.  The
<termref def="dt-basetype"/> of <term>&unsignedInt;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="unsignedInt-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&unsignedInt;</term> has a lexical representation consisting
of a finite-length
sequence of decimal digits (#x30-#x39).  For example: 0,
1267896754, 100000.
</p>
</div4>
<div4 id="unsignedInt-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>unsignedInt</term> is defined
by prohibiting certain options from the
<specref ref="unsignedInt-lexical-representation"/>.  Specifically, 
leading zeroes are prohibited.
</p>
</div4>
<div4 id="unsignedInt-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="unsignedInt-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="unsignedShort">
<head>&unsignedShort;</head>
<p>
<termdef id="dt-unsignedShort" term="unsignedShort">
<term>&unsignedShort;</term> is <termref def="dt-derived"/> from
<dtref ref="unsignedInt"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 65535.  The
<termref def="dt-basetype"/> of <term>&unsignedShort;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="unsignedShort-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&unsignedShort;</term>  has a lexical representation consisting
of a finite-length
sequence of decimal digits (#x30-#x39).
For example: 0,
12678, 10000.
</p>
</div4>
<div4 id="unsignedShort-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>unsignedShort</term> is defined
by prohibiting certain options from the
<specref ref="unsignedShort-lexical-representation"/>.  Specifically, the
leading zeroes are prohibited.
</p>
</div4>
<div4 id="unsingedShort-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="unsignedShort-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="unsignedByte">
<head>&unsignedByte;</head>
<p>
<termdef id="dt-unsignedByte" term="unsignedByte">
<term>&unsignedByte;</term> is <termref def="dt-derived"/> from
<dtref ref="unsignedShort"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 255. The
<termref def="dt-basetype"/> of <term>&unsignedByte;</term> is
<baseref/>.
</termdef>
</p>
<div4 id="unsignedByte-lexical-representation">
<head>Lexical representation</head>
<p>
<term>&unsignedByte;</term>  has a lexical representation consisting
of a finite-length
sequence of decimal digits (#x30-#x39).
For example: 0,
126, 100.
</p>
</div4>
<div4 id="unsignedByte-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>unsignedByte</term> is defined
by prohibiting certain options from the
<specref ref="unsignedByte-lexical-representation"/>.  Specifically, 
leading zeroes are prohibited.
</p>
</div4>
<div4 id="unisngedByte-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="positiveInteger">
<head>positiveInteger</head>
<p>
<termdef id="dt-positiveInteger" term="positiveInteger">
<term>positiveInteger</term> is <termref def="dt-derived"/> from
<dtref ref="nonNegativeInteger"/> by setting the value of
<termref def="dt-minInclusive"/> to be 1. This results in the standard
mathematical concept of the positive integer numbers.  
The <termref def="dt-value-space"/> of <term>positiveInteger</term>
is the infinite set {1,2,...}.  The <termref def="dt-basetype"/> of
<term>positiveInteger</term> is <baseref/>.
</termdef>
</p>
<div4 id="positiveInteger-lexical-representation">
<head>Lexical representation</head>
<p>
<term>positiveInteger</term> has a lexical representation consisting
of an optional positive sign ("+") followed by a finite-length
sequence of decimal digits (#x30-#x39).
For example: 1, 12678967543233, +100000.
</p>
</div4>
<div4 id="positiveInteger-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>positiveInteger</term> is defined
by prohibiting certain options from the
<specref ref="positiveInteger-lexical-representation"/>.  Specifically, the
the optional "+" sign is prohibited and leading zeroes are prohibited.
</p>
</div4>
<div4 id="positiveInteger-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="timeInstant">
<head>timeInstant</head>
<p>
<termdef id="dt-timeInstant" term="timeInstant">
<term>timeInstant</term> represents a specific instant of time.  The
<termref def="dt-value-space"/> of <term>timeInstant</term> is the space
of <emph>Combinations of date and time of day</emph> values as defined
in &sect; 5.4 of <bibref ref="ISO8601"/>. The <termref def="dt-basetype"/>
of <term>timeInstant</term> is <baseref/>.
</termdef>
<term>timeInstant</term> is generated from
<dtref ref="recurringDuration"/> by fixing the value of the
<termref def="dt-duration"/> facet equal to "P0Y" and the value of the
<termref def="dt-period"/> facet equal to "P0Y" (no recurrence).
</p>
<div4 id="timeInstant-lexical-repr">
<head>Lexical representation</head>
<p>
A single lexical representation, which is a subset of the lexical
representations allowed by <bibref ref="ISO8601"/>, and is the same
lexical representation as its basetype <dtref ref="recurringDuration"/>
is allowed for <term>timeInstant</term>.
</p>
<p>
For example, to indicate 1:20 pm on May the 31st, 1999 for Eastern
Standard Time which is 5 hours behind Coordinated Universal Time (UTC), one
would write: <code>1999-05-31T13:20:00-05:00</code>.
</p>
</div4>
<div4 id="timeInstant-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>timeInstant</term> is defined
by prohibiting certain options from the
<specref ref="timeInstant-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="timeInstant-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="time">
<head>time</head>
<p>
<termdef id="dt-time" term="time"><term>time</term>
represents an instant of time that recurs every day.  The
<termref def="dt-value-space"/> of <term>time</term> is the space
of <emph>time of day</emph> values as defined in &sect; 5.3 of
<bibref ref="ISO8601"/>.  Specifically, it is a set of zero-duration daily
instances e.g. lexical 12:30:24 to represent T12:30:24 on any day.
The <termref def="dt-basetype"/> of
<term>time</term> is <baseref/>.
<term>time</term> is generated from <dtref ref="recurringDuration"/>
by fixing the value of the <termref def="dt-duration"/> facet equal
to "P0Y" and the value of the <termref def="dt-period"/> facet equal to
"P1D".
</termdef>
</p>
<div4 id="time-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>time</term> is the left
truncated lexical representation for <dtref ref="timeInstant"/>:
hh:mm:ss.sss with optional following time zone indicator.  For example,
to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind
Coordinated Universal Time (UTC), one would write: 13:20:00-05:00. See also
<specref ref="isoformats"/>.
</p>
</div4>
<div4 id="time-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>time</term> is defined
by prohibiting certain options from the
<specref ref="time-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="time-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="timePeriod">
<head>timePeriod</head>
<p>
<termdef id="dt-timePeriod" term="timePeriod"><term>timePeriod</term>
represents a specific period of time with a given start and end.
The <termref def="dt-value-space"/> of <term>timePeriod</term> is the
value space of <emph>Periods of time</emph> as defined in &sect; 5.5
of <bibref ref="ISO8601"/>.  The <termref def="dt-basetype"/> of
<term>timePeriod</term> is <baseref/>.
<term>timePeriod</term> is generated from <dtref ref="recurringDuration"/>
by fixing the value of the <termref def="dt-period"/> facet equal to
"P0Y" (no recurrence).
</termdef>
</p>
<p>
The value in the instance specifies the start of the
<term>time period</term> while the value of <termref def="dt-duration"/>
facet, specified when subtypes are defined, gives the duration of the
<term>time period</term>.
</p>
<div4 id="timePeriod-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>timePeriod</term> is the same
as that of its basetype, <dtref ref="recurringDuration"/>.
</p>
</div4>
<div4 id="timePeriod-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>timePeriod</term> is defined
by prohibiting certain options from the
<specref ref="timePeriod-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="timePeriod-facets">
<head>Constraining facets</head>
<facets/>
<constraintnote type="cos" id="duration-required">
<head>period facet value required for timePeriod</head>
<p>
It is an <termref def="dt-error"/> for <term>timePeriod</term>
to be used directly in a schema.  Only datatypes that are
<termref def="dt-derived"/> from <term>timePeriod</term> by
specifying a value for <termref def="dt-duration"/> can be used
in a schema.
</p>
</constraintnote>
</div4>
<div4 id="timePeriod-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>

<div3 id="date">
<head>date</head>
<p>
<termdef id="dt-date" term="date"><term>date</term>
represents a <dtref ref="timePeriod"/> that starts at midnight of a
specified day and lasts until midnight the following day.  The <termref def="dt-value-space"/>
of <term>date</term> is the set of Gregorian calendar dates as defined
in &sect; 5.2.1 of <bibref ref="ISO8601"/>.  Specifically,
it is a set of one-day long, non-periodic instances
e.g. lexical 1999-10-26 to represent the whole day of 1999-10-26, independent
of how many hours this day has.
The <termref def="dt-basetype"/> of <term>date</term> is
<baseref/>.  <term>date</term> is generated from
<dtref ref="timePeriod"/> by fixing the value of the
<termref def="dt-duration"/> facet equal to "P1D".
</termdef>
</p>
<div4 id="date-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>date</term> is the reduced (right
truncated) lexical representation for <dtref ref="timePeriod"/>:
CCYY-MM-DD.  No left truncation is allowed.  An optional following time
zone qualifier is allowed as for <dtref ref="timePeriod"/>.   To
accommodate year values outside the range from 0001 to 9999, additional
digits can be added to the left of this representation and a preceding
"-" is allowed.
</p>
<p>
For example, to indicate May the 31st, 1999, one would write: 1999-05-31.
See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="date-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>date</term> is defined
by prohibiting certain options from the
<specref ref="date-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="date-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

<div3 id="month">
<head>month</head>
<p>
<termdef id="dt-month" term="month"><term>month</term> represents a
<dtref ref="timePeriod"/> that starts at midnight on the first day of
the month and lasts until the midnight that ends the last day
of the month.  The <termref def="dt-value-space"/> of <term>month</term>
is the set of Gregorian calendar months as defined in &sect; 5.2.1 of
<bibref ref="ISO8601"/>.  Specifically, it is a set of one-month long,
non-periodic instances
e.g. 1999-10 to represent the whole month of 1999-10, independent of
how many days this month has.
The <termref def="dt-basetype"/> of
<term>month</term> is <baseref/>.  <term>month</term> is
generated from <dtref ref="timePeriod"/> by fixing the value of the
<termref def="dt-duration"/> facet equal to "P1M".
</termdef>
</p>
<div4 id="month-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>month</term> is the reduced
(right truncated) lexical representation for <dtref ref="timePeriod"/>:
CCYY-MM.  No left truncation is allowed.  An optional following time
zone qualifier is allowed as for <dtref ref="timePeriod"/>.   To
accommodate year values outside the range from 0001 to 9999, additional
digits can be added to the left of this representation and a preceding
"-" is allowed.
</p>
<p>
For example, to indicate the month of May 1999, one would write: 1999-05.
See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="month-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>month</term> is defined
by prohibiting certain options from the
<specref ref="month-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="month-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

<div3 id="year">
<head>year</head>
<p>
<termdef id="dt-year" term="year"><term>year</term> represents a
<dtref ref="timePeriod"/> that starts at the midnight that 
starts the first day of the year and ends at the midnight that ends the
last day of the year.  The <termref def="dt-value-space"/> of
<term>year</term> is the set of Gregorian calendar years as defined in
&sect; 5.2.1 of <bibref ref="ISO8601"/>. Specifically, it is a set of one-year
long, non-periodic instances
e.g. lexical 1999 to represent the whole year 1999, independent of
how many months and days this year has.
 
The <termref def="dt-basetype"/>
of <term>year</term> is <baseref/>.  <term>year</term> is
generated from <dtref ref="timePeriod"/> by fixing the value of the
<termref def="dt-duration"/> facet equal to "P1Y".
</termdef>
</p>
<div4 id="year-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>year</term> is the reduced (right
truncated) lexical representation for <dtref ref="timePeriod"/>: CCYY.
No left truncation is allowed.  An optional following time
zone qualifier is allowed as for <dtref ref="timePeriod"/>.   To
accommodate year values outside the range from 0001 to 9999, additional
digits can be added to the left of this representation and a preceding
"-" is allowed.
</p>
<p>
For example, to indicate 1999, one would write: 1999.
See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="year-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>year</term> is defined
by prohibiting certain options from the
<specref ref="year-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="year-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

<div3 id="century">
<head>century</head>
<p>
<termdef id="dt-century" term="century"><term>century</term>
represents a <dtref ref="timePeriod"/> that starts at the midnight that
starts the first day of the century and ends at the midnight that ends
that last day of the century.  The <termref def="dt-value-space"/> of
<term>century</term> is the set of Gregorian calendar centuries as
defined in &sect; 5.2.1 of <bibref ref="ISO8601"/>.  Specifically, it is
a set of one-century long, non-periodic instances
e.g. literal 19 to represent the whole of the 20th century.

The <termref def="dt-basetype"/> of <term>century</term> is
<baseref/>.  <term>century</term> is generated from
<dtref ref="timePeriod"/> by fixing the value of the
<termref def="dt-duration"/> facet equal to "P100Y".
</termdef>
</p>

<div4 id="century-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>century</term> is the reduced
(right truncated) lexical representation for <dtref ref="timePeriod"/>:
CC.  No left truncation is allowed.  An optional following time
zone qualifier is allowed as for <dtref ref="timePeriod"/>.   To
accommodate year values outside the range from 0001 to 9999, additional
digits can be added to the left of this representation and a preceding
"-" is allowed.
</p>
<p>
For example, to indicate the 20th century, one would write: 19.
See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="century-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>century</term> is defined
by prohibiting certain options from the
<specref ref="century-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="century-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

<div3 id="recurringDate">
<head>recurringDate</head>
<p>
<termdef id="dt-recurringDate" term="recurringDate">
<term>recurringDate</term> is a date that recurs, specifically a day of
the year such as the third of May.  Arbitrary recurring dates are not
supported by this datatype.  The <termref def="dt-value-space"/> of
<term>recurringDate</term> is the set of <emph>calendar
dates</emph>, as defined in &sect; 3 of <bibref ref="ISO8601"/>.  Specifically,
it is a set of one-day long, annually periodic instances.
The <termref def="dt-basetype"/> of <term>recurringDate</term> is
<baseref/>.  <term>recurringDate</term> is
generated from <dtref ref="recurringDuration"/> by fixing the value of
the <termref def="dt-duration"/> facet equal to "P1D"
and the value of the <termref def="dt-period"/> facet to "P1Y"
(one year).
</termdef>
</p>

<div4 id="recurringDate-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>recurringDate</term> is the left
truncated lexical representation for <dtref ref="date"/>: --MM-DD.
No other formats are allowed. See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="recurringDate-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>recurringDate</term> is defined
by prohibiting certain options from the
<specref ref="recurringDate-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="recurringDate-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

<div3 id="recurringDay">
<head>recurringDay</head>
<p>
<termdef id="dt-recurringDay" term="recurringDay">
<term>recurringDay</term> is a day that recurs, specifically a day
of the month such as the 5th of the month.  Arbitrary recurring days
are not supported by this datatype.  The <termref def="dt-value-space"/>
of <term>recurringDay</term> is the space of a set of <emph>calendar
dates</emph> as defined in &sect; 3 of <bibref ref="ISO8601"/>.  Specifically,
it is a set of one-day long, monthly periodic instances.
The <termref def="dt-basetype"/> of <term>recurringDay</term> is
<baseref/>.  <term>recurringDay</term> is
generated from <dtref ref="recurringDuration"/> by fixing the value
of the <termref def="dt-duration"/> facet equal to "P1D"
and the value of the <termref def="dt-period"/> facet to
"P1M".
</termdef>
</p>
<div4 id="recurringDay-lexical-repr">
<head>Lexical representation</head>
<p>
The lexical representation for <term>recurringDay</term> is the left
truncated lexical representation for <dtref ref="date"/>: ---DD .
No other formats are allowed.  See also <specref ref="isoformats"/>.
</p>
</div4>
<div4 id="recurringDay-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>recurringDay</term> is defined
by prohibiting certain options from the
<specref ref="recurringDay-lexical-repr"/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="recurringDay-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>

</div2>
</div1>
<div1 id="datatype-components">
<head>Datatype components</head>
<p>
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 absent are taken to have
the null value.
</p>
<p>
Throughout the following sections, the &i-value; of an attribute
information item means a string composed of, in order, the
&i-ccode; of each character information item in the &i-attrChildren;
of that attribute information item.
</p>
<p>
For more information on the notion of datatype (schema) components,
see <xspecref href="&xsdl;#components">Schema Component Details</xspecref>
of <bibref ref="structural-schemas"/>.
</p>
<note>
<p>
Readers whose primary interest is in the XML representation of datatype
definitions might wish to skip this section on the first reading,
concentrating instead on <specref ref="xr-datatype-definitions"/>.
</p>
</note>
<div2 id="dc-defn">
<head>Datatype definition</head>
<p>
Datatype definitions provide for:
</p>
<ulist>
<item>
<p>
Establishing the <termref def="dt-value-space"/> and <termref def="dt-lexical-space"/>
of a datatype, through
the combined set of <termref def="dt-constraining-facet"/>s specified
in the definition;
</p>
</item>
<item>
<p>
Attaching a unique name (actually a <dtref ref="QName"/>) to the
<termref def="dt-value-space"/> and <termref def="dt-lexical-space"/>.
</p>
</item>
</ulist>
<p>
The datatype definition schema component has the following properties:
</p>
<!--
<compdef name="Datatype Definition" ref="datatype">
<proplist>
<propdef id="defn-name" name="name">
Optional.  An NCName as defined by <bibref ref="XMLNS"/>.
</propdef>
<propdef id="defn-target-namespace" name="target namespace">
Either <xspecref href="&xsdl;#key-null">null</xspecref> or a
namespace URI, as defined in <bibref ref="XMLNS"/>.
</propdef>
<propdef id="defn-variety" name="variety">
One of {<termref def="dt-atomic"/>, <termref def="dt-list"/>, <termref def="dt-union"/>}.
</propdef>
<propdef id="defn-basetype" name="base type definition">
If <propref ref='defn-variety'/> is <termref def='dt-atomic'/>
or <termref def='dt-list'/> then a datatype definition, else if
<propref ref='defn-variety'/> is <termref def='dt-union'/> then a list of
datatype definitions.
</propdef>
<propdef id="defn-facets" name="facets">
A possibly empty set of <specref ref="dc-facets"/>.
</propdef>
<propdef id="defn-fund-facets" name="fundamental facets">
A set of <specref ref="fundamental-facets"/>
</propdef>
<propdef id="defn-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>
-->
<compdef name="Datatype Definition" ref="datatype">
<proplist>
<propdef id="defn-name" name="name">
Optional.  An NCName as defined by
<bibref ref="XMLNS"/>.
</propdef>
<propdef id="defn-target-namespace" name="target namespace">
Either <xspecref href="&xsdl;#key-null">null</xspecref> or a
namespace URI, as defined in <bibref ref="XMLNS"/>.
</propdef>
<propdef id="defn-variety" name="variety">
One of {<pt>atomic</pt>, <pt>list</pt>, <pt>union</pt>}. Depending on the
value of <propref ref="defn-variety"/>, further properties are defined as follows:
<glist>
<gitem>
<label>atomic</label>
<def>
<proplist>
<propdef id="defn-primitive" name="primitive type definition">
A <termref def="dt-built-in"/>&nbsp;<termref def="dt-primitive"/>
datatype definition (or the <xtermref href="&xsdl;#simple-ur-type-itself">
simple ur-type definition</xtermref>).
</propdef>
</proplist>
</def>
</gitem>
<gitem>
<label>list</label>
<def>
<proplist>
<propdef id="defn-itemType" name="itemType definition">
An <termref def="dt-atomic"/> or <termref def="dt-union"/> datatype definition.
</propdef>
</proplist>
</def>
</gitem>
<gitem>
<label>union</label>
<def>
<proplist>
<propdef id="defn-memberTypes" name="memberType definitions">
A non-empty sequence of simple type definitions.
</propdef>
</proplist>
</def>
</gitem>
</glist>
</propdef>    
<propdef id="defn-facets" name="facets">
A possibly empty set of <specref ref="dc-facets"/>.
</propdef>
<propdef id="defn-fund-facets" name="fundamental facets">
A set of <specref ref="fundamental-facets"/>
</propdef>
<propdef id="defn-basetype" name="base type definition">
Optional.  If the datatype has been <termref def="dt-derived"/> by restriction
then the datatype definition from which it is <termref def="dt-derived"/>,
otherwise absent.
</propdef>
<propdef id="defn-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>
<p>
Datatypes are identified by their <propref ref="defn-name"/>
and <propref ref="defn-target-namespace"/>.  Except
for anonymous datatypes (those with no <propref ref="defn-name"/>),
datatype definitions <termref def="dt-must"/> be uniquely identified
within an schema.
</p>
<p>
If <propref ref="defn-variety"/> is <termref def="dt-atomic"/>
then the <termref def="dt-value-space"/> of the datatype defined will
be a subset of the <termref def="dt-value-space"/> of
<propref ref="defn-basetype"/> (which is a subset of the
<termref def="dt-value-space"/> of <propref ref="defn-primitive"/>).
If <propref ref="defn-variety"/> is <termref def="dt-list"/>
then the <termref def="dt-value-space"/> of the datatype defined will
be the set of finite-length sequence of values from the
<termref def="dt-value-space"/> of <propref ref="defn-itemType"/>.
If <propref ref="defn-variety"/> is <termref def="dt-union"/> then the
<termref def="dt-value-space"/> of the datatype defined will be the
union of the <termref def="dt-value-space"/>s of each datatype in
<propref ref="defn-memberTypes"/>.
</p>
<p>
If <propref ref="defn-variety"/> is <termref def="dt-atomic"/>
then the <propref ref="defn-variety"/> of <propref ref="defn-basetype"/> 
must be <termref def="dt-atomic"/>.
If <propref ref="defn-variety"/> is <termref def="dt-list"/>
then the <propref ref="defn-variety"/> of <propref ref="defn-itemType"/>
must be either <termref def="dt-atomic"/> or <termref def="dt-union"/>.
If <propref ref="defn-variety"/> is <termref def="dt-union"/>
then
<propref ref="defn-memberTypes"/> must be a list of datatype definitions.
</p>
<!--
<ednote>
<name>PVB</name>
<edtext>
List of union makes sense, allowing different items in the list to be of
the different types in the union. There is no way to override the lexical
resolution strategy, i.e., you can't use xsi:type to say that item 3 of the list
is really a string when the resolution strategy would say it is an int.  This
is OK, but it just dawned on my and I wanted to call it out to make sure
I'm correct.
</edtext>
</ednote>
-->
<p>
The value of <propref ref="defn-facets"/> consists of the set of
<termref def="dt-facet"/>s specified directly in the datatype definition
unioned with the possibly empty set of <propref ref="defn-facets"/> of
<propref ref="defn-basetype"/>.
</p>
<p>
The value of <propref ref="defn-fund-facets"/> consists of the set of
<termref def="dt-fundamental-facet"/>s and their values.
</p>
<p>
If
<propref ref="defn-variety"/> is <termref def="dt-atomic"/>
then <termref def="dt-bounded"/> is <emph>true</emph> and
<termref def="dt-cardinality"/> is <emph>finite</emph> if
one of <termref def="dt-minInclusive"/> or <termref def="dt-minExclusive"/>
and one of <termref def="dt-maxInclusive"/> or <termref def="dt-maxExclusive"/>
are among <propref ref="defn-facets"/>, otherwise
<termref def="dt-bounded"/> is <emph>false</emph> and
<termref def="dt-cardinality"/> is <emph>countably infinite</emph>,
<termref def="dt-numeric"/> and <termref def="dt-ordered"/>
are inherited from <propref ref="defn-basetype"/>.
</p>
<p>
If
<propref ref="defn-variety"/> is 
<termref def="dt-list"/>
then <termref def="dt-bounded"/> is <emph>true</emph> and
<termref def="dt-cardinality"/> is <emph>finite</emph> if
<termref def="dt-length"/> or both of
<termref def="dt-minLength"/> and <termref def="dt-maxLength"/>
are among <propref ref="defn-facets"/>, otherwise
<termref def="dt-bounded"/> is <emph>false</emph> and 
<termref def="dt-cardinality"/> is <emph>countably infinite</emph>,
<termref def="dt-numeric"/> and <termref def="dt-ordered"/> are <emph>false</emph>.
</p>
<p>
If
<propref ref="defn-variety"/> is <termref def="dt-union"/>
then
<termref def="dt-bounded"/> is <emph>true</emph> if every member
of <propref ref="defn-memberTypes"/> is <termref def="dt-bounded"/>
and all members of <propref ref="defn-memberTypes"/> share a common
ancestor and is <emph>false</emph> otherwise,
<termref def="dt-cardinality"/> is <emph>finite</emph> if the
<termref def="dt-cardinality"/> of every member of
<propref ref="defn-memberTypes"/> is <emph>finite</emph> and
is <emph>countably infinite</emph> otherwise,
<termref def="dt-ordered"/> is <emph>true</emph> if every member of
<propref ref="defn-memberTypes"/> is <termref def="dt-ordered"/> and
all members of <propref ref="defn-memberTypes"/> share a common
ancestor and is <emph>false</emph> otherwise,
<termref def="dt-numeric"/> are <emph>true</emph> if every member of
<propref ref="defn-memberTypes"/> is <termref def="dt-numeric"/> and
is <emph>false</emph> otherwise.
</p>

<constraintnote type="cos" id="cos-applicable-facets">
<head>applicable facets</head>

<p>
The <termref def="dt-constraining-facet"/>s which are allowed
to be members of <propref ref="defn-facets"/> are dependent on
<propref ref="defn-basetype"/> as specified in the following table:
</p>
<applicable-facets/>
</constraintnote>

<constraintnote type="cos" id="cos-list-of-atomic">
<head>list of atomic</head>
<p>
If <propref ref="defn-variety"/> is <termref def="dt-list"/>, then
the <propref ref="defn-variety"/> of <propref ref="defn-itemType"/>
&nbsp;<termref def="dt-must"/> be <termref def="dt-atomic"/> or
<termref def="dt-union"/>.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-datatype-valid">
<head>Datatype Valid</head>
<p>
A string is datatype-valid with respect to a datatype definition if:
</p>
<olist>
<item>
<p>
it <termref def="dt-match"/>es a literal in the
<termref def="dt-lexical-space"/> of the datatype, determined as follows:
<olist>
<item>
<p>
if <propref ref="defn-variety"/> is <termref def="dt-atomic"/> then
the string must <termref def="dt-match"/> a literal in the
<termref def="dt-lexical-space"/> of <propref ref="defn-basetype"/>
</p>
</item>
<item>
<p>
if <propref ref="defn-variety"/> is <termref def="dt-list"/> then
the string must be a sequence of white space separated tokens, each of
which <termref def="dt-match"/>es a literal in the
<termref def="dt-lexical-space"/> of <propref ref="defn-itemType"/>
</p>
</item>
<item>
<p>
if <propref ref="defn-variety"/> is <termref def="dt-union"/> then
the string must <termref def="dt-match"/> a literal in the
<termref def="dt-lexical-space"/> of at least one member of
<propref ref="defn-memberTypes"/>
</p>
</item>
</olist>
</p>
</item>
<item>
<p>
the value denoted by the literal <termref def="dt-match"/>ed in the previous step
is a member of the <termref def="dt-value-space"/> of the datatype, as determined
by it being <specref ref="cvc-facet-valid"/>
with respect to each member of <propref ref="defn-facets"/>.
</p>
<!--
<olist>
<item>
<p>
if <propref ref='defn-variety'/> is <termref def='dt-atomic'/> then the
value is a member of the <termref def="dt-value-space"/> of the
<propref ref="defn-primitive"/> and is <specref ref="cvc-facet-valid"/>
with respect to each member of <propref ref="defn-facets"/>.
</p>
</item>
<item>
<p>
<ednote><edtext>needs work</edtext></ednote>
If <propref ref='defn-variety'/> is <termref def='dt-list'/> then
each value denoted by each token in the 
the member of the <termref def="dt-value-space"/> of the
<propref ref="defn-itemType"/> denoted by each token in the literal is
<specref ref="cvc-facet-valid"/> with respect to each member of <propref ref="defn-facets"/>.
</p>
</item>
<item>
<p>
<ednote><edtext>needs work</edtext></ednote>
If <propref ref='defn-variety'/> is <termref def='dt-union'/> then
the value 
member of the <termref def="dt-value-space"/> of the
<propref ref="defn-itemType"/> denoted by each token in the literal is
<specref ref="cvc-facet-valid"/> with respect to each member of <propref ref="defn-facets"/>.
</p>
</item>
</olist>
</p>
-->
</item>
</olist>
</constraintnote>
</div2>

<div2 id="dc-facets">
<head>Constraining facets</head>
<p>
This section provides the details of each
<termref def="dt-constraining-facet"/> component.
</p>
<p>
<termref def="dt-constraining-facet"/>s provide for:
</p>
<ulist>
<item>
<p>
Constraining the <termref def="dt-value-space"/> of a datatype
by specifying optional properties which serve to semantically
characterize the values in the <termref def="dt-value-space"/>.
</p>
</item>
</ulist>

<constraintnote type="cvc" id="cvc-facet-valid">
<head>Facet Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to a <termref def="dt-constraining-facet"/> component if:
</p>
<olist>
<item>
<p>
the value is facet-valid with respect to the particular
<termref def="dt-constraining-facet"/> as specified below.
</p>
</item>
</olist>
</constraintnote>

<div3 id="dc-length">
<head>length</head>
<p>
<termref def="dt-length"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values with a specific number of <emph>units of length</emph>,
where <emph>units of length</emph>
varies depending on <propref ref="defn-basetype"/>.
</p>
</item>
</ulist>

<compdef name="length" ref="dt-length">
<proplist>
<propdef id="length-value" name="value">
A <dtref ref="nonNegativeInteger"/>.
</propdef>
<propdef id="length-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="length-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="length-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-length"/> other than <propref ref="length-value"/>.
</p>

<constraintnote type="cos" id="length-minLength-maxLength">
<head>length and minLength or maxLength</head>
<p>
It is an <termref def="dt-error"/> for both
<compref ref="dc-length"/> and either of
<compref ref="dc-minLength"/> or <compref ref="dc-maxLength"/>
to be members of <propref ref="defn-facets"/>.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-length-valid">
<head>Length Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-length"/>, determined as follows:
</p>
<olist>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-atomic"/> then
<olist>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="string"/>, then the
length of the value, as measured in <xtermref href="&xmlspec;#dt-character">
character</xtermref>s
<termref def="dt-must"/> be equal to <propref ref="length-value"/>;
</p>
</item>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="binary"/>, then the
length of the value, as measured in octets of the binary data, 
<termref def="dt-must"/> be equal to <propref ref="length-value"/>;
</p>
</item>
</olist>
</p>
</item>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-list"/>,
then the length of the value, as measured
in list items, <termref def="dt-must"/> be equal to <propref ref="length-value"/>
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-minLength">
<head>minLength</head>

<p>
<termref def="dt-minLength"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values with at least a specific number of <emph>units of length</emph>,
where <emph>units of length</emph>
varies depending on <propref ref="defn-basetype"/>.
</p>
</item>
</ulist>

<compdef name="minLength" ref="dt-minLength">
<proplist>
<propdef id="minLength-value" name="value">
A <dtref ref="nonNegativeInteger"/>.
</propdef>
<propdef id="minLength-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="minLength-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="minLength-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-minLength"/> other than <propref ref="minLength-value"/>.
</p>

<constraintnote type="cos" id="minLength-less-than-equal-to-maxLength">
<head>minLength &lt;= maxLength</head>
<p>
If both <compref ref="dc-minLength"/> and <compref ref="dc-maxLength"/>
are members of <propref ref="defn-facets"/>, then the
<propref ref="minLength-value"/> of <compref ref="dc-minLength"/>
&nbsp;<termref def="dt-must"/> be less than or equal to the
<propref ref="maxLength-value"/> of <compref ref="dc-maxLength"/>.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-minLength-valid">
<head>minLength Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-minLength"/>, determined as follows:
</p>
<olist>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-atomic"/> then
<olist>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="string"/>, then the
length of the value, as measured in<xtermref href="&xmlspec;#dt-character">
character</xtermref>s
<termref def="dt-must"/> be greater than or equal to
<propref ref="minLength-value"/>;
</p>
</item>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="binary"/>, then the
length of the value, as measured in octets of the binary data, 
<termref def="dt-must"/> be greater than or equal to
<propref ref="minLength-value"/>;
</p>
</item>
</olist>
</p>
</item>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-list"/>,
then the length of the value, as measured
in list items, <termref def="dt-must"/> be greater than or equal
to <propref ref="minLength-value"/>
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-maxLength">
<head>maxLength</head>

<p>
<termref def="dt-maxLength"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values with at most a specific number of <emph>units of length</emph>,
where <emph>units of length</emph>
varies depending on <propref ref="defn-basetype"/>.
</p>
</item>
</ulist>

<compdef name="maxLength" ref="dt-maxLength">
<proplist>
<propdef id="maxLength-value" name="value">
A <dtref ref="nonNegativeInteger"/>.
</propdef>
<propdef id="maxLength-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="maxLength-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="maxLength-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-maxLength"/> other than <propref ref="maxLength-value"/>.
</p>

<constraintnote type="cvc" id="cvc-maxLength-valid">
<head>maxLength Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-maxLength"/>, determined as follows:
</p>
<olist>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-atomic"/> then
<olist>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="string"/>, then the
length of the value, as measured in <xtermref href="&xmlspec;#dt-character">
character</xtermref>s
<termref def="dt-must"/> be less than or equal to
<propref ref="maxLength-value"/>;
</p>
</item>
<item>
<p>
if <propref ref="defn-primitive"/> is <dtref ref="binary"/>, then the
length of the value, as measured in octets of the binary data, 
<termref def="dt-must"/> be less than or equal to <propref ref="maxLength-value"/>;
</p>
</item>
</olist>
</p>
</item>
<item>
<p>
if the <propref ref="defn-variety"/> is <termref def="dt-list"/>,
then the length of the value, as measured
in list items, <termref def="dt-must"/> be less than or equal to
<propref ref="maxLength-value"/>
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-pattern">
<head>pattern</head>

<p>
<termref def="dt-pattern"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values that are denoted by literals which match a specific
<termref def="dt-regex"/>.
</p>
</item>
</ulist>

<compdef name="pattern" ref="dt-pattern">
<proplist>
<propdef id="pattern-value" name="value">
A <termref def="dt-regex"/>.
</propdef>
<!-- <propdef id="pattern-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>  -->
<propdef id="pattern-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<!-- <p>
If <propref ref='pattern-fixed'/> is <emph>true</emph>, then types for which
the current type is the <propref ref='defn-basetype'/> cannot specify a
value for <compref ref='dc-pattern'/> other than <propref ref='pattern-value'/>.
</p>  -->
<!--
<ednote>
<name>PVB</name>
<edtext>
Fixing the pattern component makes sense (and would result in no further
restriction of the value space using any other facet), but the concept of "fixing"
one occurance of pattern facet doesn't seem to make sense.  So, I'm not sure
how this should be handled at the XML representation level.
</edtext>
</ednote>

<ednote>
<name>AM</name>
<edtext>
I have removed the "fixed" property from enumeration and pattern pending
resolution on how to handle these two cases.
</edtext>
</ednote>
-->

<constraintnote type="cvc" id="cvc-pattern-valid">
<head>pattern valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-pattern"/> if:
</p>
<olist>
<item>
<p>
the value is among the set of values denoted by literals which are
among the set of strings denoted by the <termref def="dt-regex"/>
specified in <propref ref="pattern-value"/>.
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-enumeration">
<head>enumeration</head>

<p>
<termref def="dt-enumeration"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to a specified set of values.
</p>
</item>
</ulist>

<compdef name="enumeration" ref="dt-enumeration">
<proplist>
<propdef id="enumeration-value" name="value">
A set of values from the <termref def="dt-value-space"/> of the
<propref ref="defn-basetype"/>.
</propdef>
<!-- <propdef id="enumeration-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef> -->
<propdef id="enumeration-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<!-- <p>
If <propref ref='enumeration-fixed'/> is <emph>true</emph>, then types for which
the current type is the <propref ref='defn-basetype'/> cannot specify a
value for <compref ref='dc-enumeration'/> other than <propref ref='enumeration-value'/>.
</p> -->
<!--
<ednote>
<name>PVB</name>
<edtext>
Fixing the enumeration component makes sense (and would result in no further
restriction of the value space using any other facet), but the concept of "fixing"
one occurance of enumeration facet doesn't seem to make sense.  So, I'm not sure
how this should be handled at the XML representation level.
</edtext>
</ednote>

<ednote>
<name>AM</name>
<edtext>
I have removed the "fixed" property from enumeration and pattern pending
resolution on how to handle these two cases.
</edtext>
</ednote>
-->
<constraintnote type="cvc" id="cvc-enumeration-valid">
<head>enumeration valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-enumeration"/> if:
</p>
<olist>
<item>
<p>
the value <termref def="dt-must"/> be one of the values specified in
<propref ref="enumeration-value"/>.
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-whiteSpace">
<head>whiteSpace</head>

<p>
<termref def="dt-whiteSpace"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> according to
the white space normalization rules.
<!--
<xspecref href='&xmlspec;#AVNormalize'>Attribute Value Normalization</xspecref>
rules in <bibref ref='XML'/>.
-->
</p>
</item>
</ulist>

<compdef name="whiteSpace" ref="dt-whiteSpace">
<proplist>
<propdef id="whiteSpace-value" name="value">
One of <code>{preserve, replace, collapse}</code>.
</propdef>
<propdef id="whiteSpace-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="whiteSpace-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="whiteSpace-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-whiteSpace"/> other than <propref ref="whiteSpace-value"/>.
</p>

<note>
<p>
There are no <termref def="dt-cvc"/>s associated <termref def="dt-whiteSpace"/>.
For more information, see the
discussion on white space normalization in
<xspecref href="&xsdl;#components">Schema Component Details</xspecref>
in <bibref ref="structural-schemas"/>.
</p>
</note>
</div3>

<div3 id="dc-maxInclusive">
<head>maxInclusive</head>

<p>
<termref def="dt-maxInclusive"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific <emph>inclusive</emph>&nbsp;<termref def="dt-upper-bound"/>.
</p>
</item>
</ulist>

<compdef name="maxInclusive" ref="dt-maxInclusive">
<proplist>
<propdef id="maxInclusive-value" name="value">
A value from the <termref def="dt-value-space"/> of the
<propref ref="defn-basetype"/>.
</propdef>
<propdef id="maxInclusive-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="maxInclusive-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="maxInclusive-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-maxInclusive"/> other than <propref ref="maxInclusive-value"/>.
</p>

<constraintnote type="cos" id="minInclusive-less-than-equal-to-maxInclusive">
<head>minInclusive &lt;= maxInclusive</head>
<p>
It is an <termref def="dt-error"/> for the value specified for
<termref def="dt-minInclusive"/> to be greater than the value
specified for <termref def="dt-maxInclusive"/> for the same datatype.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-maxInclusive-valid">
<head>maxInclusive Valid</head>
<p>
A value in an <termref def="dt-ordered"/>&nbsp;<termref def="dt-value-space"/>
is facet-valid with respect to <termref def="dt-maxInclusive"/>, determined as
follows:
</p>
<olist>
<item>
<p>
if the <termref def="dt-numeric"/> property in
<propref ref="defn-fund-facets"/> is <emph>true</emph>, then the value
<termref def="dt-must"/> be numerically less than or
equal to <propref ref="maxInclusive-value"/>;
</p>
</item>
<item>
<p>
if the <termref def="dt-numeric"/> property in 
<propref ref="defn-fund-facets"/> is <emph>false</emph> (i.e.,
<propref ref="defn-basetype"/> is one of the date and time related
datatypes), then the value <termref def="dt-must"/> be chronologically
less than or equal to <propref ref="maxInclusive-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-maxExclusive">
<head>maxExclusive</head>

<p>
<termref def="dt-maxExclusive"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific <emph>exclusive</emph> <termref def="dt-upper-bound"/>.
</p>
</item>
</ulist>

<compdef name="maxExclusive" ref="dt-maxExclusive">
<proplist>
<propdef id="maxExclusive-value" name="value">
A value from the <termref def="dt-value-space"/> of the
<propref ref="defn-basetype"/>.
</propdef>
<propdef id="maxExclusive-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="maxExclusive-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="maxExclusive-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-maxExclusive"/> other than <propref ref="maxExclusive-value"/>.
</p>

<constraintnote type="cos" id="maxInclusive-maxExclusive">
<head>maxInclusive and maxExclusive</head>
<p>
It is an <termref def="dt-error"/> for both
<termref def="dt-maxInclusive"/> and <termref def="dt-maxExclusive"/>
to be specified for the same datatype.
</p>
</constraintnote>

<constraintnote type="cos" id="minExclusive-less-than-equal-to-maxExclusive">
<head>minExclusive &lt;= maxExclusive</head>
<p>
It is an <termref def="dt-error"/> for the value specified for
<termref def="dt-minExclusive"/> to be greater than the value
specified for <termref def="dt-maxExclusive"/> for the same datatype.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-maxExclusive-valid">
<head>maxExclusive Valid</head>
<p>
A value in an <termref def="dt-ordered"/>&nbsp;<termref def="dt-value-space"/>
is facet-valid with respect to <termref def="dt-maxExclusive"/>, determined
as follows:
</p>
<olist>
<item>
<p>
if the <termref def="dt-numeric"/> property in
<propref ref="defn-fund-facets"/> is <emph>true</emph>, then the
value <termref def="dt-must"/> be numerically less than
<propref ref="maxExclusive-value"/>;
</p>
</item>
<item>
<p>
if the <termref def="dt-numeric"/> property in 
<propref ref="defn-fund-facets"/> is <emph>false</emph> (i.e.,
<propref ref="defn-basetype"/> is one of the date and time related
datatypes), then the value <termref def="dt-must"/> be chronologically
less than <propref ref="maxExclusive-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-minExclusive">
<head>minExclusive</head>

<p>
<termref def="dt-minExclusive"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific <emph>exclusive</emph> <termref def="dt-lower-bound"/>.
</p>
</item>
</ulist>

<compdef name="minExclusive" ref="dt-minExclusive">
<proplist>
<propdef id="minExclusive-value" name="value">
A value from the <termref def="dt-value-space"/> of the
<propref ref="defn-basetype"/>.
</propdef>
<propdef id="minExclusive-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="minExclusive-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="minExclusive-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-minExclusive"/> other than <propref ref="minExclusive-value"/>.
</p>

<constraintnote type="cos" id="minInclusive-minExclusive">
<head>minInclusive and minExclusive</head>
<p>
It is an <termref def="dt-error"/> for both
<termref def="dt-minInclusive"/> and <termref def="dt-minExclusive"/>
to be specified for the same datatype.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-minExclusive-valid">
<head>minExclusive Valid</head>
<p>
A value in an <termref def="dt-ordered"/>&nbsp;<termref def="dt-value-space"/>
is facet-valid with respect to <termref def="dt-minExclusive"/> if:
</p>
<olist>
<item>
<p>
if the <termref def="dt-numeric"/> property in
<propref ref="defn-fund-facets"/> is <emph>true</emph>, then the
value <termref def="dt-must"/> be numerically greater than
<propref ref="minExclusive-value"/>;
</p>
</item>
<item>
<p>
if the <termref def="dt-numeric"/> property in 
<propref ref="defn-fund-facets"/> is <emph>false</emph> (i.e.,
<propref ref="defn-basetype"/> is one of the date and time related
datatypes), then the value <termref def="dt-must"/> be chronologically
greater than <propref ref="minExclusive-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-minInclusive">
<head>minInclusive</head>

<p>
<termref def="dt-minInclusive"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific <emph>inclusive</emph> <termref def="dt-lower-bound"/>.
</p>
</item>
</ulist>

<compdef name="minInclusive" ref="dt-minInclusive">
<proplist>
<propdef id="minInclusive-value" name="value">
A value from the <termref def="dt-value-space"/> of the
<propref ref="defn-basetype"/>.
</propdef>
<propdef id="minInclusive-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="minInclusive-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="minInclusive-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-minInclusive"/> other than <propref ref="minInclusive-value"/>.
</p>

<constraintnote type="cvc" id="cvc-minInclusive-valid">
<head>minInclusive Valid</head>
<p>
A value in an <termref def="dt-ordered"/>&nbsp;<termref def="dt-value-space"/>
is facet-valid with respect to <termref def="dt-minInclusive"/> if:
</p>
<olist>
<item>
<p>
if the <termref def="dt-numeric"/> property in
<propref ref="defn-fund-facets"/> is <emph>true</emph>, then the
value <termref def="dt-must"/> be numerically greater than or equal to 
<propref ref="minInclusive-value"/>;
</p>
</item>
<item>
<p>
if the <termref def="dt-numeric"/> property in 
<propref ref="defn-fund-facets"/> is <emph>false</emph> (i.e.,
<propref ref="defn-basetype"/> is one of the date and time related
datatypes), then the value <termref def="dt-must"/> be chronologically
greater than or equal to <propref ref="minInclusive-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-precision">
<head>precision</head>

<p>
<termref def="dt-precision"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific maximum number of decimal digits (#x30-#x39).
</p>
</item>
</ulist>

<compdef name="precision" ref="dt-precision">
<proplist>
<propdef id="precision-value" name="value">
A <dtref ref="positiveInteger"/>.
</propdef>
<propdef id="precision-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="precision-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="precision-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-precision"/> other than <propref ref="precision-value"/>.
</p>

<constraintnote type="cvc" id="cvc-precision-valid">
<head>precision Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-precision"/> if:
</p>
<olist>
<item>
<p>
the number of decimal digits in the value is less than or equal to
<propref ref="precision-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-scale">
<head>scale</head>

<p>
<termref def="dt-scale"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/> to values
with a specific maximum number of decimal digits in the fractional
part.
</p>
</item>
</ulist>

<compdef name="scale" ref="dt-scale">
<proplist>
<propdef id="scale-value" name="value">
A <dtref ref="nonNegativeInteger"/>.
</propdef>
<propdef id="scale-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="scale-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="scale-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-scale"/> other than <propref ref="scale-value"/>.
</p>

<constraintnote type="cos" id="scale-precision">
<head>scale less than or equal to precision</head>
<p>
It is an <termref def="dt-error"/> for <termref def="dt-scale"/> to
be greater than <termref def="dt-precision"/>.
</p>
</constraintnote>

<constraintnote type="cvc" id="cvc-scale-valid">
<head>scale Valid</head>
<p>
A value in a <termref def="dt-value-space"/> is facet-valid with
respect to <termref def="dt-scale"/> if:
</p>
<olist>
<item>
<p>
the number of decimal digits in the fractional part of the
value is less than or equal to <propref ref="scale-value"/>;
</p>
</item>
</olist>
</constraintnote>
</div3>

<div3 id="dc-encoding">
<head>encoding</head>

<p>
<termref def="dt-encoding"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining the <termref def="dt-lexical-space"/> of 
datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>
to a specified form.
</p>
</item>
</ulist>

<compdef name="encoding" ref="dt-encoding">
<proplist>
<propdef id="encoding-value" name="value">
One of {<pt>hex</pt>, <pt>base64</pt>}.
</propdef>
<propdef id="encoding-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="encoding-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="encoding-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-encoding"/> other than <propref ref="encoding-value"/>.
</p>

<note>
<p>
There are no <termref def="dt-cvc"/>s associated with <termref def="dt-encoding"/>.
<compref ref="dc-encoding"/> determines the <termref def="dt-lexical-space"/>
of datatypes <termref def="dt-derived"/> from <dtref ref="binary"/> without
constraining the <termref def="dt-value-space"/>.
</p>
</note>
</div3>

<div3 id="dc-duration">
<head>duration</head>

<p>
<termref def="dt-duration"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values of a specific duration of time.
</p>
</item>
</ulist>

<compdef name="duration" ref="dt-duration">
<proplist>
<propdef id="duration-value" name="value">
A <dtref ref="timeDuration"/>.
</propdef>
<propdef id="duration-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="duration-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="duration-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-duration"/> other than <propref ref="duration-value"/>.
</p>

<note>
<p>
There are no <termref def="dt-cvc"/>s associated <termref def="dt-duration"/>.
</p>
</note>
</div3>

<div3 id="dc-period">
<head>period</head>
<p>
<termref def="dt-period"/> provides for:
</p>
<ulist>
<item>
<p>
Constraining a <termref def="dt-value-space"/>
to values of a specific frequency of recurrence.
</p>
</item>
</ulist>

<compdef name="period" ref="dt-period">
<proplist>
<propdef id="period-value" name="value">
A <dtref ref="timeDuration"/>.
</propdef>
<propdef id="period-fixed" name="fixed">
A <dtref ref="boolean"/>.
</propdef>
<propdef id="period-annotation" name="annotation">
Optional.  An <xspecref href="&xsdl;#Annotation">annotation</xspecref>.
</propdef>
</proplist>
</compdef>

<p>
If <propref ref="period-fixed"/> is <emph>true</emph>, then types for which
the current type is the <propref ref="defn-basetype"/> cannot specify a
value for <compref ref="dc-period"/> other than <propref ref="period-value"/>.
</p>

<note>
<p>
There are no <termref def="dt-cvc"/>s associated <termref def="dt-period"/>.
</p>
</note>
</div3>
</div2>
</div1>

<div1 id="xr-datatype-definitions">
<head>XML representation of datatype definitions</head>
<p>
The sections below define correspondences between element information
items and datatype definition components.  All the element information
items in the XML representation of a datatype definition are in the
XML Schema namespace, that is their
<xpropref href="http://www.w3.org/TR/xml-infoset#infoitem.element">
namespace URI</xpropref> is <code>http://www.w3.org/2000/10/XMLSchema</code>.
</p>
<p>
Throughout the following sections, the &i-value; of an attribute
information item or the &i-children; of an element information item means
a string composed of, in order, the &i-ccode; of each character information
item in the &i-attrChildren; of that attribute information item or in the
&i-children; of that element information item respectively.
</p>
<div2 id="xr-defn">
<head>XML representation of datatype definitions</head>

<p>
The XML representation for a <compref ref="dc-defn"/> schema component
is a <eltref ref="simpleType"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>
<reprdef eltname="simpleType">
 <reprelt eltname="simpleType"/>
<reprcomp abstract="Datatype Definition" ref="dc-defn">
<propmap name="defn-name">
The value of the <code>name</code>&nbsp;&i-attribute;, if present,
otherwise <xtermref href="&xsdl;#key-null">null</xtermref>
</propmap>
<propmap name="defn-target-namespace">
The value of the <code>targetNamespace</code> &i-attribute;
of the parent <code>schema</code> element information item.
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<!--
<reprdef eltname='simpleType'>
 <reprelt eltname="simpleType"/>
 <reprelt eltname="restriction"/>
 <reprelt eltname="list"/>
 <reprelt eltname="union"/>
<reprcomp abstract="Datatype Definition" ref="dc-defn">
<propmap name="defn-name">
The value of the <code>name</code>&nbsp;&i-attribute;, if present,
otherwise <xtermref href="&xsdl;#key-null">null</xtermref>
</propmap>
<propmap name="defn-target-namespace">
The value of the <code>targetNamespace</code> &i-attribute;
of the parent <code>schema</code> element information item.
</propmap>
<propmap name="defn-variety">
<pt>list</pt> if the immediate &i-child; of <code>simpleType</code> (or the
<propref ref='defn-variety'/> of <propref ref="defn-basetype"/> or any of its
ancestors) is <code>list</code> is <pt>list</pt>; else <pt>union</pt> if the
immediate &i-child; of <code>simpleType</code>  (or the
<propref ref='defn-variety'/> of <propref ref="defn-basetype"/> or any of its
ancestors) is <code>union</code>; otherwise <pt>atomic</pt>
</propmap>
<propmap name="defn-facets">
The union of the set of facet components corresponding to the
facet &i-children; of the <code>restriction</code>.
</propmap>
<propmap name="defn-basetype">
If <propref ref='defn-variety'/> is <termref def='dt-list'/> then the value
of the <code>type</code> &i-attribute;; else if <propref ref='defn-variety'/>
is <termref def='dt-union'/>, then the list of <propref ref='defn-basetype'/> from
the <code>simpleType</code> &i-children;; else the value of the <code>base</code>
&i-attribute; of the <code>restriction</code> &i-child;
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
-->
<p>
A <termref def="dt-derived"/> datatype can be <termref def="dt-derived"/>
from a <termref def="dt-primitive"/> datatype or another
<termref def="dt-derived"/> datatype by one of three means:
by <emph>restriction</emph>, by <emph>list</emph> or by <emph>union</emph>.
</p>
<div3 id="derivation-by-restriction">
<head>Derivation by restriction</head>
<reprdef eltname="restriction">
<reprelt eltname="restriction"/>
<reprcomp abstract="Datatype Definition" ref="dc-defn">
<propmap name="defn-variety">
The value of <propref ref="defn-variety"/> of <propref ref="defn-basetype"/>
</propmap>
<propmap name="defn-facets">
The union of the set of facet components corresponding to the
facet &i-children;.
</propmap>
<propmap name="defn-basetype">
Either the <code>base</code> &i-attribute; or the
<code>simpleType</code> &i-children;, whichever is present.
</propmap>
</reprcomp>
</reprdef>
<constraintnote type="src" id="src-restriction-base-or-simpleType">
<head>base attribute or simpleType child</head>
<p>
Either the <code>base</code> &i-attribute; or the
<code>simpleType</code> &i-child; must be present, but not both.
</p>
</constraintnote>
<p>
One <!--An <termref def="dt-atomic"/>-->datatype can be <termref def="dt-derived"/>
from another <!-- <termref def="dt-atomic"/>--> datatype by restricting its
<termref def="dt-value-space"/> and, consequently, its
<termref def="dt-lexical-space"/>.  Restriction of the <termref def="dt-value-space"/>
is accomplished through the specification of values for one or more
<termref def="dt-constraining-facet"/>s.
</p>
<p>
<termdef id="dt-basetype" term="base type">Every
datatype that is <termref def="dt-derived"/> by <term>restriction</term>
is defined in terms of an existing datatype, referred to as its
<term>base type</term>. <term>base type</term>s can be either
<termref def="dt-primitive"/> or <termref def="dt-derived"/>.
</termdef>
</p>
<p>
<note role="example">
<p>
An electronic commerce schema might define a datatype called
<emph>Sku</emph> (the barcode number that appears on products) from the
<termref def="dt-built-in"/> datatype <dtref ref="string"/> by
supplying a value for the <termref def="dt-pattern"/> facet.
</p>
<eg><![CDATA[<simpleType name='Sku'>
    <restriction base='string'>
      <pattern value='\d{3}-[A-Z]{2}'/>
    </restriction>
</simpleType>]]></eg>
<p>
In this case, <emph>Sku</emph> is the name of the new
<termref def="dt-user-derived"/> datatype, <dtref ref="string"/> is
its <termref def="dt-basetype"/> and <termref def="dt-pattern"/>
is the facet.
</p>
</note>
</p>
</div3>

<div3 id="derivation-by-list">
<head>Derivation by list</head>
<reprdef eltname="list">
 <reprelt eltname="list"/>
<reprcomp abstract="Datatype Definition" ref="dc-defn">
<propmap name="defn-variety">
list
</propmap>
<propmap name="defn-itemType">
The value of the <code>itemType</code>&nbsp;&i-attribute;
</propmap>
</reprcomp>
</reprdef>
<constraintnote type="src" id="src-list-itemType-or-simpleType">
<head>itemType attribute or simpleType child</head>
<p>
Either the <code>itemType</code> &i-attribute; or the
<code>simpleType</code> &i-child; must be present, but not both.
</p>
</constraintnote>
<p>
A <termref def="dt-list"/> datatype must be <termref def="dt-derived"/>
from an <termref def="dt-atomic"/> or a <termref def="dt-list"/> datatype,
known as the
<termref def="dt-itemType"/> of the <termref def="dt-list"/> datatype.
This yields a datatype whose <termref def="dt-value-space"/> is composed of
finite sequences of values from the <termref def="dt-value-space"/> of the
<termref def="dt-itemType"/> and whose <termref def="dt-lexical-space"/> is
composed of white space separated lists of literals of the
<termref def="dt-itemType"/>.
</p>
<note role="example">
<p>
A system might want to store lists of floating point values. 
</p>
<eg><![CDATA[<simpleType name='listOfFloat'>
  <list itemType='float'/>
</simpleType>
]]></eg>
<p>
In this case, <emph>listOfFloat</emph> is the name of the new
<termref def="dt-user-derived"/> datatype, <dtref ref="float"/> is its
<termref def="dt-itemType"/> and <termref def="dt-list"/> is the
derivation method.
</p>
</note>
<p>
As mentioned in <specref ref="list-datatypes"/>,
when a datatype is <termref def="dt-derived"/> from a
<termref def="dt-list"/> datatype, the following
<termref def="dt-constraining-facet"/>s can be used:
</p>
<ulist>
<item><p><termref def="dt-length"/></p></item>
<item><p><termref def="dt-maxLength"/></p></item>
<item><p><termref def="dt-minLength"/></p></item>
<item><p><termref def="dt-enumeration"/></p></item>
<item><p><termref def="dt-whiteSpace"/></p></item>
</ulist>
<p>
regardless of the <termref def="dt-constraining-facet"/>s that are applicable
to the <termref def="dt-atomic"/> datatype that serves as the
<termref def="dt-itemType"/> of the <termref def="dt-list"/>.
</p>
<p>
For each of the above <termref def="dt-facet"/>s, the
<emph>unit of length</emph> is measured in number of list items.
</p>
</div3>
<div3 id="derivation-by-union">
<head>Derivation by union</head>
<reprdef eltname="union">
 <reprelt eltname="union"/>
<reprcomp abstract="Datatype Definition" ref="dt-union">
<propmap name="defn-variety">
union
</propmap>
<propmap name="defn-memberTypes">
The type definitions resolved to by the items in the value of
the <code>memberTypes</code>&nbsp;&i-attribute;, if any, in order,
followed by the type definitions corresponding to the
<code>simpleType</code>&nbsp;&i-children;, if any, in order.
</propmap>
</reprcomp>
</reprdef>
<constraintnote type="src" id="src-union-memberTypes-or-simpleTypes">
<head>memberTypes attribute or simpleType children</head>
<p>
Either the <code>memberTypes</code> &i-attribute; must be non-empty or
there must be at least one <code>simpleType</code> &i-child;.
</p>
</constraintnote>
<!--
is this constrain really necessary?  For instance, what is there is
one type in memberTypes and 2 more simpleType children...what would be
wrong with that?
-->
<p>
A <termref def="dt-union"/> datatype can be <termref def="dt-derived"/>
from two or more <termref def="dt-atomic"/>, <termref def="dt-list"/> or
other <termref def="dt-union"/> datatypes, known as the <termref def="dt-memberTypes"/>
of that <termref def="dt-union"/> datatype.
</p>
<note role="example">
<p>
An example, taken from a typical display oriented text markup language,
might want to express font sizes as an integer between 8 and 72, or with
one of the tokens "small", "medium" or "large".  The <termref def="dt-union"/>
type definition below would accomplish that.
</p>
<eg><![CDATA[
<xsd:attribute name="size">
  <xsd:simpleType>
    <xsd:union>
      <xsd:simpleType>
        <xsd:restriction base="xsd:positiveInteger">
          <xsd:minInclusive value="8"/>
          <xsd:maxInclusive value="72"/>
        </xsd:restriction>
      </xsd:simpleType>
      <xsd:simpleType>
        <xsd:restriction base="xsd:NMTOKEN">
          <xsd:enumeration value="small"/>
          <xsd:enumeration value="medium"/>
          <xsd:enumeration value="large"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:union>
  </xsd:simpleType>
</xsd:attribute>
]]></eg>
<eg><![CDATA[
<p>
<font size='large'>A header</font>
</p>
<p>
<font size='12'>this is a test</font>
</p>
]]></eg>
</note>
<p>
As mentioned in <specref ref="union-datatypes"/>,
when a datatype is <termref def="dt-derived"/> from a
<termref def="dt-union"/> datatype, the only following
<termref def="dt-constraining-facet"/>s can be used:
</p>
<ulist>
<item><p><termref def="dt-pattern"/></p></item>
<item><p><termref def="dt-enumeration"/></p></item>
</ulist>
<p>
regardless of the <termref def="dt-constraining-facet"/>s that are
applicable to the datatypes that participate in the <termref def="dt-union"/>
</p>
</div3>
</div2>

<div2 id="xr-facets">
<head>Constraining facets</head>
<p>
This section discusses the details of the XML Representation for specifying
<termref def="dt-constraining-facet"/>s in
a datatype definition.
</p>

<div3 id="xr-length">
<head>length</head>

<p>
The XML representation for a <compref ref="dc-length"/> schema
component is a <eltref ref="length"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="length">
<reprelt eltname="length"/>
<reprcomp abstract="length" ref="dc-scale">
<propmap name="length-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="length-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>

<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype to represent product codes which must be
exactly 8 characters in length.  By fixing the value of the
<term>length</term> facet we ensure that types derived from productCode can
change or set the values of other facets, such as <term>pattern</term>, but
cannot change the length.  
</p>
<eg><![CDATA[<simpleType name='productCode'>
   <restriction base='string'>
     <length value='8' fixed='true'/>
   </restriction>
</simpleType>]]></eg>
</note>

</div3>

<div3 id="xr-minLength">
<head>minLength</head>

<p>
The XML representation for a <compref ref="dc-minLength"/> schema
component is a <eltref ref="minLength"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="minLength">
<reprelt eltname="minLength"/>
<reprcomp abstract="minLength" ref="dc-scale">
<propmap name="minLength-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="minLength-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which requires strings to have at least one character (i.e.,
the empty string is not in the <termref def="dt-value-space"/>
of this datatype).
</p>
<eg><![CDATA[<simpleType name='non-empty-string'>
  <restriction base='string'>
    <minLength value='1'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-maxLength">
<head>maxLength</head>

<p>
The XML representation for a <compref ref="dc-maxLength"/> schema
component is a <eltref ref="maxLength"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="maxLength">
<reprelt eltname="maxLength"/>
<reprcomp abstract="maxLength" ref="dc-scale">
<propmap name="maxLength-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="maxLength-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which might be used to accept form input with an upper limit
to the number of characters that are acceptable.
</p>
<eg><![CDATA[<simpleType name='form-input'>
  <restriction base='string'>
    <maxLength value='50'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-pattern">
<head>pattern</head>

<p>
The XML representation for a <compref ref="dc-pattern"/> schema
component is a <eltref ref="pattern"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="pattern">
<reprelt eltname="pattern"/>
<reprcomp abstract="pattern" ref="dc-scale">
<reprdep>
<propref ref="pattern-value"/>&nbsp;<termref def="dt-must"/> be a valid
<termref def="dt-regex"/>.
</reprdep>
<propmap name="pattern-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<!--
<propmap name="pattern-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
-->
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>

<constraintnote type="src" id="src-multiple-patterns">
<head>Multiple patterns</head>
<p>
If multiple <eltref ref="pattern"/> element information items appear as
&i-children; of a <eltref ref="simpleType"/>, the &i-value;s should
be combined as if they appeared in a single
<termref def="dt-regex"/> as separate
<termref def="dt-branch"/>es.
</p>
</constraintnote>

<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which is a better representation of postal codes in the
United States, by limiting strings to those which are matched by
a specific <termref def="dt-regex"/>.
</p>
<eg><![CDATA[<simpleType name='better-us-zipcode'>
  <restriction base='string'>
    <pattern value='[0-9]{5}(-[0-9]{4})?'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-enumeration">
<head>enumeration</head>

<p>
The XML representation for a <compref ref="dc-enumeration"/> schema
component is a <eltref ref="enumeration"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="enumeration">
<reprelt eltname="enumeration"/>
<reprcomp abstract="enumeration" ref="dc-enumeration">
<reprdep>
<propref ref="enumeration-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="enumeration-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<!--
<propmap name="enumeration-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
-->
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>

<constraintnote type="src" id="src-multiple-enumerations">
<head>Multiple enumerations</head>
<p>
If multiple <eltref ref="enumeration"/> element information items appear
as &i-children; of a <eltref ref="simpleType"/> the
<propref ref="enumeration-value"/> of the <compref ref="dc-enumeration"/>
component should be the set of all such &i-value;s.
</p>
</constraintnote>

<note role="example">
<p>
The following example is a datatype definition for a
<termref def="dt-user-derived"/> datatype which limits the values
of dates to the three US holidays enumerated. This datatype
definition would appear in a schema authored by an "end-user" and
shows how to define a datatype by enumerating the values in its
<termref def="dt-value-space"/>.  The enumerated values must be
type-valid literals for the <termref def="dt-basetype"/>.
</p>
<eg><![CDATA[<simpleType name='holidays'>
    <annotation>
        <documentation>some US holidays</documentation>
    </annotation>
    <restriction base='recurringDate'>
      <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>]]></eg>
</note>
</div3>

<!--
<p>
The following <termref def='dt-constraining'/> <termref def='dt-facet'/>s
apply only to datatypes whose <termref def='dt-value-space'/>s have
the <termref def='dt-ordered'/> property.
</p>
-->

<div3 id="xr-whiteSpace">
<head>whiteSpace</head>

<p>
The XML representation for a <compref ref="dc-whiteSpace"/> schema
component is a <eltref ref="whiteSpace"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="whiteSpace">
<reprelt eltname="whiteSpace"/>
<reprcomp abstract="whiteSpace" ref="dc-whiteSpace">
<reprdep>
<propref ref="whiteSpace-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="whiteSpace-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="whiteSpace-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>

<note role="example">
<p>
The following example is the datatype definition for
the <dtref ref="token"/>&nbsp;<termref def="dt-built-in"/>&nbsp;
<termref def="dt-derived"/>
datatype.
</p>
<eg><![CDATA[<simpleType name='token'>
    <restriction base='CDATA'>
      <whiteSpace value='collapse'/>
    </restriction>  
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-maxInclusive">
<head>maxInclusive</head>

<p>
The XML representation for a <compref ref="dc-maxInclusive"/> schema
component is a <eltref ref="maxInclusive"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="maxInclusive">
<reprelt eltname="maxInclusive"/>
<reprcomp abstract="maxInclusive" ref="dt-maxInclusive">
<reprdep>
<propref ref="maxInclusive-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="maxInclusive-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="maxInclusive-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note>
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which limits values to integers less than or equal to
100, using <termref def="dt-maxInclusive"/>.
</p>
<eg><![CDATA[<simpleType name='one-hundred-or-less'>
  <restriction base='integer'>
    <maxInclusive value='100'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-maxExclusive">
<head>maxExclusive</head>

<p>
The XML representation for a <compref ref="dc-maxExclusive"/> schema
component is a <eltref ref="maxExclusive"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="maxExclusive">
<reprelt eltname="maxExclusive"/>
<reprcomp abstract="maxExclusive" ref="dt-maxExclusive">
<reprdep>
<propref ref="maxExclusive-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="maxExclusive-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="maxExclusive-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note>
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which limits values to integers less than or equal to
100, using <termref def="dt-maxExclusive"/>.
</p>
<eg><![CDATA[<simpleType name='less-than-one-hundred-and-one'>
  <restriction base='integer'>
    <maxExclusive value='101'/>
  </restriction>
</simpleType>]]></eg>
<p>
Note that the
<termref def="dt-value-space"/> of this datatype is identical to
the previous one (named 'one-hundred-or-less').
</p>
</note>
</div3>

<div3 id="xr-minInclusive">
<head>minInclusive</head>

<p>
The XML representation for a <compref ref="dc-minInclusive"/> schema
component is a <eltref ref="minInclusive"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="minInclusive">
<reprelt eltname="minInclusive"/>
<reprcomp abstract="minInclusive" ref="dt-minInclusive">
<reprdep>
<propref ref="minInclusive-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="minInclusive-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="minInclusive-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note>
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which limits values to integers greater than or equal to
100, using <termref def="dt-minInclusive"/>.
</p>
<eg><![CDATA[<simpleType name='one-hundred-or-more'>
  <restriction base='integer'>
    <minInclusive value='100'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-minExclusive">
<head>minExclusive</head>

<p>
The XML representation for a <compref ref="dc-minExclusive"/> schema
component is a <eltref ref="minExclusive"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="minExclusive">
<reprelt eltname="minExclusive"/>
<reprcomp abstract="minExclusive" ref="dt-minExclusive">
<reprdep>
<propref ref="minExclusive-value"/>&nbsp;<termref def="dt-must"/> be a valid
value of the <propref ref="defn-basetype"/>.
</reprdep>
<propmap name="minExclusive-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="minExclusive-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note>
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which limits values to integers greater than or equal to
100, using <termref def="dt-minExclusive"/>.
</p>
<eg><![CDATA[<simpleType name='more-than-ninety-nine'>
  <restriction base='integer'>
    <minExclusive value='99'/>
  </restriction>
</simpleType>]]></eg>
<p>
Note that the
<termref def="dt-value-space"/> of this datatype is identical to
the previous one (named 'one-hundred-or-more').
</p>
</note>
</div3>

<!--
<p>
The following <termref def='dt-constraining'/> <termref def='dt-facet'/>s
apply only to datatypes whose <termref def='dt-value-space'/>s have
the <termref def='dt-numeric'/>
property.
</p>
-->

<div3 id="xr-precision">
<head>precision</head>

<p>
The XML representation for a <compref ref="dc-precision"/> schema
component is a <eltref ref="precision"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="precision">
<reprelt eltname="precision"/>
<reprcomp abstract="precision" ref="dc-precision">
<propmap name="precision-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="precision-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which could be used to represent monetary amounts, such as
in a financial management application which does not have figures
of $1M or more and only allows whole cents. This definition would appear
in a schema authored by an "end-user" and shows how to define a datatype by
specifying facet values which constrain the range of the
<termref def="dt-basetype"/> in a manner specific to the
<termref def="dt-basetype"/> (different than specifying max/min values
as before).
</p>
<eg><![CDATA[<simpleType name='amount'>
  <restriction base='decimal'>
    <precision value='8'/>
    <scale value='2' fixed='true'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-scale">
<head>scale</head>

<p>
The XML representation for a <compref ref="dc-scale"/> schema
component is a <eltref ref="scale"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="scale">
<reprelt eltname="scale"/>
<reprcomp abstract="scale" ref="dc-scale">
<propmap name="scale-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="scale-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
The following is the definition of a <termref def="dt-user-derived"/>
datatype which could be used to represent the magnitude
of a person's body temperature on the Celsius scale.
This definition would appear in a schema authored by an "end-user"
and shows how to define a datatype by specifying facet values which
constrain the range of the <termref def="dt-basetype"/>.
</p>
<eg><![CDATA[<simpleType name='celsiusBodyTemp'>
  <restriction base='decimal'>
    <precision value='4'/>
    <scale value='1'/>
    <minInclusive value='36.4'/>
    <maxInclusive value='40.5'/>
  </restriction>
</simpleType>
]]></eg>
</note>
</div3>

<div3 id="xr-encoding">
<head>encoding</head>

<p>
The XML representation for a <compref ref="dc-encoding"/> schema
component is an <eltref ref="encoding"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="encoding">
<reprelt eltname="encoding"/>
<reprcomp abstract="encoding" ref="dt-maxExclusive">
<propmap name="encoding-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="scale-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
The following example is a datatype definition for a
<termref def="dt-user-derived"/> datatype whose
<termref def="dt-value-space"/> is the set of binary streams of
length 4 octets (32 bits) and whose <termref def="dt-lexical-space"/>
is the set of base64 encodings of such binary streams.
This datatype definition would appear in a schema
authored by an "end-user" and shows how to define a datatype by
specifying multiple <termref def="dt-constraining-facet"/>s.
</p>
<eg><![CDATA[<simpleType name='myBinary'>
  <restriction base='binary'>
    <length value='4'/>
    <encoding value='base64'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<!--
<p>
The following <termref def='dt-constraining'/> <termref def='dt-facet'/>s
apply only to datatypes whose <termref def='dt-value-space'/>s have
the <termref def='dt-dateTime'/> property.
</p>
-->

<div3 id="xr-duration">
<head>duration</head>

<p>
The XML representation for a <compref ref="dc-duration"/> schema
component is a <eltref ref="duration"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="duration">
<reprelt eltname="duration"/>
<reprcomp abstract="duration" ref="dc-duration">
<propmap name="duration-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="duration-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
Suppose an health insurance company wanted to define the length of a hospital stay permitted
for the birth of a baby as two days. They might want to define a datatype as below.
</p>
<eg><![CDATA[<simpleType name='birthingStay'>
  <restriction base='timePeriod'>
    <duration value='P2D'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

<div3 id="xr-period">
<head>period</head>

<p>
The XML representation for a <compref ref="dc-period"/> schema
component is a <eltref ref="period"/> element information item. The
correspondences between the properties of the information item and
properties of the component are as follows:
</p>

<reprdef eltname="period">
<reprelt eltname="period"/>
<reprcomp abstract="period" ref="dc-period">
<propmap name="period-value">
The value of the <code>value</code> &i-attribute;
</propmap>
<propmap name="period-fixed">
The value of the <code>fixed</code> &i-attribute;, if present, otherwise false
</propmap>
<propmap name="defn-annotation">
The annotation corresponding to the <eltref ref="annotation"/>
element information item in the &i-children;, if present, otherwise
<xspecref href="&xsdl;#key-null">null</xspecref>
</propmap>
</reprcomp>
</reprdef>
<note role="example">
<p>
Suppose we wanted to define a day of the week i.e. a duration of one day
that recurs every 7 days.  This could be done as follows:
</p>
<eg><![CDATA[<simpleType name='dayOfWeek'>
  <restriction base='recurringDuration'>
    <duration value='P1D'/>
    <period value='P7D'/>
  </restriction>
</simpleType>]]></eg>
</note>
</div3>

</div2>
</div1>

<div1 id="conformance">
<head>Conformance</head>
<p>
This specification describes two levels of conformance for
datatype processors.  The first is
required of all processors.  Support for the other will depend on the
application environments for which the processor is intended.
</p>
<p>
<termdef id="dt-minimally-conforming" term="minimally conforming">
<term>Minimally conforming</term> processors <termref def="dt-must"/>
completely and correctly implement the <termref def="dt-cos"/> and
<termref def="dt-cvc"/>
.
</termdef>
</p>
<p>
<termdef id="dt-interchange" term="conformance to the XML Representation
of Schemas">
Processors which accept schemas in the form of XML documents as described
in <specref ref="xr-defn"/> are additionally said to provide
<term>conformance to the XML Representation of Schemas</term>,
and <termref def="dt-must"/>, when processing schema documents, completely and
correctly implement all
<termref def="dt-src"/>s
in this specification, and <termref def="dt-must"/> adhere exactly to the
specifications in <specref ref="xr-defn"/> for mapping the contents of such
documents to <xtermref href="&xsdl;#key-component">schema components</xtermref>
for use in validation.
</termdef>
</p>
<note>
<p>
By separating the conformance requirements relating to the concrete
syntax of XML schema documents, this specification admits processors
which validate using schemas stored in optimised binary representations,
dynamically created schemas represented as programming language data
structures, or implementations in which particular schemas are compiled
into executable code such as C or Java.  Such processors can be said to
be <termref def="dt-minimally-conforming">minimally conforming</termref>
but not necessarily in <termref def="dt-interchange">conformance to
the XML Representation of Schemas</termref>.
</p>
</note>
</div1>

</body>
<back>
<!--
<div1 id='builtins'>
<head>Schema for Builtin Datatypes (normative)</head>
<eg xml:space='preserve' text='builtins.xsd.txt'/>
</div1>
-->
<div1 id="schema">
<head>Schema for Datatype Definitions (normative)</head>
<eg xml:space="preserve" text="datatypes.xsd.txt"/>
</div1>
<div1 id="dtd-for-datatypeDefs">
<head>DTD for Datatype Definitions (non-normative)</head>
<eg xml:space="preserve" text="datatypes.dtd.txt"/>
</div1>
<div1>
<head>Datatypes and Facets</head>
<div2 id="app-fundamental-facets">
<head>Fundamental Facets</head>
<p>
The following table shows the values of the fundamental facets
for each <termref def="dt-built-in"/> datatype.
</p>
<fundamental-facets/>
</div2>
<div2 id="app-constraining-facets">
<head>Constraining Facets</head>
<p>
The <termref def="dt-constraining-facet"/>s are listed
below with all the <termref def="dt-primitive"/>
and <termref def="dt-derived"/> datatypes that they apply to.
</p>
<inverse-facets name="length"/>
<inverse-facets name="minLength"/>
<inverse-facets name="maxLength"/>
<inverse-facets name="pattern"/>
<inverse-facets name="enumeration"/>
<inverse-facets name="maxInclusive"/>
<inverse-facets name="maxExclusive"/>
<inverse-facets name="minInclusive"/>
<inverse-facets name="minExclusive"/>
<inverse-facets name="precision"/>
<inverse-facets name="scale"/>
<inverse-facets name="encoding"/>
<inverse-facets name="duration"/>
<inverse-facets name="period"/>
</div2>
</div1>
<div1 id="isoformats">
<head>ISO 8601 Date and Time Formats</head>
<div2 id="formatdetails">
<head>ISO 8601 Conventions</head>
<p>
The two <termref def="dt-primitive"/> datatypes described above,
<dtref ref="timeDuration"/>, <dtref ref="recurringDuration"/>, and the
five <termref def="dt-derived"/> datatypes <dtref ref="timeInstant"/>,
<dtref ref="date"/>, <dtref ref="time"/>, <dtref ref="timePeriod"/>, and
<dtref ref="recurringDate"/> use lexical formats inspired by
<bibref ref="ISO8601"/>.  This appendix provides more detail on the ISO
formats and discusses some deviations from them for the datatypes
defined in this specification.
</p>
<p>
<bibref ref="ISO8601"/> "specifies the representation of dates in the
Gregorian calendar and times and representations of periods of time".
The Gregorian calendar includes dates prior to 1582 (the year it came
into use as an ecclesiastical calendar).
It should be pointed out that the datatypes described in this
specification do not cover all the types of data covered by
<bibref ref="ISO8601"/>, nor do they support all the lexical
representations for those types of data.  
</p>
<p>
<bibref ref="ISO8601"/> lexical formats are described using "pictures"
in which characters are used in place of digits.  For 
<dtref ref="recurringDuration"/> and types derived from it, these characters
have the following meanings:
</p>
<ulist>
<item>
<p>
C -- represents a digit used in the thousands and hundreds components,
the "century" component, of the time element "year". Legal values are
from 0 to 9.
</p>
</item>
<item>
<p>
Y -- represents a digit used in the tens and units components of the time
element "year".  Legal values are from 0 to 9.
</p>
</item>
<item>
<p>
M -- represents a digit used in the time element "month".  The two
digits in a MM format can have values from 1 to 12.
</p>
</item>
<item>
<p>
D -- represents a digit used in the time element "day". The two digits
in a DD format can have values from 1 to 28 if the month value equals 2,
1 to 29 if the month value equals 2 and the year is a leap year, 1 to 30
if the month value equals 4, 6, 9 or 11, and 1 to 31 if the month value
equals 1, 3, 5, 7, 8, 10 or 12. 
</p>
</item>
<item>
<p>
h -- represents a digit used in the time element "hour". The two digits
in a hh format can have values from 0 to 23.
</p>
</item>
<item>
<p>
m -- represents a digit used in the time element "minute". The two digits
in a mm format can have values from 0 to 59.
</p>
</item>
<item>
<p>
s -- represents a digit used in the time element "second".  The two
digits in a ss format can have values from 0 to 60.  In the formats
described in this specification the whole number of seconds <termref def="dt-may"/>
be followed by decimal seconds to an arbitrary level of precision.
This is represented in the picture by "ss.sss".  A value of 60 is allowed
only in the case of leap seconds.
</p>
</item>
</ulist>
<p>
For all the information items indicated by the above characters, leading
zeros are required where indicated.
</p>
<p>
In addition to the above, certain characters are used as designators
and appear as themselves in lexical formats.
</p>
<ulist>
<item>
<p>
T -- is used as time designator to indicate the start of the
representation of the time of day in <dtref ref="recurringDuration"/>
and <dtref ref="timeInstant"/>
</p>
</item>
<item>
<p>
Z -- is used as time-zone designator, immediately (without a space)
following a data element expressing the time of day in Coordinated
Universal Time (UTC) in <dtref ref="recurringDuration"/>,
<dtref ref="timeInstant"/> and <dtref ref="time"/>
</p>
</item>
</ulist>
<p>In the lexical format for <dtref ref="timeDuration"/> the following
characters are also used as designators and appear as themselves in 
lexical formats:</p>
<ulist>
<item>
<p>P -- is used as the time duration designator, preceding a data element
representing a given duration of time.</p>
</item>
<item>
<p>Y -- follows the number of years in a time duration.</p></item>
<item><p>M -- follows the number of months or minutes in a time duration.</p></item>
<item><p>D -- follows the number of days in a time duration.</p></item>
<item><p>H -- follows the number of hours in a time duration.</p></item>
<item><p>S -- follows the number of seconds in a time duration.</p></item>
</ulist>  
<p>
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but 
allow an arbitrary integer.  Similarly, the value of the Seconds component
allows an arbitrary decimal.  Thus, the lexical format for
<dtref ref="timeDuration"/> and datatypes derived from it 
does not follow the alternative 
format of &sect; 5.5.3.2.1 of <bibref ref="ISO8601"/>.</p>
</div2>
<div2 id="truncatedformats">
<head>Truncated and Reduced Formats</head>
<p>
<bibref ref="ISO8601"/> supports a variety of "truncated" formats in
which some of the characters on the left of specific formats, for example,
the
century, can be omitted.
Truncated formats are, in
general, not permitted for the datatypes defined in this specification
with three exceptions.  The <dtref ref="time"/> datatype uses
a truncated format for <dtref ref="timeInstant"/>. By truncating the date
information we represent an instant of time that recurs every day.
Similarly, the <dtref ref="recurringDate"/> and <dtref ref="recurringDay"/>
datatypes use left-truncated formats for <dtref ref="date"/>.
</p>
<p>
<bibref ref="ISO8601"/> also supports a variety of "reduced" or right-truncated
formats in which some of the characters to the right of specific formats,
such as the
time specification, can be omitted.  Right truncated formats are also, in
general,
not permitted for the datatypes defined in this specification
with the following exceptions:
right-truncated representations of <dtref ref="timePeriod"/> are used as
lexical representations for <dtref ref="date"/>,  <dtref ref="month"/>,
<dtref ref="year"/> and <dtref ref="century"/>.
</p>
</div2>
<div2 id="deviantformats">
<head>Deviations from ISO 8601 Formats</head>
<div3 id="signallowed">
<head>Sign Allowed</head>
<p>
An optional minus sign is allowed immediately preceding, without a space,
the lexical representations for <dtref ref="timeDuration"/>, <dtref ref="timeInstant"/> and
<dtref ref="date"/>.
</p>
</div3>
<div3 id="noYearZero">
<head>No Year Zero</head>
<p>
The year "0000" is an illegal year value. 
</p>
</div3>
<div3 id="morethan9999years">
<head>More Than 9999 Years</head>
<p>
To accommodate year values greater than 9999, more than four digits are
allowed in the year representations of <dtref ref="recurringDuration"/>
and datatypes <termref def="dt-derived"/> from it. This follows
<bibref ref="ISO8601revision"/>.
</p>
</div3>
</div2>
</div1>

<div1 id="regexs">
<head>Regular Expressions</head>
<p>
A <termref def="dt-regex"/> <emph>R</emph> is a sequence of
characters that denote a <B>set of strings</B> <emph>L(R)</emph>.
When used to constrain a <termref def="dt-lexical-space"/>, a
<term>regular expression</term> <emph>R</emph> asserts that only strings
in <emph>L(R)</emph> are valid literals for values of that type.
</p>

<p>
<termdef id="dt-regex" term="regular expression">A
<term>regular expression</term> is composed from zero or more
<termref def="dt-branch"/>es, separated by <code>|</code> characters.
</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
For all <termref def="dt-branch"/>es <emph>S</emph>, and for all
<termref def="dt-regex"/>s <emph>T</emph>, valid
<termref def="dt-regex"/>s <emph>R</emph> are:
</th>
<th>
Denoting the set of strings <emph>L(R)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center">(empty string)</td>
  <td align="center">the set containing just the empty string
</td>
</tr>
<tr>
  <td align="center"><emph>S</emph></td>
  <td align="center">all strings in <emph>L(S)</emph></td>
</tr>
<tr>
  <td align="center"><emph>S</emph>|<emph>T</emph></td>
  <td align="center">all strings in <emph>L(S)</emph> and
  all strings in <emph>L(T)</emph></td>
</tr>
</tbody>
</table>

<p>
<termdef id="dt-branch" term="branch">A <term>branch</term> consists
of zero or more <termref def="dt-piece"/>s, concatenated together.
</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
For all <termref def="dt-piece"/>s <emph>S</emph>, and for all
<termref def="dt-branch"/>es <emph>T</emph>, valid
<termref def="dt-branch"/>es <emph>R</emph> are:
</th>
<th>
Denoting the set of strings <emph>L(R)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center"><emph>S</emph></td>
  <td align="center">all strings in <emph>L(S)</emph></td>
</tr>
<tr>
  <td align="center"><emph>S</emph><emph>T</emph></td>
  <td align="center">all strings <emph>st</emph> with <emph>s</emph> in
  <emph>L(S)</emph> and <emph>t</emph> in <emph>L(T)</emph></td>
</tr>
</tbody>
</table>

<p>
<termdef id="dt-piece" term="piece">A <term>piece</term> is an
<termref def="dt-atom"/>, possibly followed by a
<termref def="dt-quantifier"/>.
</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
For all <termref def="dt-atom"/>s <emph>S</emph> and non-negative
integers <emph role="eq">n</emph>, <emph role="eq">m</emph> such that
<emph role="eq">n &lt;= m</emph>, valid <termref def="dt-piece"/>s
<emph>R</emph> are:
</th>
<th>
Denoting the set of strings <emph>L(R)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center"><emph>S</emph></td>
  <td align="center">all strings in <emph>L(S)</emph></td>
</tr>
<tr>
  <td align="center"><emph>S</emph>?</td>
  <td align="center">the empty string, and all strings in
  <emph>L(S)</emph>.</td>
</tr>
<tr>
  <td align="center"><emph>S</emph>*</td>
  <td align="center">
  All strings in <emph>L(S?)</emph> and all strings <emph>st</emph>
  with <emph>s</emph> in <emph>L(S*)</emph>
  and <emph>t</emph> in <emph>L(S)</emph>. <emph>( all concatenations
  of zero or more strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>+</td>
  <td align="center">
  All strings <emph>st</emph> with <emph>s</emph> in <emph>L(S)</emph>
  and <emph>t</emph> in <emph>L(S*)</emph>.  <emph>( all concatenations
  of one or more strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>{n,m}</td>
  <td align="center">
  All strings <emph>st</emph> with <emph>s</emph> in <emph>L(S)</emph>
  and <emph>t</emph> in <emph>L(S{n-1,m-1})</emph>.  <emph>( All
sequences of at least n, and at most m, strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>{n}</td>
  <td align="center">
  All strings in <emph>L(S{n,n})</emph>.  <emph>( All
sequences of exactly n strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>{n,}</td>
  <td align="center">
  All strings in L(S{n}S*)  <emph>( All
sequences of at least n, strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>{0,m}</td>
  <td align="center">
  All strings <emph>st</emph> with <emph>s</emph> in <emph>L(S?)</emph>
  and <emph>t</emph> in <emph>L(S{0,m-1})</emph>.  <emph>( All
sequences of at most m, strings from L(S) )</emph>
  </td>
</tr>
<tr>
  <td align="center"><emph>S</emph>{0,0}</td>
  <td align="center">
  The set containing only the empty string
  </td>
</tr>
</tbody>
</table>
<note>
<p>
The regular expression language in the Perl Programming Language
<bibref ref="Perl"/> does not include a quantifier of the form
<code>S{,m)</code>, since it is logically equivalent to <code>S{0,m}</code>.
We have, therefore, left this logical possibility out of the regular
expression language defined by this specification.   We welcome
further input from implementors and schema authors on this issue.
</p>
</note>
<p>
<termdef id="dt-quantifier" term="quantifier">A <term>quantifier</term>
is one of <code>?</code>, <code>*</code>, <code>+</code>,
<code>{n,m}</code> or <code>{n,}</code>, which have the meanings
defined in the table above.
</termdef>
</p>
<p>
<termdef id="dt-atom" term="atom">An <term>atom</term> is either a
<termref def="dt-normalc"/>, a <termref def="dt-charclass"/>, or
a parenthesized <termref def="dt-regex"/>.</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
For all <termref def="dt-normalc"/>s <emph>c</emph>,
<termref def="dt-charclass"/>es <emph>C</emph>, and
<termref def="dt-regex"/>s <emph>S</emph>, valid
<termref def="dt-atom"/>s <emph>R</emph> are:
</th>
<th>
Denoting the set of strings <emph>L(R)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center"><emph>c</emph></td>
  <td align="center">the single string consisting only of <emph>c</emph></td>
</tr>
<tr>
  <td align="center"><emph>C</emph></td>
  <td align="center">all strings in <emph>L(C)</emph></td>
</tr>
<tr>
  <td align="center">(<emph>S</emph>)</td>
  <td align="center">all strings in <emph>L(S)</emph></td>
</tr>
</tbody>
</table>

<p>
<termdef id="dt-metac" term="metacharacter">A <term>metacharacter</term>
is either <code>.</code>, <code>\</code>, <code>?</code>,
<code>*</code>, <code>+</code>, <code>{</code>, <code>}</code>
<code>(</code>, <code>)</code>, <code>[</code> or <code>]</code>.
These characters have special meanings in <termref def="dt-regex"/>s,
but can be escaped to form <termref def="dt-atom"/>s that denote the
sets of strings containing only themselves, i.e., an escaped
<termref def="dt-metac"/> behaves like a <termref def="dt-normalc"/>.
</termdef>
</p>

<p>
<termdef id="dt-normalc" term="normal character">A
<term>normal character</term> is any XML character that is not a
metacharacter.  In <termref def="dt-regex"/>s, a normal character is an
atom that denotes the singleton set of strings containing only itself.
</termdef>
</p>
<p>
Note that a <termref def="dt-normalc"/> can be represented either as
itself, or with a <xspecref href="&xmlspec;#dt-charref">character
reference</xspecref>.
</p>
<div2 id="charcter-classes">
<head>Character Classes</head>
<p>
<termdef id="dt-charclass" term="character class">A
<term>character class</term> is an <termref def="dt-atom"/>
<emph>R</emph> that identifies a <B>set of characters</B>
<emph>C(R)</emph>.  The set of strings <emph>L(R)</emph> denoted by a
character class <emph>R</emph> contains one single-character string
"<emph>c</emph>" for each character <emph>c</emph> in <emph>C(R)</emph>.
</termdef>
</p>
<p>
A character class is either a <termref def="dt-cces"/> or a
<termref def="dt-charexpr"/>.
</p>

<p>
<termdef id="dt-charexpr" term="character class expression">A
<term>character class expression</term> is a <termref def="dt-chargroup"/> surrounded
by <code>[</code> and <code>]</code> characters.  For all character
groups <emph>G</emph>, [<emph>G</emph>] is a valid <term>character class
expression</term>, identifying the set of characters
<emph>C</emph>([<emph>G</emph>]) = <emph>C</emph>(<emph>G</emph>).
</termdef>
</p>

<p>
<termdef id="dt-chargroup" term="character group">A
<term>character group</term> is either <termref def="dt-poschargroup"/>,
a <termref def="dt-negchargroup"/>, or a <termref def="dt-subchargroup"/>.
</termdef>
</p>

<p>
<termdef id="dt-poschargroup" term="positive character group">
A <term>positive character group</term> consists of one or more
<termref def="dt-charrange"/>s or <termref def="dt-cces"/>s, concatenated
together.  A <term>positive character group</term> identifies the set of
characters containing all of the characters in all of the sets identified
by its constituent ranges or escapes.
</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
For all <termref def="dt-charrange"/>s <emph>R</emph>, all
<termref def="dt-cces"/>s <emph>E</emph>, and all
<termref def="dt-poschargroup"/>s <emph>P</emph>, valid
<termref def="dt-poschargroup"/>s <emph>G</emph> are:
</th>
<th>
Identifying the set of characters <emph>C(G)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center"><emph>R</emph></td>
  <td align="center">all characters in <emph>C(R)</emph>.</td>
</tr>
<tr>
  <td align="center"><emph>E</emph></td>
  <td align="center">all characters in <emph>C(E)</emph>.</td>
</tr>
<tr>
  <td align="center"><emph>RP</emph></td>
  <td align="center">all characters in <emph>C(R)</emph> and all
  characters in <emph>C(P)</emph>.</td>
</tr>
<tr>
  <td align="center"><emph>EP</emph></td>
  <td align="center">all characters in <emph>C(E)</emph> and all
  characters in <emph>C(P)</emph>.</td>
</tr>
</tbody>
</table>

<p>
<termdef id="dt-negchargroup" term="negative character group">
A <term>negative character group</term> is a
<termref def="dt-poschargroup"/> preceded by the <code>^</code> character.
For all <termref def="dt-poschargroup"/>s <emph>P</emph>, ^<emph>P</emph>
is a valid <term>negative character group</term>, and <emph>C(^P)</emph>
contains all XML characters that are <B>not</B> in <emph>C(P)</emph>.
</termdef>
</p>

<p>
<termdef id="dt-subchargroup" term="character class subtraction">A
<term>character class subtraction</term> is a <termref def="dt-charexpr"/>
subtracted from a <termref def="dt-poschargroup"/> or
<termref def="dt-negchargroup"/>, using the <code>-</code> character.
</termdef>
</p>
<p>
For any <termref def="dt-poschargroup"/> or
<termref def="dt-negchargroup"/> <emph>G</emph>, and any
<termref def="dt-charexpr"/> <emph>C</emph>, <emph>G-C</emph> is a valid
<termref def="dt-subchargroup"/>, identifying the set of all characters in
<emph>C(G)</emph> that are not also in <emph>C(C)</emph>.
</p>

<p>
<termdef id="dt-charrange" term="character range">A
<term>character range</term> <emph>R</emph> identifies a set of
characters <emph>C(R)</emph> containing all XML characters with Unicode
code points in a specified range.
</termdef>
</p>
<p>
A single XML character is a <termref def="dt-charrange"/> that identifies
the set of characters containing only itself.  All XML characters are valid
character ranges, except as follows:
</p>
<ulist>
<item>
<p>
The <code>[</code>, <code>]</code>, and <code>\</code> characters are not
valid character ranges;
</p>
</item>
<item>
<p>
The <code>^</code> character is only valid at the beginning of a
<termref def="dt-poschargroup"/> if it is part of a
<termref def="dt-negchargroup"/>; and
</p>
</item>
<item>
<p>
The <code>-</code> character is a valid character range only at the
beginning or end of a <termref def="dt-poschargroup"/>.
</p>
</item>
</ulist>
<p>
A <termref def="dt-charrange"/>&nbsp;<termref def="dt-may"/> also be written
in the form <emph>s-e</emph>, identifying the set that contains all XML characters
with Unicode code points greater than or equal to the code point
of <emph>s</emph>, but not greater than the code point of <emph>e</emph>.
</p>
<p>
<emph>s-e</emph> is a valid character range iff:
</p>
<ulist>
<item>
<p>
<emph>s</emph> is a <termref def="dt-cces1"/>, or an XML character;
</p>
</item>
<item>
<p>
<emph>s</emph> is not <code>\</code>
</p>
</item>
<item>
<p>
If s is the first character in a <termref def="dt-charexpr"/>, then
<emph>s</emph> is not <code>^</code>
</p>
</item>
<item>
<p>
<emph>e</emph> is a <termref def="dt-cces1"/>, or an XML character;
</p>
</item>
<item>
<p>
<emph>e</emph> is not <code>\</code> or <code>[</code>; and
</p>
</item>
<item>
<p>
The code point of <emph>e</emph> is greater than or equal to the code
point of <emph>s</emph>;
</p>
</item>
</ulist>
<note>
<p>
The code point of a <termref def="dt-cces1"/> is the code point of the
single character in the set of characters that it identifies.
</p>
</note>
<div3 id="cces">
<head>Character Class Escapes</head>
<p>
<termdef id="dt-cces" term="character class escape">
A <term>character class escape</term> is a short sequence of characters
that identifies predefined character class.  The valid character
class escapes include the <termref def="dt-cces1"/>s, the
<termref def="dt-ccesN"/>s, and the <termref def="dt-ccescat"/>s.
</termdef>
</p>
<p>
<termdef id="dt-cces1" term="single character escape">A
<term>single character escape</term> identifies a set containing a only
one character -- usually because that character is difficult or
impossible to write directly into a <termref def="dt-regex"/>.
</termdef>
</p>

<table border="1">
<col width="50%"/>
<col width="50%"/>
<thead>
<tr>
<th>
The valid <termref def="dt-cces1"/>s are:
</th>
<th>
Identifying the set of characters <emph>C(R)</emph> containing:
</th>
</tr>
</thead>
<tbody>
<tr>
  <td align="center"><code>\n</code></td>
  <td align="center">the newline character (#xA)</td>
</tr>
<tr>
  <td align="center"><code>\r</code></td>
  <td align="center">the return character (#xD)</td>
</tr>
<tr>
  <td align="center"><code>\t</code></td>
  <td align="center">the tab character (#x9)</td>
</tr>
<tr>
  <td align="center"><code>\\</code></td>
  <td align="center">\</td>
</tr>
<tr>
  <td align="center"><code>\|</code></td>
  <td align="center">|</td>
</tr>
<tr>
  <td align="center"><code>\.</code></td>
  <td align="center">.</td>
</tr>
<tr>
  <td align="center"><code>\-</code></td>
  <td align="center">-</td>
</tr>
<tr>
  <td align="center"><code>\^</code></td>
  <td align="center">^</td>
</tr>
<tr>
  <td align="center"><code>\?</code></td>
  <td align="center">?</td>
</tr>
<tr>
  <td align="center"><code>\*</code></td>
  <td align="center">*</td>
</tr>
<tr>
  <td align="center"><code>\+</code></td>
  <td align="center">+</td>
</tr>
<tr>
  <td align="center"><code>\{</code></td>
  <td align="center">{</td>
</tr>
<tr>
  <td align="center"><code>\}</code></td>
  <td align="center">}</td>
</tr>
<tr>
  <td align="center"><code>\(</code></td>
  <td align="center">(</td>
</tr>
<tr>
  <td align="center"><code>\)</code></td>
  <td align="center">)</td>
</tr>
<tr>
  <td align="center"><code>\[</code></td>
  <td align="center">[</td>
</tr>
<tr>
  <td align="center"><code>\]</code></td>
  <td align="center">]</td>
</tr>
</tbody>
</table>
<p>
<termdef id="dt-ccescat" term="category escape">
<bibref ref="Unicode3"/> defines a number of character properties
and provides mappings from code points to specific character properties.
The set containing all characters that have property <code>X</code>,
can be identified with a <term>category escape</term> <code>\p{X}</code>.
The complement of this set is specified with the
<term>category escape</term> <code>\P{X}</code>.
(<code>[\P{X}]</code> = <code>[^\p{X}]</code>).
</termdef>
</p>
<note>
<p>
<bibref ref="Unicode3"/> is subject to future revision.  For example, the
mapping from code points to character properties might be updated.  
All <termref def="dt-minimally-conforming"/> processors <termref def="dt-must"/>
support the character properties defined in the version of the Unicode
Standard that is current at the time this specification became a W3C
Recommendation.  However, implementors are encouraged to support the
character properties defined in any future version of the Unicode Standard.
</p>
</note>
<note>
<p>
The syntax <code>\p{X}</code> is the same as that used in
<bibref ref="Perl5.6"/>.
</p>
</note>
<p>
The following table specifies the main character properties (for more
information, see Chapter 4 of <bibref ref="Unicode3"/>).
</p>

<table border="1" align="center">
<tbody>
	<tr>
		<th>Category</th>
		<th>Property</th>
		<th>Meaning</th>
	</tr>
	<tr>
		<td rowspan="6">Letters</td>
		<td align="center">L</td>
		<td>All Letters</td>
	</tr>
	<tr>
		<td align="center">Lu</td>
		<td>Uppercase</td>
	</tr>
	<tr>
		<td align="center">Ll</td>
		<td>Lowercase</td>
	</tr>
	<tr>
		<td align="center">Lt</td>
		<td>Titlecase</td>
	</tr>
	<tr>
		<td align="center">Lm</td>
		<td>Modifier</td>
	</tr>
	<tr>
		<td align="center">Lo</td>
		<td>Other</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="4">Marks</td>
		<td align="center">M</td>
		<td>All Marks</td>
	</tr>
	<tr>
		<td align="center">Mn</td>
		<td>Non-Spacing</td>
	</tr>
	<tr>
		<td align="center">Mc</td>
		<td>Spacing Combining</td>
	</tr>
	<tr>
		<td align="center">Me</td>
		<td>Enclosing</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="4">Numbers</td>
		<td align="center">N</td>
		<td>All Numbers</td>
	</tr>
	<tr>
		<td align="center">Nd</td>
		<td>Decimal Digit</td>
	</tr>
	<tr>
		<td align="center">Nl</td>
		<td>Letter</td>
	</tr>
	<tr>
		<td align="center">No</td>
		<td>Other</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="8">Punctuation</td>
		<td align="center">P</td>
		<td>All Punctuation</td>
	</tr>
	<tr>
		<td align="center">Pc</td>
		<td>Connector</td>
	</tr>
	<tr>
		<td align="center">Pd</td>
		<td>Dash</td>
	</tr>
	<tr>
		<td align="center">Ps</td>
		<td>Open</td>
	</tr>
	<tr>
		<td align="center">Pe</td>
		<td>Close</td>
	</tr>
	<tr>
		<td align="center">Pi</td>
		<td>Initial quote
			(can behave like Ps or Pe depending on usage)</td>
	</tr>
	<tr>
		<td align="center">Pf</td>
		<td>Final quote
			(can behave like Ps or Pe depending on usage)</td>
	</tr>
	<tr>
		<td align="center">Po</td>
		<td>Other</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="4">Separators</td>
		<td align="center">Z</td>
		<td>All Separators</td>
	</tr>
	<tr>
		<td align="center">Zs</td>
		<td>Space</td>
	</tr>
	<tr>
		<td align="center">Zl</td>
		<td>Line</td>
	</tr>
	<tr>
		<td align="center">Zp</td>
		<td>Paragraph</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="5">Symbols</td>
		<td align="center">S</td>
		<td>All Symbols</td>
	</tr>
	<tr>
		<td align="center">Sm</td>
		<td>Math</td>
	</tr>
	<tr>
		<td align="center">Sc</td>
		<td>Currency</td>
	</tr>
	<tr>
		<td align="center">Sk</td>
		<td>Modifier</td>
	</tr>
	<tr>
		<td align="center">So</td>
		<td>Other</td>
	</tr>
	<tr>
		<td colspan="3">&nbsp;</td>
	</tr>
	<tr>
		<td rowspan="6">Other</td>
		<td align="center">C</td>
		<td>All Others</td>
	</tr>
	<tr>
		<td align="center">Cc</td>
		<td>Control</td>
	</tr>
	<tr>
		<td align="center">Cf</td>
		<td>Format</td>
	</tr>
	<!--
	<tr>
		<td align="center">Cs</td>
		<td>Surrogate</td>
	</tr>
	  -->
	<tr>
		<td align="center">Co</td>
		<td>Private Use</td>
	</tr>
	<tr>
		<td align="center">Cn</td>
		<td>Not Assigned</td>
	</tr>
</tbody>
</table>
<note>
<p>
The properties mentioned exclude the <code>Cs</code> property described
in Chapter 4 of <bibref ref="Unicode3"/>.  The <code>Cs</code> property
identifies <bibref ref="Unicode3"/> "surrogate" characters, which do not
occur at the level of the "character abstraction" that XML instance documents
operate on.
</p>
</note>
<p>
<termdef id="dt-ccesblock" term="block escape">
<bibref ref="Unicode3"/> groups code points into a number of blocks
such as Basic Latin (i.e., ASCII), Latin-1 Supplement, Hangul Jamo,
CJK Compatibility, etc.
The set containing all characters that have block name <code>X</code>
(with all white space stripped out),
can be identified with a <term>block escape</term> <code>\p{IsX}</code>.
The compliment of this set is specified with the
<term>block escape</term> <code>\P{IsX}</code>.
(<code>[\P{IsX}]</code> = <code>[^\p{IsX}]</code>).
</termdef>
</p>
<note>
<p>
<bibref ref="Unicode3"/> is subject to future revision.  For example, the
grouping of code points into blocks might be updated.  
All <termref def="dt-minimally-conforming"/> processors <termref def="dt-must"/>
support the blocks defined in the version of the Unicode
Standard that is current at the time this specification became a W3C
Recommendation.  However, implementors are encouraged to support the
blocks defined in any future version of the Unicode Standard.
</p>
</note>
<note>
<p>
The syntax <code>\p{IsX}</code> is the same as that used in
<bibref ref="Perl5.6"/>.
</p>
</note>
<p>
For example, the <termref def="dt-ccesblock"/> for identifying the
ASCII characters is <code>\p{IsBasicLatin}</code>.
</p>
<p>
<termdef id="dt-ccesN" term="multi-character escape">A
<term>multi-character escape</term> provides a simple way to identify
a commonly used set of characters:
</termdef>
</p>
<table border="1" align="center">
<col width="33%"/>
<col width="33%"/>
<col width="33%"/>
<thead><tr>
<th>Character sequence</th>
<!--<th>Name</th>-->
<th>Equivalent <termref def="dt-charclass"/></th>
</tr>
</thead>
<tbody>
	<tr>
		<td align="center">.</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\n\r]</td>
	</tr>
	<tr>
		<td align="center">\s</td>
<!--		<td>white space</td>-->
		<td align="center">[#x20\t\n\r]</td>
	</tr>
	<tr>
		<td align="center">\S</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\s]</td>
	</tr>
	<tr>
		<td align="center">\i</td>
<!--		<td>XML initial Name character</td>-->
		<td align="center">[\p{L}\p{Nl}:_]</td>
	</tr>
	<tr>
		<td align="center">\I</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\i]</td>
	</tr>
	<tr>
		<td align="center">\c</td>
<!--		<td>XML Name character</td>-->
		<td align="center">the set of characters matched by
		<xspecref href="&xmlspec;#NT-NameChar">NameChar</xspecref></td> 
	</tr>
	<tr>
		<td align="center">\C</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\c]</td>
	</tr>
	<tr>
		<td align="center">\d</td>
<!--		<td>digit (includes digits outside of the 0-9)</td>-->
		<td align="center">\p{Nd}</td>
	</tr>
	<tr>
		<td align="center">\D</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\d]</td>
	</tr>
	<tr>
		<td align="center">\w</td>
<!--		<td>a "word" character</td>-->
		<td align="center">
			[#x0000-#x10FFFF]-[\p{P}\p{S}\p{C}]
			(<emph>all characters except the set of "punctuation",
				"separator" and "control" characters</emph>)
		</td>
	</tr>
	<tr>
		<td align="center">\W</td>
<!--		<td>&nbsp;</td>-->
		<td align="center">[^\w]</td>
	</tr>
</tbody>
</table>
<note>
<p>
The <termref def="dt-regex"/> language defined here does not
attempt to provide a general solution to "regular expressions" over
<bibref ref="Unicode3"/> strings.  In particular, it does not easily provide
for matching sequences of base characters and combining marks.
<!--(e.g.,
<code>&eacute;</code> vs. <code>e</code> followed by #0301 [an acute accent mark]).
-->
The language is targeted at support of "Level 1" features as defined in
<bibref ref="unicodeRegEx"/>.  It is hoped that future versions of this
specification will provide support for "Level 2" features.
</p>
</note>
<ednote role="pf">
<edtext>
Future versions of this specification might allow non-significant white space
embedded within a <termref def="dt-regex"/>.  The
<loc href="http://www.w3.org/XML/Activity#schema-wg">XML Schema Working
Group</loc> welcomes feedback from implementors and schema authors on
the advisability of including such white space.
</edtext>
</ednote>
</div3>
</div2>
</div1>
<div1 id="biblio">
<head>References</head>
<!--
   bibls can be in any order and the stylesheet will sort them
   by the value of their key attribute
  -->
<div2 id="normative-biblio">
<head>Normative</head>
<blist>
<bibl id="ieee754" key="IEEE 754-1985">
IEEE. <emph>IEEE Standard for Binary Floating-Point Arithmetic.</emph>
See <loc href="http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html">
http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html</loc>
</bibl>
<bibl id="XML-Infoset" key="XML Information Set">
World Wide Web Consortium.  XML Information Set (public WD)
Available at: <loc href="http://www.w3.org/TR/xml-infoset">
http://www.w3.org/TR/xml-infoset </loc>
</bibl>
<bibl id="XML" key="XML 1.0 Recommendation (Second Edition)">
World Wide Web Consortium. <emph>Extensible Markup Language (XML) 1.0, Second
Edition.</emph>
Available at: <loc href="&xmlspec;">&xmlspec;</loc>
</bibl>
<bibl id="structural-schemas" key="XML Schema Part 1: Structures">
XML Schema Part 1: Structures. Available at: <loc href="&xsdl;">
&xsdl;</loc>
</bibl>
<bibl id="schema-requirements" key="XML Schema Requirements">
XML Schema Requirements.  Available at:
<loc href="http://www.w3.org/TR/NOTE-xml-schema-req">
http://www.w3.org/TR/NOTE-xml-schema-req</loc>
</bibl>
<bibl id="XMLNS" key="Namespaces in XML">
World Wide Web Consortium.  <emph>Namespaces in XML</emph>. Available at:
<loc href="&xmlnsspec;">&xmlnsspec;</loc>
</bibl>
<bibl id="RFC2396" key="RFC 2396">
Tim Berners-Lee, et. al. <emph>RFC 2396: Uniform Resource Identifiers (URI):
Generic Syntax.</emph>. 1998.  Available at:
<loc href="http://www.ietf.org/rfc/rfc2396.txt">
http://www.ietf.org/rfc/rfc2396.txt</loc>
</bibl>
<bibl id="RFC2732" href="http://www.ietf.org/rfc/rfc2732.txt" key="RFC 2732">
<emph>RFC
2732: Format for Literal IPv6 Addresses in URL's</emph>. 1999.
Available at:
<loc href="http://www.ietf.org/rfc/rfc2732.txt">
http://www.ietf.org/rfc/rfc2732.txt</loc>
</bibl>
<bibl id="RFC2045" key="RFC 2045">
N. Freed and N. Borenstein. <emph>RFC 2045: Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies</emph>. 1996  Available at:
<loc href="http://www.ietf.org/rfc/rfc2045.txt">
http://www.ietf.org/rfc/rfc2045.txt</loc>
</bibl>
<bibl id="RFC1766" key="RFC 1766">
H. Alvestrand, ed. <emph>RFC 1766: Tags for the Identification of Languages</emph>
1995. Available at: <loc href="http://www.ietf.org/rfc/rfc1766.txt">
http://www.ietf.org/rfc/rfc1766.txt</loc>
</bibl>
<bibl id="clinger1990" key="Clinger, WD (1990)">
William D Clinger. <emph>How to Read Floating Point Numbers Accurately.</emph>
In <emph>Proceedings of Conference on Programming Language Design and
Implementation</emph>, pages 92-101.
Available at: <loc href="ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps">
ftp://ftp.ccs.neu.edu/pub/people/will/howtoread.ps</loc>
</bibl>
<bibl id="Unicode3" key="Unicode3">
The Unicode Consortium. <emph>The Unicode Standard, Version 3.0.</emph>
Reading, Mass.: Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5.
</bibl>
</blist>
</div2>
<div2 id="non-normative-biblio">
<head>Non-normative</head>
<blist>
<!--
<bibl id='ecmascript-regex' key='ECMAScript Regex'>
ECMAScript v2 Draft. Regular Expressions.
See <loc href='http://www2.hursley.ibm.com/tc39/regexp30.pdf'>
http://www2.hursley.ibm.com/tc39/regexp30.pdf</loc>
</bibl>
-->
<bibl id="ISO10646" key="ISO 10646">
ISO (International Organization for Standardization).  <emph>ISO/IEC 10646-1993
(E).  Information technology --- Universal Multiple-Octet Coded Character
Set (UCS) --- Part 1: Architecture and Basic Multilingual Plane.</emph>
[Geneva]: International Organization for Standardization, 1993 (plus amendments
AM 1 through AM 7).
</bibl>
<bibl id="ISO10646-2000" key="ISO 10646-2000">
ISO (International Organization for Standardization).  <emph>ISO/IEC 10646-1:2000.
Information technology --- Universal Multiple-Octet Coded Character
Set (UCS) --- Part 1: Architecture and Basic Multilingual Plane.</emph>
[Geneva]: International Organization for Standardization, 2000.
</bibl>
<bibl id="Unicode" key="Unicode">
The Unicode Consortium. <emph>The Unicode Standard, Version 2.0.</emph>
Reading, Mass.: Addison-Wesley Developers Press, 1996.
</bibl>
<bibl id="unicodeDB" key="Unicode Database">
The Unicode Consortium. <emph>The Unicode Character Database</emph>.
Available at: <loc href="http://www.unicode.org/Public/3.0-Update/UnicodeCharacterDatabase-3.0.0.html">
http://www.unicode.org/Public/3.0-Update/UnicodeCharacterDatabase-3.0.0.html</loc>
</bibl>
<bibl id="unicodeRegEx" key="Unicode Regular Expression Guidelines">
Mark Davis.  <emph>Unicode Regular Expression Guidelines</emph>, 1988.
Available at: <loc href="http://www.unicode.org/unicode/reports/tr18/">
http://www.unicode.org/unicode/reports/tr18/</loc>
</bibl>
<bibl id="Perl" key="Perl">
The Perl Programming Language.  See <loc href="http://www.perl.com/pub">
http://www.perl.com</loc>
</bibl>
<bibl id="Perl5.6" key="Perl 5.6">
The Perl Programming Language, Version 5.6.  See <loc href="http://www.perl.com/language/misc/ann58/index.html">
http://www.perl.com/language/misc/ann58/index.html</loc>
</bibl>
<bibl id="SQL" key="SQL">
<!--
SQL Standard.  See <loc href='http://www.jcc.com/SQLPages/jccs_sql.htm'>
http://www.jcc.com/SQLPages/jccs_sql.htm</loc>
  -->
ISO (International Organization for Standardization).  <emph>ISO/IEC
9075-2:1999, Information technology --- Database languages ---
SQL --- Part 2: Foundation (SQL/Foundation)</emph>.
[Geneva]: International Organization for Standardization, 1999.
See <loc href="http://www.iso.ch/cate/d26197.html">
http://www.iso.ch/cate/d26197.html</loc>
</bibl>
<bibl id="ISO8601" key="ISO 8601">
ISO (International Organization for Standardization).
<emph>Representations of dates and times, 1988-06-15.</emph>  Available at:
<loc href="http://www.iso.ch/markete/8601.pdf">
http://www.iso.ch/markete/8601.pdf</loc>  
</bibl>
<bibl id="ISO8601revision" key="ISO 8601 Draft Revision">
ISO (International Organization for Standardization).
<emph>Representations of dates and times, draft revision, 1998.</emph>
<!--
Available at:
<loc href='http://www.cl.cam.ac.uk/~mgk25/8601v04.pdf'>
http://www.cl.cam.ac.uk/~mgk25/8601v04.pdf</loc>
-->
</bibl>
<bibl id="ISO11404" key="ISO 11404">
ISO (International Organization for Standardization).
<emph>Language-independent Datatypes.</emph>  See
<loc href=" http://www.iso.ch/cate/d19346.html">
 http://www.iso.ch/cate/d19346.html</loc>
</bibl>
<bibl id="RDFSchema" key="RDF Schema">
World Wide Web Consortium. <emph>RDF Schema Specification.</emph>
Available at:
<loc href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</loc>
</bibl>
<bibl id="XSL" key="XSL">
World Wide Web Consortium.
<emph>Extensible Stylesheet Language (XSL).</emph>
Available at: <loc href="http://www.w3.org/TR/xsl/">http://www.w3.org/TR/xsl/</loc>
</bibl>
<bibl id="Xptr" key="XPointer">
World Wide Web Consortium.
<emph>XML Pointer Language (XPointer) .</emph>
Available at: <loc href="http://www.w3.org/TR/WD-xptr">http://www.w3.org/TR/WD-xptr</loc>
</bibl>
<bibl id="CharMod" key="Character Model">
Martin J. D&#xfc;rst and Fran&#xe7;ois Yergeau, eds.
Character Model for the World Wide Web. World Wide Web Consortium
Working Draft. 1999
Available at:
<loc href="http://www.w3.org/TR/1999/WD-charmod-19991129/">
http://www.w3.org/TR/1999/WD-charmod-19991129/</loc>
</bibl>
<bibl id="gay1990" key="Gay, DM (1990)">
David M. Gay.  <emph>Correctly Rounded Binary-Decimal and
Decimal-Binary Conversions.</emph> AT&amp;T Bell Laboratories Numerical
Analysis Manuscript 90-10, November 1990.
Available at:
<loc href="http://cm.bell-labs.com/cm/cs/doc/90/4-10.ps.gz">
http://cm.bell-labs.com/cm/cs/doc/90/4-10.ps.gz</loc>
</bibl>
</blist>
</div2>
</div1>
<div1 id="acknowledgments">
<head>Acknowledgements (non-normative)</head>
 <p>The following have contributed material to this draft:</p>
 <slist>
  <sitem>David Fallside, IBM</sitem>
  <sitem>Scott Lawrence, Agranat Systems</sitem>
  <sitem>Andrew Layman, Microsoft</sitem>
  <sitem>Eve L. Maler, Sun Microsystems</sitem>
 </slist>
<p>The editors acknowledge the members of the XML Schema Working Group, the members of other W3C Working Groups, and industry experts in other
forums who have contributed directly or indirectly to the process or content of
creating this document. The Working Group is particularly grateful to Lotus
Development Corp. and IBM for providing teleconferencing facilities.</p>
 <p>The current members of the XML Schema Working Group are:</p>
<orglist>
<member>
 <name>Jim Barnette</name>
 <affiliation>Defense Information Systems Agency (DISA)</affiliation>
</member>
<member>
 <name>David Beech</name>
 <affiliation>Oracle Corp.</affiliation>
</member>
<member>
 <name>Paul V. Biron</name>
 <affiliation>Health Level Seven</affiliation>
</member>
<member>
 <name>Don Box</name>
 <affiliation>DevelopMentor</affiliation>
</member>
<member>
 <name>Allen Brown</name>
 <affiliation>Microsoft</affiliation>
</member>
<member>
 <name>Lee Buck</name>
 <affiliation>TIBCO Extensibility</affiliation>
</member>
<member>
 <name>Charles E. Campbell</name>
 <affiliation>Informix</affiliation>
</member>
 <member>
  <name>Wayne Carr</name>
  <affiliation>Intel</affiliation>
 </member>
<member>
 <name>Peter Chen</name>
 <affiliation>Bootstrap Alliance and LSU</affiliation>
</member>
<member>
 <name>David Cleary</name>
 <affiliation>Progress Software</affiliation>
</member>
 <member>
  <name>Mike Cokus</name>
  <affiliation>MITRE</affiliation>
 </member>
<member>
 <name>Dan Connolly</name>
 <affiliation>W3C</affiliation>
 <role>staff contact</role>
</member>
<member>
 <name>Roger L. Costello</name>
 <affiliation>MITRE</affiliation>
</member>
<member>
 <name>Ugo Corda</name>
 <affiliation>Xerox</affiliation>
</member>
 <member>
  <name>Haavard Danielson</name>
  <affiliation>Progress Software</affiliation>
 </member>
<member>
 <name>David Ezell</name>
 <affiliation>Hewlett Packard Company</affiliation>
</member>
<member>
 <name>David Fallside</name>
 <affiliation>IBM</affiliation>
</member>
<member>
 <name>Matthew Fuchs</name>
 <affiliation>Commerce One</affiliation>
</member>
<member>
 <name>Andrew Goodchild</name>
 <affiliation>Distributed Systems Technology Centre (DSTC Pty Ltd)</affiliation>
</member>
<member>
 <name>Paul Grosso</name>
 <affiliation>ArborText, Inc</affiliation>
</member>
<member>
 <name>Martin Gudgin</name>
 <affiliation>DevelopMentor</affiliation>
</member>
<member>
 <name>Dave Hollander</name>
 <affiliation>Contivo</affiliation>
 <role>co-chair</role>
</member>
<member>
 <name>Mary Holstege</name>
 <affiliation>Calico Commerce</affiliation>
</member>
<member>
 <name>Jane Hunter</name>
 <affiliation>Distributed Systems Technology Centre (DSTC Pty Ltd)</affiliation>
</member>
 <member>
  <name>Rick Jelliffe</name>
  <affiliation>Academia Sinica</affiliation>
 </member>
<member>
 <name>Andrew Layman</name>
 <affiliation>Microsoft</affiliation>
</member>
<member>
 <name>Dmitry Lenkov</name>
 <affiliation>Hewlett Packard Company</affiliation>
</member>
<member>
 <name>Ashok Malhotra</name>
 <affiliation>IBM</affiliation>
</member>
<member>
 <name>Murray Maloney</name>
 <affiliation>Muzmo Communication, acting for Commerce One</affiliation>
</member>
<member>
 <name>John McCarthy</name>
 <affiliation>Lawrence Berkeley National Laboratory</affiliation>
</member>
<member>
 <name>Noah Mendelsohn</name>
 <affiliation>Lotus Development Corporation</affiliation>
</member>
<member>
 <name>Don Mullen</name>
 <affiliation>TIBCO Extensibility</affiliation>
</member>
 <member>
  <name>Alex Milowski</name>
  <affiliation>Lexica LLC</affiliation>
 </member>
<member>
 <name>Frank Olken</name>
 <affiliation>Lawrence Berkeley National Laboratory</affiliation>
</member>
 <member>
  <name>Dave Peterson</name>
  <affiliation>Graphic Communications Association</affiliation>
 </member>
<member>
 <name>Jonathan Robie</name>
 <affiliation>Software AG</affiliation>
</member>
 <member>
  <name>Lew Shannon</name>
  <affiliation>NCR</affiliation>
 </member>
<member>
 <name>C. M. Sperberg-McQueen</name>
 <affiliation>W3C</affiliation>
 <role>co-chair</role>
</member>
<member>
 <name>Bob Streich</name>
 <affiliation>Calico Commerce</affiliation>
</member>
<member>
 <name>Henry S. Thompson</name>
 <affiliation>University of Edinburgh</affiliation>
</member>
<member>
 <name>Matt Timmermans</name>
 <affiliation>Microstar</affiliation>
</member>
<member>
 <name>Jim Trezzo</name>
 <affiliation>Oracle Corp.</affiliation>
</member>
<member>
 <name>Mark Tucker</name>
 <affiliation>Health Level Seven</affiliation>
</member>
 <member>
  <name>Asir S. Vedamuthu</name>
  <affiliation>webMethods, Inc</affiliation>
 </member>
<member>
 <name>Priscilla Walmsley</name>
 <affiliation>XMLSolutions</affiliation>
</member>
<member>
 <name>Norm Walsh</name>
 <affiliation>Sun Microsystems</affiliation>
</member>
<member>
 <name>Aki Yoshida</name>
 <affiliation>SAP AG</affiliation>
</member>
</orglist>
 <p>The XML Schema Working Group has benefited in its work from the
participation and contributions of a number of people not currently
members of the Working Group, including
in particular those named below.  Affiliations given are those current at
the time of their work with the WG.
</p>
 <orglist>
<member>
 <name>Paula Angerstein</name>
 <affiliation>Vignette Corporation</affiliation>
</member>
 <member>
  <name>Gabe Beged-Dov</name>
  <affiliation>Rogue Wave Software</affiliation>
 </member>
<member>
 <name>Greg Bumgardner</name>
 <affiliation>Rogue Wave Software</affiliation>
</member>
<member>
 <name>Dean Burson</name>
 <affiliation>Lotus Development Corporation</affiliation>
</member>
 <member>
 <name>Andrew Eisenberg</name>
 <affiliation>Progress Software</affiliation>
</member>
<member>
 <name>Rob Ellman</name>
 <affiliation>Calico Commerce</affiliation>
</member>
 <member>
  <name>George Feinberg</name>
  <affiliation>Object Design</affiliation>
 </member>
 <member>
  <name>Charles Frankston</name>
  <affiliation>Microsoft</affiliation>
 </member>
 <member>
  <name>Ernesto Guerrieri</name>
  <affiliation>Inso</affiliation>
 </member>
 <member>
  <name>Michael Hyman</name>
  <affiliation>Microsoft</affiliation>
 </member>
<member>
 <name>Renato Iannella</name>
 <affiliation>Distributed Systems Technology Centre (DSTC Pty Ltd)</affiliation>
</member>
 <member>
  <name>Dianne Kennedy</name>
  <affiliation>Graphic Communications Association</affiliation>
 </member>
<member>
 <name>Janet Koenig</name>
 <affiliation>Sun Microsystems</affiliation>
</member>
<member>
 <name>Setrag Khoshafian</name>
 <affiliation>Technology Deployment International (TDI)</affiliation>
</member>
<member>
 <name>Ara Kullukian</name>
 <affiliation>Technology Deployment International (TDI)</affiliation>
</member>
<member>
 <name>Murata Makoto</name>
 <affiliation>Xerox</affiliation>
</member>
<member>
 <name>Eve Maler</name>
 <affiliation>Sun Microsystems</affiliation>
</member>
 <member>
  <name>Chris Olds</name>
  <affiliation>Wall Data</affiliation>
 </member>
<member>
 <name>Shriram Revankar</name>
 <affiliation>Xerox</affiliation>
</member>
<member>
 <name>Mark Reinhold</name>
 <affiliation>Sun Microsystems</affiliation>
</member>
<member>
 <name>John C. Schneider</name>
 <affiliation>MITRE</affiliation>
</member>
 <member>
  <name>William Shea</name>
  <affiliation>Merrill Lynch</affiliation>
 </member>
 <member>
  <name>Ralph Swick</name>
  <affiliation>W3C</affiliation>
 </member>
 <member>
  <name>Tony Stewart</name>
  <affiliation>Rivcom</affiliation>
 </member>
<member>
 <name>Steph Tryphonas</name>
 <affiliation>Microstar</affiliation>
</member>
 </orglist>
</div1>
<!--
<div1 id='open-issues'>
<head>Open Issues</head>
<open-issues/>
</div1>
-->
<div1 id="revisions">
<head>Revisions from Previous Draft</head>
<revisions/>
</div1>
</back>
</spec>
