<?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/1999/REC-xml-names-19990114/">
 <!ENTITY xsdl "http://www.w3.org/TR/2001/PR-xmlschema-1-20010316/">
 <!ENTITY xlink "http://www.w3.org/TR/2000/PR-xlink-20001220/">
 <!ENTITY charmod 'http://www.w3.org/TR/2001/WD-charmod-20010126/'>
 <!ENTITY html4 'http://www.w3.org/TR/1999/REC-html401-19991224/'>

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

 <!ENTITY year "2001">
 <!ENTITY mm "03">
 <!ENTITY MM "March">
 <!ENTITY dd "16">

 <!ENTITY schema-language "XML Schema definition language">
 
 <!ENTITY thisversion "http://www.w3.org/TR/2001/">
 <!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 v-value "<xtermref href='&xsdl;#key-vv'>actual value</xtermref>">

   <!ENTITY % local.emph.class "|B|font">
   <!ENTITY % local.p.class "|stale|facets|subtypes|
   		inverse-facets|open-issues|revisions|
   		fundamental-facets|applicable-facets|type-hierarchy">
   <!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>
	
	<!ELEMENT type-hierarchy EMPTY>
	<!ELEMENT font (#PCDATA)>
	<!ATTLIST font
		size NMTOKEN #IMPLIED>

	<!ATTLIST spec
		xml:lang NMTOKEN #IMPLIED>
        <!ATTLIST td style CDATA #IMPLIED>
        <!ATTLIST th style CDATA #IMPLIED>
	]>
<spec xml:lang='en'>
<header>
<title>XML Schema Part 2: Datatypes</title>

<version></version>
    <w3c-designation>datatypes-20010316</w3c-designation>
    <w3c-doctype>W3C Proposed Recommendation</w3c-doctype>
<pubdate><day>&dd;</day><month>&MM;</month><year>&year;<!--
Point release id: <code>Id: datatypes.xml,v 1.64 2001/03/16 23:49:39 ht Exp </code>--></year></pubdate>
<notice role="publoc">
<p>
(in <loc href="http://www.w3.org/TR/2001/PR-xmlschema-2-20010316/datatypes.xml">XML</loc> and
<loc href="http://www.w3.org/TR/2001/PR-xmlschema-2-20010316/datatypes.html">HTML</loc>,	with a
<loc href="http://www.w3.org/2001/XMLSchema.xsd">schema</loc> and
<loc href="http://www.w3.org/2001/XMLSchema.dtd">DTD</loc> including datatype definitions,
as well as a <loc href="http://www.w3.org/2001/XMLSchema-datatypes.xsd">schema</loc>
for built-in datatypes only, in a separate namespace.)
</p>
</notice>
<publoc>
<loc href="http://www.w3.org/TR/2001/PR-xmlschema-2-20010316/">http://www.w3.org/TR/2001/PR-xmlschema-2-20010316/</loc>
</publoc>
<prevlocs>
	<loc href="http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/">
		http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/
	</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>Microsoft, formerly of IBM</affiliation>
<email href="mailto:ashokma@microsoft.com">ashokma@microsoft.com</email>
</author>
</authlist>
    <status>
<p>This specification of the XML Schema language is a Proposed
Recommendation of the World Wide Web Consortium.  This means that
the specification is stable and that implementation experience has
been gathered showing that each feature of the specification can be
implemented.  After review by the Consortium's Advisory Committee,
this specification will either be published as a Recommendation, or
(if review shows further changes are required) republished as a
Candidate Recommendation or as a Working Draft.
</p>
<p>Implementors should note that this part of this specification makes a
normative reference to the current version of the Unicode Database,
which specifies properties for characters on which the regular
expression language defined here relies.  A new version of the
Unicode Database is expected to appear between the time this
Proposed Recommendation is published and the time it becomes a W3C
Recommendation; it is expected that the normative reference to the
Unicode Database will be updated accordingly.</p>
     <p>The deadline for review of this document is Monday 16 April 2001.</p>
     <p>Technical and editorial comments should be sent to the publicly
archived <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> mailing list.</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>There have been no declarations regarding patents related to this
specification within the XML Schema Working Group.</p>
      <p>A list of current W3C Recommendations and other technical documents can be found at
        <loc href="http://www.w3.org/TR/">http://www.w3.org/TR/</loc>.</p>
</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
in XML Schemas as well as other XML 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 name, 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-11-21: AM: added sentence on float and double special values.
</sitem>
<sitem>
2000-11-22: AM: fixed minor bugs in lexical and canonical representations of the date/time datatypes.
</sitem>
<sitem>
2000-11-27: AM: removed century and recurringDuration.  Made timeInstant,
timePeriod, recurringDate, recurringDay primitive.
</sitem>
<sitem>
2000-11-27: AM: renamed CDATA to normalizedString.
</sitem>
<sitem>
2000-11-28: AM: made timeInstant and timePeriod primitive datatypes.
Also, recurringDate and recurringDay.
</sitem>
<sitem>
2000-11-28: AM: added new sections on order relations for timeDuration and
timeInstant.  Added Appendix E on addition of timeInstant and durations.
</sitem>
<sitem>
2000-11-28: AM: changed canonical representation for decimal.
</sitem>
<sitem>
2000-11-28: AM: made all date/time datatypes primitive types.
</sitem>
<sitem>
2000-11-28: AM: changed recurringDate to gMonthDay, recurringDay to day and month to yearMonth.
</sitem>
<sitem>
2000-12-21: AM: fixed NMTOKENS, ENTITIES, IDREFS to have minLength = 1.
</sitem>
<sitem>
2000-12-21: AM: changed introductory section on order facet to discuss partial order..
</sitem>
<sitem>
2001-01-22: am: added 1 and 0 to lexical space of boolean.  Created placeholder
section for canonical representtaion for boolean.
</sitem>
<sitem>
2001-01-22: am: Changed section on facet comparison for timeDuration.  
</sitem>
<sitem>
2001-01-22: am: Changed name timeDuration to duration and timeInstant to dateTime.  
</sitem>
<sitem>
2001-01-22: am: Removed binary.  Replaced with hexBinary and base64Binary.
Removed encoding facet.  
</sitem>
<sitem>
2001-02-16: PVB: A whole host of changes that I haven't documented yet.
</sitem>
<sitem>
2001-03-01: PVB: changed the name of uriReference to anyURI as a result
of vote at boston f2f descision
</sitem>
<sitem>
2001-03-08: PVB: moved references to unicode and ISO 10646 to the non-normative
section, since we get their content through the normative ref to XML 1.02e.
</sitem>
<sitem>
2001-03-08: PVB: correctly updated reference to the Jan 2001 CharMod draft
</sitem>
<sitem>
2001-03-08: PVB: removed all Priority Feedback Requests
</sitem>
<sitem>
2001-03-11: PVB: changed am's affiliation
</sitem>
<sitem>
2001-03-11: PVB: added the ability to make a simpleType final, thus
blocking any further derivation
</sitem>
<sitem>
2001-03-11: PVB: added the text that has always been in the schema for
datatypes regarding the unique IDs for datatypes, facets, and datatype/facet
pairs to the beginning of section 3.
</sitem>
<sitem>
2001-03-11: PVB: added language intended to clarify the why the built-in
types are defined in both the schema NS and in the built-in NS
</sitem>
<sitem>
2001-03-11: PVB: added {true,false} as the canonical rep for boolean
</sitem>
<sitem>
2001-03-11: PVB: added definition for derivation by restriction, which
makes it clear that a restriction must result in subseted value space
</sitem>
<sitem>
2001-03-11: PVB: added a SRC which rules out multiple occurances of
facets, other than pattern and enumeration
</sitem>
<sitem>
2001-03-11: PVB: removed fixed attribute from pattern and enumeration facets
</sitem>
<sitem>
2001-03-11: PVB: added note that spaces are discouraged in anyURI
</sitem>
<sitem>
2001-03-11: PVB: added note clarifying that a namespace decl must be
in scope for the lexical-to-value space mapping
</sitem>
<sitem>
2001-03-11: PVB: added "related by union" to the clause that equality
clause that says that values from unrelated types are not equal.
</sitem>
<sitem>
2001-03-11: PVB: fixed definition(s) of bounded, such that the bound
does not necessarily have to be in the value space (to account for
min/maxExclusive) and modified the definitions of min/maxExclusive to
reference the new definitions
</sitem>
<sitem>
2001-03-12: PVB: fixed typo ("although [not=>no] value space...") in
definition of cardinality
</sitem>
<sitem>
2001-03-13: PVB: changed name of decimal to number; precision to totalDigits
and scale to fractionDigits
</sitem>
<sitem>
2001-03-14: pvb: removed references to Unicode and 10646 (but kept
normative ref to the Unicode DB)
</sitem>
<sitem>
2001-03-14: pvb: changed names of day, month, year, monthDay and yearMonth
to gDay, gMonth, gYear, gMonthDay and gYearMonth; also added health warnings
that conversion to other calendar systems may not result in simple values
</sitem>
<sitem>
2001-03-14: pvb: added a note about how to get AND behavior with
patterns
</sitem>
<sitem>
2001-03-14: pvb: updated description of value/lexical space of anyURI,
including note that scheme-specific syntax checking is not part of
type validity.  Also added note that spaces are discouraged, and added
anyURI to the discussion in the section on lists of types with spaces.
</sitem>
<sitem>
2001-03-14: pvb: added health warning to string, stating that it isn't
always appropriate for text
</sitem>
<sitem>
2001-03-14: pvb: made NOTATION primitive, made the value space all QNames,
and removed the constraint that the enumeration given must be that of
the name of a notation declared in the schema.
</sitem>
<sitem>
2001-03-14: pvb: added note that AM used to work for IBM and that his
participation until now was supported by IBM
</sitem>
<sitem>
2001-03-14: pvb: removed Cs from the legal properties in the regex BNF
(it was already absent from the table of properties)
</sitem>
<sitem>
2001-03-14: pvb: removed surrogate blocks from the BlockNames table in
the regex appendix
</sitem>
<sitem>
2001-03-15: pvb: fixed one remaining problem in the defns for bounds
introduced on 2001-03-11.
</sitem>
<sitem>
2001-03-15: pvb: changed all occurances of "namespace URI" to "namespace name"
to be consistent with the latest Infoset draft
</sitem>
<sitem>
2001-03-15: pvb: renamed datatype definition component as simple type definition
component; changed itemType and memberTypes properties to "item type" and "member types"
</sitem>
<sitem>
2001-03-15: pvb: added components for all fundamental facets; moved the
prose that specified how they get their values from the simple type definition
component to each individual component.
</sitem>
<sitem>
2001-03-15: pvb: changed wording in property mapping of annoations to be
the same as that in structures
</sitem>
<sitem>
2001-03-15: pvb: changed final from a boolean to {restirction, list, union}
</sitem>
<sitem>
2001-03-15: pvb: changed pattern-valid and datatype-valid constraints
to check pattern against the lexical-space
</sitem>
<sitem>
2001-03-15: pvb: added "F restriction valid" COS's that rule out all
forms of invalid restriction for each facet F
</sitem>
<sitem>
2001-03-15: pvb: cleaned up equality, and partial and total orders
</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 Microsoft 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 and Java primitive datatypes, 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>;
-->
for any <emph role='eq'>a</emph> and <emph role='eq'>b</emph> in
the <termref def='dt-value-space'/>,
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>;
-->
there is no pair <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
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>;
-->
for all <emph role='eq'>a</emph> in 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>;
-->
for any <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
in 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>.
-->
for any <emph role='eq'>a</emph>, <emph role='eq'>b</emph> and
<emph role='eq'>c</emph> in 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>
<item>
<p>
for any <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
in the <termref def='dt-value-space'/>
if <emph role='eq'>a = b</emph>, then <emph role='eq'>a</emph>
and <emph role='eq'>b</emph> cannot be distinguished
(i.e., equality is identity)
</p>
</item>
</ulist>
<p>
Note that a consequence of the above is that, 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 <termref def='dt-restriction'/>
or <termref def='dt-union'/>,
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>
<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>

</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 that imposes a
<termref def='dt-total-order'/> or a <termref def='dt-partial-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>
<termdef id='dt-partial-order' term='partial order'>
A <term>partial order</term> is an <termref def='dt-order-relation'/>
that is <term>irreflexive</term>, <term>antisymmetric</term> and
<term>transitive</term>.
</termdef>
</p>
<p>
A <termref def='dt-partial-order'/> has the following properties:
</p>
<ulist>
<item>
<p>
<!--
a R a
-->
for no <emph role='eq'>a</emph> in the <termref def='dt-value-space'/>,
<emph role='eq'>a &lt; a</emph>
(irreflexivity)
</p>
</item>
<item>
<p>
<!--
a R b and b R a implies a = b
-->
for all <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
in the <termref def='dt-value-space'/>,
<emph role='eq'>a &lt; b</emph> and <emph role='eq'>b &lt; a</emph>
implies <emph role='eq'>a = b</emph>
(antisymmetry)
</p>
</item>
<item>
<p>
<!--
a R b and b R c implies a R c
-->
for all <emph role='eq'>a</emph>, <emph role='eq'>b</emph>
and <emph role='eq'>c</emph>  in the <termref def='dt-value-space'/>,
<emph role='eq'>a &lt; b</emph> and <emph role='eq'>b &lt; c</emph>
implies <emph role='eq'>a &lt; c</emph>
(transitivity)
</p>
</item>
<!--
<item>
<p>
-->
<!--
Toys R Us
-->
<!--
for all <emph role='eq'>Toys</emph> and <emph role='eq'>Us</emph>
 in the <termref def='dt-value-space'/>,
<emph role='eq'>Toys &lt; Us</emph>
(jeffreyity)
</p>
</item>
-->
<!--
<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>
or <emph role="eq">a &lt;&gt; b</emph> where the symbol &lt;&gt; indicates that
an order between the two values cannot be determined.
</p>
</item>
-->
</ulist>
<p>
The notation <emph role='eq'>a &lt;> b</emph> is used to indicate the
case when <emph role='eq'>a != b</emph> and neither
<emph role='eq'>a &lt; b</emph> nor <emph role='eq'>b &lt; a</emph>
</p>
<p>
<termdef id='dt-total-order' term='total order'>
A <term>total order</term> is an <termref def='dt-partial-order'/>
such that for no <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
is it the case that <emph role='eq'>a &lt;> b</emph>.
</termdef>
</p>
<p>
A <termref def='dt-total-order'/> has all of the properties specified
above for <termref def='dt-partial-order'/>, plus
the following property:
</p>
<ulist>
<item>
<p>
<!--
a R b or b R a
-->
for all <emph role='eq'>a</emph> and <emph role='eq'>b</emph>
 in 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 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 by imposing its own order relation.
</p>
</note>
</div4>

<div4 id="bounds">
<head>Bounds</head>
<p>
<termdef id='dt-inclusive-upper-bound' term='inclusive upper bound'>
A value <emph role='eq'>u</emph> in an <termref def='dt-ordered'/>
&nbsp;<termref def='dt-value-space'/>&nbsp;<emph role='eq'>U</emph>
is said to be an <term>inclusive upper bound</term> of a
<termref def='dt-value-space'/>&nbsp;<emph role='eq'>V</emph>
(where <emph role='eq'>V</emph> is a subset of <emph role='eq'>U</emph>)
if for all <emph role='eq'>v</emph> in <emph role='eq'>V</emph>,
<emph role='eq'>u</emph> >= <emph role='eq'>v</emph>.
</termdef>


<!--
<termdef id='dt-inclusive-upper-bound' term='inclusive upper bound'>
A value <emph role='eq'>U</emph> is said to be an <term>inclusive upper
bound</term> of an <termref def='dt-ordered'/> <termref def='dt-value-space'/>
if <emph role='eq'>U >= v</emph> for all values <emph role='eq'>v</emph>
in the <termref def='dt-value-space'/>.
</termdef>
-->
</p>
<p>
<termdef id='dt-exclusive-upper-bound' term='exclusive upper bound'>
A value <emph role='eq'>u</emph> in an <termref def='dt-ordered'/>
&nbsp;<termref def='dt-value-space'/>&nbsp;<emph role='eq'>U</emph>
is said to be an <term>exclusive upper bound</term> of a
<termref def='dt-value-space'/>&nbsp;<emph role='eq'>V</emph>
(where <emph role='eq'>V</emph> is a subset of <emph role='eq'>U</emph>)
if for all <emph role='eq'>v</emph> in <emph role='eq'>V</emph>,
<emph role='eq'>u</emph> > <emph role='eq'>v</emph>.
</termdef>
<!--
<termdef id='dt-exclusive-upper-bound' term='exclusive upper bound'>
A value <emph role='eq'>U</emph> is said to be an <term>exclusive upper
bound</term> of an <termref def='dt-ordered'/> <termref def='dt-value-space'/>
if <emph role='eq'>U > v</emph> for all values <emph role='eq'>v</emph>
in the <termref def='dt-value-space'/>.
</termdef>
-->
</p>
<p>
<termdef id='dt-inclusive-lower-bound' term='inclusive lower bound'>
A value <emph role='eq'>l</emph> in an <termref def='dt-ordered'/>
&nbsp;<termref def='dt-value-space'/>&nbsp;<emph role='eq'>L</emph>
is said to be an <term>inclusive lower bound</term> of a
<termref def='dt-value-space'/>&nbsp;<emph role='eq'>V</emph>
(where <emph role='eq'>V</emph> is a subset of <emph role='eq'>L</emph>)
if for all <emph role='eq'>v</emph> in <emph role='eq'>V</emph>,
<emph role='eq'>l</emph> &lt;= <emph role='eq'>v</emph>.
</termdef>
<!--
<termdef id='dt-inclusive-lower-bound' term='inclusive lower bound'>
A value <emph role='eq'>L</emph> is said to be an <term>inclusive lower
bound</term> of an <termref def='dt-ordered'/> <termref def='dt-value-space'/>
if <emph role='eq'>L &lt;= v</emph> for all values <emph role='eq'>v</emph>
in the <termref def='dt-value-space'/>.
</termdef>
-->
</p>
<p>
<termdef id='dt-exclusive-lower-bound' term='exclusive lower bound'>
A value <emph role='eq'>l</emph> in an <termref def='dt-ordered'/>
&nbsp;<termref def='dt-value-space'/>&nbsp;<emph role='eq'>L</emph>
is said to be an <term>exclusive lower bound</term> of a
<termref def='dt-value-space'/>&nbsp;<emph role='eq'>V</emph>
(where <emph role='eq'>V</emph> is a subset of <emph role='eq'>L</emph>)
if for all <emph role='eq'>v</emph> in <emph role='eq'>V</emph>,
<emph role='eq'>l</emph> &lt; <emph role='eq'>v</emph>.
</termdef>
<!--
<termdef id='dt-exclusive-lower-bound' term='exclusive lower bound'>
A value <emph role='eq'>L</emph> is said to be an <term>exclusive lower
bound</term> of an <termref def='dt-ordered'/> <termref def='dt-value-space'/>
if <emph role='eq'>L &lt; v</emph> for all values <emph role='eq'>v</emph>
in the <termref def='dt-value-space'/>.
</termdef>
-->
</p>
<!--
<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
<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">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 either an
<termref def='dt-inclusive-upper-bound'/> or an <termref def='dt-exclusive-upper-bound'/>
and either an <termref def="dt-inclusive-lower-bound"/> and an
<termref def="dt-exclusive-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 could
conceivably be uncountably infinite (although no <termref def='dt-value-space'/>
defined by this specification is uncountable 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="hexBinary"/> and <dtref ref="base64Binary"/> and datatypes <termref def="dt-derived"/> from them,
<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 number of 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="hexBinary"/> and <dtref ref="base64Binary"/> and datatypes <termref def="dt-derived"/> from them,
<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 number of 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="hexBinary"/> and <dtref ref="base64Binary"/> and datatypes <termref def="dt-derived"/> from them,
<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 number of 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 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 (line feed) 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 Character Set (UCS) code point <code>hexadecimal A</code> (line feed), which is denoted by
U+000A.  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 <termref def='dt-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
<termref def='dt-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-inclusive-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value of
<term>maxInclusive</term>&nbsp;<termref def="dt-must"/> be 
in the <termref def='dt-value-space'/> of 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-exclusive-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value of <term>maxExclusive</term>
&nbsp;<termref def='dt-must'/> be in the <termref def='dt-value-space'/> of 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-inclusive-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value of
<term>minInclusive</term>
&nbsp;<termref def='dt-must'/> be in the <termref def='dt-value-space'/> of 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-exclusive-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.
The value of <term>minExclusive</term>&nbsp;<termref def="dt-must"/>
be in the <termref def='dt-value-space'/> of the
<termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="totalDigits">
<head>totalDigits</head>
<p>
<termdef id="dt-totalDigits" term="totalDigits"><term>totalDigits</term>
is the maximum number of digits in values of datatypes
<termref def="dt-derived"/> from <dtref ref="number"/>.  The value of
<term>totalDigits</term>&nbsp;<termref def="dt-must"/> be a
<dtref ref="positiveInteger"/>.
</termdef>
</p>
</div4>
<div4 id="fractionDigits">
<head>fractionDigits</head>
<p>
<termdef id="dt-fractionDigits" term="fractionDigits"><term>fractionDigits</term>
is the maximum number of digits in the fractional part
of values of datatypes <termref def="dt-derived"/> from
<dtref ref="number"/>. The value of <term>fractionDigits</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="nonNegativeInteger"/> .
</termdef>
</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="timeeriod"/>
and datatypes <termref def="dt-derived"/> from
<dtref ref="timePeriod"/>. 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 consists of a
finite-length (possibly empty) 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 one 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 white space 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='number'/>
</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 (such as <dtref ref='string'/>
or <dtref ref='anyURI'/>). 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 apply:
</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-pattern"/></p></item>
<item><p><termref def="dt-whiteSpace"/></p></item>
</ulist>
<p>
For each of <termref def='dt-length'/>, <termref def='dt-maxLength'/>
and <termref def='dt-minLength'/>, the <emph>unit of length</emph> is
measured in number of list items.  The value of <termref def='dt-whiteSpace'/>
is fixed to the value <emph>collapse</emph>.
</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"
    	default="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="integer"/> is a special case of the more general datatype
<dtref ref="number"/>.
</p>
<p>
<termdef id='dt-anySimpleType' term='anySimpleType'>
There exists a conceptual datatype, whose name is <term>anySimpleType</term>,
that is the simple version of the
<xtermref href="&xsdl;#key-urType">ur-type definition</xtermref> from
<bibref ref='structural-schemas'/>.  <term>anySimpleType</term> can be
considered as the <termref def='dt-basetype'/> of all <termref def='dt-primitive'/>
types.  The <termref def='dt-value-space'/> of <term>anySimpleType</term>
can be considered to be the <termref def='dt-union'/> of the
<termref def='dt-value-space'/>s of all <termref def='dt-primitive'/> datatypes.
</termdef>
</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="integer"/> is <termref def="dt-derived"/>
from <dtref ref="number"/>.
</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>
<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 that 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>

<div4 id='restriction'>
<head>Derived by restriction</head>
<p>
<!-- add the exception for pattern -->
<termdef id='dt-restriction' term='restriction'>A datatype is said to be
<termref def="dt-derived"/> by <term>restriction</term> from another datatype
values for one or more <termref def="dt-constraining-facet"/>s are specified
that serve to constrain its <termref def='dt-value-space'/> and/or its
<termref def='dt-lexical-space'/> to a subset of those of its
<termref def='dt-basetype'/>.
</termdef>
</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>
</div4>
<div4 id='list'>
<head>Derived by list</head>
<p>
A <termref def='dt-list'/> datatype can be <termref def="dt-derived"/>
from another datatype (its <termref def='dt-itemType'/>) by creating
a <termref def='dt-value-space'/> that consists of a finite-length sequence
of values of its <termref def='dt-itemType'/>.
</p>
</div4>
<div4 id='union'>
<head>Derived by union</head>
<p>
One datatype can be <termref def="dt-derived"/> from one or more
datatypes by <termref def='dt-union'/>ing their <termref def="dt-value-space"/>s
and, consequently, their <termref def="dt-lexical-space"/>s.
</p>
</div4>
</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>
<type-hierarchy/>
<p>
      Each built-in datatype in this specification (both
      <termref def='dt-primitive'/> and
      <termref def='dt-derived'/>) can be uniquely addressed via a
      URI Reference constructed as follows:
</p>
<olist>
<item><p>the base URI is the URI of the XML Schema namespace</p></item>
<item><p>the fragment identifier is the name of the datatype</p></item>
</olist>
<p>        
      For example, to address the <dtref ref='int'/> datatype, the URI is:
</p>
<ulist>
      <item><p><code>http://www.w3.org/2000/10/XMLSchema#int</code></p></item>
</ulist>
<p>
      Additionally, each facet definition element can be uniquely
      addressed via a URI constructed as follows:
</p>
<olist>
<item><p>the base URI is the URI of the XML Schema namespace</p></item>
<item><p>the fragment identifier is the name of the facet</p></item>
</olist>
<p>
      For example, to address the maxInclusive facet, the URI is:
</p>
<ulist>
      <item><p><code>http://www.w3.org/2000/10/XMLSchema#maxInclusive</code></p></item>
</ulist>
<p>
      Additionally, each facet usage in a built-in datatype definition
      can be uniquely addressed via a URI constructed as follows:
</p>
<olist>
<item><p>the base URI is the URI of the XML Schema namespace</p></item>
<item><p>the fragment identifier is the name of the datatype, followed
	by a period (".") followed by the name of the facet</p></item>
</olist>
<p>        
      For example, to address the usage of the maxInclusive facet in
      the definition of int, the URI is:
</p>
<ulist>
      <item><p><code>http://www.w3.org/2000/10/XMLSchema#int.maxInclusive</code></p></item>
</ulist>
<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 usage within the &schema-language;, the <termref def="dt-built-in"/>
datatypes in this specification have the namespace name:
</p>
<ulist>
<item><p>http://www.w3.org/2001/XMLSchema</p></item>
</ulist>
<p>
To facilitate usage in specifications other than the &schema-language;,
such as those that do not want to know anything about aspects of the
&schema-language; other than the datatypes, each <termref def="dt-built-in"/>
datatype is also defined in the namespace whose URI is:
</p>
<ulist>
<item><p>http://www.w3.org/2001/XMLSchema-datatypes</p></item>
</ulist>
<p>
This applies to both
<termref def="dt-built-in"/>&nbsp;<termref def="dt-primitive"/> and
<termref def="dt-built-in"/>&nbsp;<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>
</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 Character Set code point, which is an integer.
</termdef>
</p>
<note>
<p>
Many human languages have writing systems that require
child elements for control of aspects such as bidirectional formating or
ruby annotation (see <bibref ref='ruby'/> and Section 8.2.4
<xspecref href='&html4;struct/dirlang.html#h-8.2.4'>Overriding the
bidirectional algorithm: the BDO element</xspecref> of <bibref ref='html4'/>).
Thus, <term>string</term>, as a simple type that can contain only
characters but not child elements, is often not suitable for representing text.
In such situations, a complex type that allows mixed content should be considered.
For more information, see Section 5.5
<xspecref href='http://www.w3.org/TR/2001/PR-xmlschema-0-20010316/#textType'>Any Element, Any Attribute</xspecref>
of <bibref ref='schema-primer'/>.
</p>
</note>
<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 literals {true, false, 1, 0}.
</p>
</div4>
<div4 id="boolean-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>boolean</term> is the set of
literals {true, false}.
</p>
</div4>
<div4 id="boolean-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="number">
<head>number</head>
<p>
<termdef id="dt-number" term="number"><term>number</term>
represents arbitrary precision decimal numbers.
The <termref def="dt-value-space"/> of <term>number</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>number</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
<termdef id="dt-number-with-totalDigits" term="number-with-totalDigits">
The <termref def="dt-value-space"/> of types derived from <term>number</term>
with a value for <termref def="dt-totalDigits"/> 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-number-with-fractionDigits" term="number-with-fractionDigits">
The <termref def="dt-value-space"/> of types derived from <term>number</term>
with a value for <termref def="dt-fractionDigits"/> 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-totalDigits"/> 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="number-lexical-representation">
<head>Lexical representation</head>
<p>
<term>number</term> has a lexical representation
consisting of a finite-length sequence of decimal digits (#x30-#x39) separated
by a period as a decimal indicator.  If <termref def='dt-totalDigits'/> is
specified, the number of digits must be less than or equal to
<termref def='dt-totalDigits'/>.
If <termref def='dt-fractionDigits'/> is specified, the
number of digits following the decimal point must be less than or equal to
the <termref def='dt-fractionDigits'/>.  An optional leading sign is allowed.
If the sign is omitted, "+" is assumed.  Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example: <code>-1.23, 12678967.543233, +100000.00, 210</code>.
</p>
</div4>
<div4 id="number-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>number</term> is defined by
prohibiting certain options from the
<specref ref="number-lexical-representation"/>.  Specifically, the preceding
optional "+" sign is prohibited.  The decimal point is required. Leading and 
trailing zeroes are prohibited subject to the following: there must be at least
one digit to the right and to the left of the decimal point which may be a zero.
</p>
</div4>
<div4 id="number-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="number-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</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 and 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.
Positive zero is greater than negative zero. Not-a-number equals itself and is
greater than all float values including positive infinity.
</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">