<?xml version='1.0'?>
<?xml:stylesheet type='text/xsl' href='dtspec.xsl'?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification::19990205//EN" "xmlspec-19990429.dtd" [
  <!ENTITY % versionEntities SYSTEM "versionInfo.ent">
%versionEntities; <!-- get path and date entities -->
 <!ENTITY cellback '#d0d9fa'>

 <!ENTITY xmlspec "http://www.w3.org/TR/REC-xml">
 <!ENTITY xmlnsspec "http://www.w3.org/TR/REC-xml-names/">
 <!ENTITY xmlinfosetspec "http://www.w3.org/TR/xml-infoset">
 <!ENTITY xsdl "&XSP1.base;">

 <!ENTITY schemaWG "<loc href='http://www.w3.org/XML/Activity#schema-wg'>W3C XML Schema Working Group</loc>">

 <!ENTITY year "&draft.year;">
 <!ENTITY mm "&draft.MM;">
 <!ENTITY MM "&draft.month;">
 <!ENTITY dd "&draft.DD;">
 <!ENTITY MMDD "&mm;&dd;">
 <!ENTITY iso.doc.date "&year;&MMDD;">

 <!ENTITY schema-language "XML Schema definition language">
 
 <!ENTITY thisversion "&draft.base;/">
 <!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;">

<!-- 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 fundamental-facets EMPTY>
   
   <!ENTITY % local.p.class "|stale|facets|subtypes|
   		inverse-facets|open-issues|revisions|fundamental-facets|applicable-facets">
   <!ENTITY % local.termdef.class "|propdef">
   <!ENTITY % local.ref.class "|propref|xpropref|eltref|compref|dtref">
   <!ENTITY % local.illus.class "|compdef|reprdef|proplist">
   <!ENTITY i-attribute "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>attribute</xpropref>">
   <!ENTITY i-children "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>children</xpropref>">
   <!ENTITY i-child "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>child</xpropref>">
   <!ENTITY i-attributes "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.element'>attributes</xpropref>">
   <!ENTITY i-attrChildren "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>children</xpropref>">
   <!ENTITY i-value "<xpropref href='http://www.w3.org/TR/xml-infoset#infoitem.attribute'>value</xpropref>">
   <!ENTITY i-ccode "<xpropref
href='http://www.w3.org/TR/xml-infoset#infoitem.character'>character code</xpropref>">

	<!ELEMENT applicable-facets EMPTY>
	<!ELEMENT facets EMPTY>
	<!ELEMENT subtypes EMPTY>
	<!ELEMENT inverse-facets EMPTY>
	<!ATTLIST inverse-facets
		name CDATA #REQUIRED>
	<!ELEMENT open-issues EMPTY>
	<!ELEMENT revisions EMPTY>
	
	<!ATTLIST table
		align CDATA #IMPLIED
		bgcolor CDATA #IMPLIED>
	]>
<spec>
<header>
<title>XML Schema Part 2: Datatypes</title>
<!-- need to fix these links -->
<version></version>
    <w3c-designation>&WD-XSP2;-&iso.doc.date;</w3c-designation>
    <w3c-doctype>W3C Working Draft</w3c-doctype>
<pubdate><day>&dd;</day><month>&MM;</month><year>&year;<!--
Point release id: <code>$Id: datatypes.xml,v 1.36 2000/09/22 21:46:08 ht Exp $</code>--></year></pubdate>
<notice role="publoc">
<p>
<!--
<ednote><edtext>need to fix these links, they're all wrong</edtext></ednote>
-->
(in <loc href="&XSP2.URI;.xml">XML</loc> and
<loc href="&XSP2.base;/">HTML</loc>,	with a
<loc href="&XMLSchemaDatatypesNS;.xsd">schema</loc> and
<loc href="&XMLSchemaDatatypesNS;.dtd">DTD</loc> including datatype definitions,
as well as a <loc href="&XMLSchemaBuiltinsNS;.xsd">schema</loc>
for built-in datatypes only, in a separate namespace.)
</p>
</notice>
<publoc>
<loc href="&XSP2.base;/">&XSP2.base;/</loc>
</publoc>
<prevlocs>
	<loc href="http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/">
		http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
	</loc>
</prevlocs>
<latestloc>
	<loc href="http://www.w3.org/TR/xmlschema-2/">
		http://www.w3.org/TR/xmlschema-2/
	</loc>
</latestloc>
<authlist>
<author>
<name>Paul V. Biron</name>
<affiliation>Kaiser Permanente, for Health Level Seven</affiliation>
<email href="mailto:Paul.V.Biron@kp.org">Paul.V.Biron@kp.org</email>
</author>
<author>
<name>Ashok Malhotra</name>
<affiliation>IBM</affiliation>
<email href="mailto:petsa@us.ibm.com">petsa@us.ibm.com</email>
</author>
</authlist>
<status>
<p>
This is an internal working draft for review by members of the Working Group.
</p>
<p>
It has not been reviewed by the XML Schema Working Group and the Working Group has
not agreed to its publication. Note that not that all sections of the draft
represent the current consensus of the WG. Different sections of the specification
may well command different levels of consensus in the WG. Public comments on this
draft will be instrumental in the WG's deliberations.
</p>
<p>
This working draft incorporates all WG decisions through 2000-08-02, and some 
decisions taken since then.
</p>
<p>Although the Working Group does not anticipate further
changes to the functionality described here, this is still a working
draft, subject to change.  The present version should
be implemented only by those interested in providing a check on
its design or by those preparing for an implementation of the
Candidate Recommendation. <emph>The Schema WG will
not allow early implementation to constrain its ability to make changes to this
specification prior to final release. </emph>
</p>
<p>
During the Candidate Recommendation phase, although feedback based on
implementation experience is welcome, there are certain aspects of the
design presented herein where the Working Group is particularly interested
in feedback. These are designated <emph>priority feedback</emph> aspects of
the design, and identified as such in editorial notes throughout this draft.
</p>
<p>
A list of current W3C working drafts can be found at
<loc href="http://www.w3.org/TR/">http://www.w3.org/TR/</loc>. They may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use W3C Working Drafts as reference material or to cite them
as other than "work in progress".
</p>
<p>
Several "note types" are used throughout this draft:
</p>
<glist>
<gitem><label>issue [Issue (issue-name): ]</label>
<def>
<p>something on which the editors are seeking comment.</p>
</def>
</gitem>
<gitem><label>editorial note [Ed. Note: ]</label>
<def>
<p>
something the editors wish to call to the attention of the
reader. To be removed prior to the recommendation becoming final.
</p>
</def>
</gitem>
<gitem><label>note [Note: ]</label>
<def>
<p>
something the editors wish to call to the attention of the reader.
To remain in the final recommendation.
</p>
</def>
</gitem>
</glist>
</status>
<abstract>
<p>
XML Schema: Datatypes is part 2 of a two-part draft of the specification
for the XML Schema definition language. This document proposes 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
concensus 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 dataypes.
</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>
-->
<!-- these are changes to implement berkeley f2f decisions -->
<!--
<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 refered to Name instead of NCName
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved IDREF to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Added an issue about whether this could be generated from ID.
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved IDREFS to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string)....this is
just a temporary home and it will become generated as list of IDREF when I get
the list stuff implemented
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved ENTITY to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
Also added a SVC that entity values must match a declared unparsed entity name.
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved ENTITIES to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string)....this is
just a temporary home and it will become generated as list of ENTITY when I get
the list stuff implemented
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: moved NOTATION to a primitive type (since it has validation
requirements above and beyond those provided for subtypes of string).
Also added a Note: to it making explicit the fact that the value space is scoped
to an instance document (unlike the value space of types such as integer).
Also added a SVC that notation values must match a declared notation name.
[part of the resolution to issue 81]
</sitem>
<sitem>
2000-02-15: pvb: updated table in appendix C1, to note that all datatypes
are exact
</sitem>
<sitem>
2000-02-16: pvb: added i4, i8, u4, u8, etc. subtypes of integer, using
editor's discretion in their naming as instructed at the berkeley f2f...changed the
first example in section 4 "Defining Generated Datatypes" to use the Sku
datatype from Part 0, instead of i4 since we now have i4 built-in
</sitem>
<sitem>
2000-02-16: pvb: removed issue: definition-overriding from the draft
</sitem>
<sitem>
2000-02-17: pvb: removed the exact vs. approximate distinction entirely
(since all our types turned out to be exact)
</sitem>
<sitem>
2000-02-17: pvb: removed all mention of aggregate datatypes.  Changed
the "atomic vs. aggregate" dichotomy to be: atomic vs. list.
[part of resolution to issue 112]
</sitem>
<sitem>
2000-02-17: pvb: clarified defns of value space and lexical space.  In
particular, moved the notion of a literal denoting a value from the defn
to LS to VS and noted that a literal is a character information item from
the info set.
</sitem>
<sitem>
2000-02-17: pvb: changed terminology of "generated" to "derived", to be
in alignment with the structures spec
[part of resolution to issue 204]
</sitem>
<sitem>
2000-02-17: pvb: removed definition of term subtype, changed all prose of the
form "for subtypes of X" to "for datatypes derived from X"
[part of resolution to issue 204]
</sitem>
<sitem>
2000-02-17: pvb: removed a para from Conformance section which mentioned
processor option of turning off validation of certain facets
</sitem>
<sitem>
2000-02-17: pvb: removed note that order-relations are not defined
</sitem>
<sitem>
2000-02-17: pvb: made IDREFS, ENTITIES and NMTOKENS derived by list from
IDREF, ENTITY and NMTOKENS respectively.
[part of resolution of issue 81]
</sitem>
<sitem>
2000-02-17: pvb: clarified what the values {hex,base64} mean for the
encoding facet
</sitem>
<sitem>
2000-02-17: pvb: added pointers from the 4 mechanisms to create a value space
to the places in the spec where those mechanisms are described
</sitem>
<sitem>
2000-02-17: pvb: all built-in generated types are now defined in the
schema for datatypes
</sitem>
<sitem>
2000-02-21: pvb: clarified list datatypes, wrt use of component type
which allows whitespace in its literals and wrt facets applicable for
deriving subtypes of a list type
</sitem>
<sitem>
2000-02-23: pvb: change defn of binary and meaning of length facet
for binary to be measured in octets, since both lexical encodings
are only defined for octet multiples.
</sitem>
<sitem>
2000-02-23: pvb: incorporated prose description of regex language
(thanx to Matt Timmermans!!!!)
</sitem>
<sitem>
2000-02-23: pvb: added appinfo's to built-in definitions in the
schema for datatypes, which are used to generate the list of
constraining facets for each built-in datatype in the html version
of the spec
</sitem>
<sitem>
2000-02-23: pvb: replaced abstract syntax with 2 new sections for
"schema components" and "xml representation" constructs, still needs
a lot of editorial work tho
</sitem>
<sitem>
2000-02-23: pvb: list of derived types for each built-in type
is now auto-generated from the builtins.xsd
</sitem>
<sitem>
2000-02-23: pvb: appendix C.2 (list of datatypes to which each
facet applies) is now auto-generated form the builtins.xsd
</sitem>
<sitem>
2000-02-24: pvb: put equality back in as a fundamental facet,
to help with the vote on today's telcon regarding key, unique
and keyref value matching.
</sitem>
<sitem>
2000-02-24: pvb: added 'datatype valid' validation constraint
</sitem>
<sitem>
2000-02-24: pvb: added stub for 'facet valid' validation constraint
</sitem>
<sitem>
2000-03-01: pvb: fixed inconsistency in specification of length related
facets for binary type: all are now specified in octets
</sitem>
<sitem>
2000-03-02: pvb: removed paragraph from section describing the ordered
facet/property which talked about the possibility of multiple order
relations on a value-space
</sitem>
<sitem>
2000-03-02: pvb: table in appendix C.1 is now auto-generated from
appinfo supplied info w/i the schema for built-ins (builtins.xsd)
</sitem>
<sitem>
2000-03-03: pvb: changed non-norm reference to SQL to be the
actual ISO bibref
</sitem>
<sitem>
2000-03-04: pvb: fixed bug in defn of regex, to allow for the
empty regex
</sitem>
<sitem>
2000-03-08: am: changed date and time datatypes completely (yet again).
</sitem>
<sitem>
2000-03-10: pvb: added separate appendix for schema for built-in types
</sitem>
<sitem>
2000-03-10: pvb: changed example for precision facet (old one didn't
apply)
</sitem>
<sitem>
2000-03-10: pvb: change case on facets and type names to be Pascal-like:
effected facets minlength and maxlength; and datatypes uri-reference,
non-positive-integer, non-negative-integer, negitive-integer,
positive-integer, unsigned-long, unsigned-int, unsigned-short,
unsigned-byte.
</sitem>
<sitem>
2000-03-10: pvb: fixed example for enumeration facet (to use
recurringDate instead of date for its basetype.
</sitem>
<sitem>
2000-03-14: am: updated date/time types (yet again): changed
recurringInstant into recurringDuration, made timeInstant
derived from recurringDuration instead of primitive, added timePeriod,
month, year, century, recurringDate, and recurringDay
</sitem>
<sitem>
2000-03-14: am: modified description of lists of atomic types
that allow whitespace in their literals so that it is clearer
</sitem>
<sitem>
2000-03-15: pvb: added text (written by Mark Reinhold) to float &amp;
double describing the "best approximation" required for mapping
from lexical to value space
</sitem>
<sitem>
2000-03-15: pvb: cleaned up description of lexical reps for numeric
types
</sitem>
<sitem>
2000-03-15: pvb: added some explanatory text to the beginning of
sections 4 and 5
</sitem>
<sitem>
2000-03-15: pvb: made it clear (in section 4.1) that a datatype's
facets consist of the facets directly specified in the defn as well
as the set inherited from its basetype
</sitem>
<sitem>
2000-03-15: pvb: cleaned up datatype-valid "validity constribution".
</sitem>
<sitem>
2000-03-15: pvb: added facet-valid "validity contributions" for each
facet in section 4 (some just stubs at this point)
</sitem>
<sitem>
2000-03-15: pvb: moved bibl for clinger1990 from non-normative to
normative, since we are now requiring his "best approximation" for
float/double
</sitem>
<sitem>
2000-03-16: am: Changed section 2.5.1.2 List Datatypes
</sitem>
<sitem>
2000-03-16: am: Changed section 5.1.2 List Datatype
</sitem>
<sitem>
2000-03-16: am: Changed section 5.2.1 Length example
</sitem>
<sitem>
2000-03-16: am: Fixed sections 5.1.13 and 5.2.14
</sitem>
<sitem>
2000-03-16: am: Changed section on lex rep for
unsignedLong, unsignedInt, unsignedShort and unsignedByte to remove
optional sign (after all, they are "unsigned").  Also fixed examples. 
</sitem>
<sitem>
2000-03-16: am: Changed lex rep section for timePeriod.
</sitem>
<sitem>
2000-03-16: am: Changed section on timePeriod.
</sitem>
<sitem>
2000-03-16: am: Removed 2 ednotes from date section.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from month.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from year.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednote from century.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from recurringDate.  Fixed description.
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from recurringDay. 
</sitem>
<sitem>
2000-03-16: am: Added wording to 4.2.4 and 4.2.5
</sitem>
<sitem>
2000-03-16: am: Removed ednotes from section 4 sections on min/max
inclusive/exclusive.  dates and times compare chronologically.
</sitem>
<sitem>
2000-03-16: pvb: fixed several problems with the regex appx:
a) a branch is 0 or more (not 1 or more) (empty regex matches the empty
string);
b) added numeric quantifiers ({n,m}, etc.);
c) fixed bug if meaning of S*;
d) added { and } to list of metacharacters and "single character escapes";
e) noted that a "normal character" can be represented as a character
reference;
f) added syntax for identifying blocks (e.g., \p{IsBasicLatin})
</sitem>
<sitem>
2000-03-16: pvb: make QName into a primitive, with value space the
set of tuples {namespace URI, localPart}.  Semantically, this is how it
should be defined, but it kind of breaks our type system: QName is now
clearly not an atomic type (it is an aggregate defined in terms of two
other existing types), which means that it shouldn't be primitive and
should be derived, but we don't have type generators...oh, well.
</sitem>
<sitem>
2000-03-16: pvb: uriReference lexical space now specified as strings
matching the URI-reference production from RFC 2396...still need to
generate a regex corresponding to that production
</sitem>
<sitem>
2000-03-17: pvb: moved all COS constraints into the appropriate
subsection of section 4 "datatype components"
</sitem>
<sitem>
2000-03-17: pvb: clarified statement in enumeration facet that it
imposes no order on the value space constructed
</sitem>
<sitem>
2000-03-17: pvb: clarified precision/scale to be a maximum number
of digits
</sitem>
<sitem>
2000-03-17: pvb: completed most of the facet-valid
"validity contributions" which began as just stubs, still a few more
to go
</sitem>
<sitem>
2000-03-17: pvb: explicitly defined the notion of an order relation
(which was mentioned, but not defined)
</sitem>
<sitem>
2000-03-17: pvb: corrected defn of string to state that the
order relation (and not the ordered property) as unicode code point
</sitem>
<sitem>
2000-03-17: pvb: clarified length, minLength and maxLength facets;
namely, that string is measured in code points (rather than the ambiguous
"character"), that binary is measured in octets of the binary data 
(not the lexical/encoded data), and specified meaning of these facets
for lists (only length was specified before)
</sitem>
<sitem>
2000-03-17: pvb: added defns for "constraint on schema", "schema
representation constraint" and "validation contribution" (largely stolen
from structures) to terminology section
</sitem>
<sitem>
2000-03-17: pvb: replaced Conformance section with a subset of the
equivalent section from structures
</sitem>
<sitem>
2000-03-17: pvb: added schema representation constraints for
multiple patterns and enumerations
</sitem>
<sitem>
2000-03-17: pvb: explicitly defined order relations for
float, double, timeDuration and recurringDuration
</sitem>
<sitem>
2000-04-03: pvb: corrected NOTE on ENTITY datatype to say 'defined in a DTD'
rather than a schema
</sitem>
<sitem>
2000-04-03: pvb: fixed presentation of table in "Constraint on Schemas: applicable facets"
</sitem>
<sitem>
2000-04-03: pvb: replaced empty validity contributions on encoding, duration and
period facet components with NOTEs that they don't participate in validation
</sitem>
<sitem>
2000-04-03: pvb: removed "open issues" appendix
</sitem>
<sitem>
2000-04-03: pvb: removed all terms in the "terminology" section which weren't used...also
made all *uses* of the remaining terms into links to their definitions
</sitem>
<sitem>
2000-04-03: pvb: styled constraints on schema, etc. in tables, with the table header color
coded to indicate the type of constraint
</sitem>
<sitem>
2000-04-03: pvb: modified section on Equality, to note that equality is defined (to be
not equal) across value spaces not related via restriction.
</sitem>
<sitem>
2000-04-03: pvb: incorporated new {schema,dtd} for datatypes
</sitem>
<sitem>
2000-04-04: pvb: replaced ednotes in 5.1.2 with some simple expository text, probably will
need to be expanded on before CR
</sitem>
<sitem>
2000-04-04: pvb: rewrote description of truncated forms of timeDuration, so that
it was more explicit about what is allowed
</sitem>
 End of commented out section -->
<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:
</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>
</slist>
</revisiondesc>
</header>
<body>
<div1 id="Intro">
<head>Introduction</head>
<div2 id="purpose">
<head>Purpose</head>
<p>
The <bibref ref="XML"/> specification defines limited
facilities for applying datatypes to document content in that documents
may contain or refer to DTDs that assign types to elements and attributes.
However, document authors, including authors of traditional
<emph>documents</emph> and those transporting <emph>data</emph> in XML,
often require a higher degree of type checking to ensure robustness in
document understanding and data interchange.
</p>
<p>
The table below offers two typical examples of XML instances
in which datatypes are implicit: the instance on the left
represents a billing invoice, the instance on the
right a memo or perhaps an email message in XML.
</p>
<table border="1" bgcolor="&cellback;">
<thead>
<tr>
<th align="center">Data oriented</th>
<th align="center">Document oriented</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<eg><![CDATA[<invoice>
   <orderDate>1999-01-21</orderDate>
   <shipDate>1999-01-25</shipDate>
   <billingAddress>
      <name>Ashok Malhotra</name>
      <street>123 IBM Ave.</street>
      <city>Hawthorne</city>
      <state>NY</state>
      <zip>10532-0000</zip>
   </billingAddress>
   <voice>555-1234</voice>
   <fax>555-4321</fax>
</invoice>]]></eg>
</td>
<td>
<eg><![CDATA[<memo importance='high'
      date='1999-03-23'>
   <from>Paul V. Biron</from>
   <to>Ashok Malhotra</to>
   <subject>Latest draft</subject>
   <body>
      We need to discuss the latest
      draft <emph>immediately</emph>.
      Either email me at <email>
      mailto:paul.v.biron@kp.org</email>
      or call <phone>555-9876</phone>
   </body>
</memo>]]></eg>
</td>
</tr>
</tbody>
</table>
<p>
The invoice contains several dates and telephone numbers, the postal
abbreviation for a state
(which comes from an enumerated list of sanctioned values), and a ZIP code
(which takes a definable regular form).  The memo contains many
of the same types of information: a date, telephone number, email address
and an "importance" value (from an enumerated
list, such as "low", "medium" or "high").  Applications which process
invoices and memos need to raise exceptions if something that was
supposed to be a date or telephone number does not conform to the rules
for valid dates or telephone numbers.
</p>
<p>
In both cases, validity constraints exist on the content of the
instances that are not expressible in XML DTDs.  The limited datatyping
facilities in XML have prevented validating XML processors from supplying
the rigorous type checking required in these situations.  The result
has been that individual applications writers have had to implement type
checking in an ad hoc manner.  This specification addresses
the need of both document authors and applications writers for a robust,
extensible datatype system for XML which could be incorporated into
XML processors.  As discussed below, these datatypes could be used in other
XML-related standards as well.
</p>
</div2>
<div2 id="requirements">
<head>Requirements</head>
<p>
The <bibref ref="schema-requirements"/> document spells out
concrete requirements to be fulfilled by this specification,
which state that the XML Schema Language must:
</p>
<olist>
<item>
<p>
provide for primitive data typing, including byte, date,
integer, sequence, SQL &amp; Java primitive data types, etc.;
</p>
</item>
<item>
<p>
define a type system that is adequate for import/export
from database systems (e.g., relational, object, OLAP);
</p>
</item>
<item>
<p>
distinguish requirements relating to lexical data representation
vs. those governing an underlying information set;
</p>
</item>
<item>
<p>
allow creation of user-defined datatypes, such as
datatypes that are derived from existing datatypes and which
may constrain certain of its properties (e.g., range,
precision, length, format).
</p>
</item>
</olist>
</div2>
<div2 id="scope">
<head>Scope</head>
<p>
This portion of the XML Schema Language discusses datatypes that can be
used in an XML Schema.  These datatypes can be specified for element
content that would be specified as
<xspecref href="&xmlspec;#dt-chardata">#PCDATA</xspecref> and attribute
values of <xspecref href="&xmlspec;#sec-attribute-types">various
types </xspecref> in a DTD.  It is the intention of this specification
that it be usable outside of the context of XML Schemas for a wide range
of other XML-related activities such as <bibref ref="XSL"/> and
<bibref ref="RDFSchema"/>.
</p>
</div2>
<div2 id="terminology">
<head>Terminology</head>
<p>
The terminology used to describe XML Schema Datatypes is defined in the
body of this specification. The terms defined in the following list are
used in building those definitions and in describing the actions of a
datatype processor:
</p>
<glist>
<gitem>
<label>
<termdef id="dt-compatibility" term="for compatibility">
for compatibility</termdef>
</label>
<def>
<p>
A feature of this specification included solely to ensure that schemas
which use this feature remain compatible with <bibref ref="XML"/>
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-may" term="may"><term>may</term></termdef>
</label>
<def>
<p>
Conforming documents and processors are permitted to but need
not behave as described.
</p>
</def>
</gitem>
<gitem>
<label>
<termdef id="dt-match" term="match"><term>match</term></termdef>
</label>
<def>
<p>
(Of strings or names:) Two strings or names being compared
 <termref def="dt-must"/> be character for character the same.
</p>
</def>
</gitem>
<!--
<gitem>
<label>
<termdef id='dt-identical' term='identical'>identical</termdef>
</label>
<def>
<p>
(Of <pt>URI</pt>s) <emph>identical</emph>, according to the rules
for identity in <bibref ref='XMLNS'/>.
</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="Validity Contribution">
<term>Validity Contribution</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 may 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 (literals may appear as one or more
<xspecref href="&xmlinfosetspec;#infoitem.character">character
information item</xspecref>s as defined in <bibref ref="XML-Infoset"/>).
</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>
</div2>
<div2 id="canonical-lexical-representation">
<head>Canonical Lexical Representation</head>
<p>
While the dataypes 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 may be
several literals for one of the date or time datatypes that denote the
same value using different timezone indicators.  In such cases, this
specification defines a <termdef term="canonical lexical representation"
id="dt-canonical-representation"> <term>canonical lexical representation</term>,
or <term>canonical representation</term> for short,
which selects a set of literals from among the valid set of literals
for the datatype such that each literal maps to a single value in
the <termref def="dt-value-space"/> and vice-versa.
</termdef>
</p>
</div2>
<div2 id="facets">
<head>Facets</head>
<p>
<termdef id="dt-facet" term="facet">A <term>facet</term> is a single
defining aspect of a <termref def="dt-value-space"/>.  Generally
speaking, each facet characterizes a <termref def="dt-value-space"/>
along independent axes or dimensions.</termdef>
</p>
<p>
The facets of a datatype serve to distinguish those aspects of
one datatype which <emph>differ</emph> from other datatypes.
Rather than being defined solely in terms of a prose description
the datatypes in this specification are defined in terms of
the <emph>synthesis</emph> of facet values which together determine the
<termref def="dt-value-space"/> and properties of the datatype.
</p>
<p>
Facets are of two types: <emph>fundamental</emph> facets that define
the datatype and <emph>non-fundamental</emph> or <emph>constraining
</emph> facets that constrain the permitted values of a datatype.
</p>
<div3 id="fundamental-facets">
<head>Fundamental facets</head>
<p>
<termdef id="dt-fundamental-facet" term="fundamental facet">
A <term>fundamental facet</term> is an abstract property which
serves to semantically characterize the values in a
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
These properties are discussed in this section.
</p>
<div4 id="equal">
<head>Equal</head>
<p>
Every <termref def="dt-value-space"/> supports the notion of equality,
with the following rules:
</p>
<ulist>
<item>
<p>
for any two instances of values from the <termref def="dt-value-space"/>
<emph role="eq">(a,b)</emph>, either <emph role="eq">a</emph> is equal
to <emph role="eq">b</emph>, denoted <emph role="eq">a = b</emph>, or
<emph role="eq">a</emph> is not equal to <emph role="eq">b</emph>,
denoted <emph role="eq">a != b</emph>;
</p>
</item>
<item>
<p>
there is no pair of instances (<emph role="eq">a, b</emph>) of values
from the <termref def="dt-value-space"/> such that both
<emph role="eq">a = b</emph> and <emph role="eq">a != b</emph>;
</p>
</item>
<item>
<p>
for every value a from the <termref def="dt-value-space"/>,
<emph role="eq">a = a</emph>;
</p>
</item>
<item>
<p>
for any two instances <emph role="eq">(a, b)</emph> of values from the
<termref def="dt-value-space"/>, <emph role="eq">a = b</emph> if and
only if <emph role="eq">b = a</emph>;
</p>
</item>
<item>
<p>
for any three instances <emph role="eq">(a, b, c)</emph> of values from
the <termref def="dt-value-space"/>, if <emph role="eq">a = b</emph>
and <emph role="eq">b = c</emph>, then <emph role="eq">a = c</emph>.
</p>
</item>
</ulist>
<p>
On every datatype, the operation Equal is defined in terms of the equality
property of the <termref def="dt-value-space"/>: for any values
<emph role="eq">a, b</emph> drawn from the
<termref def="dt-value-space"/>, <emph role="eq">Equal(a,b)</emph> is
true if <emph role="eq">a = b</emph>, and false otherwise.
</p>

<p>
By definition, given <termref def="dt-value-space"/>
<emph role="eq">A</emph> and <termref def="dt-value-space"/>
<emph role="eq">B</emph> where <emph role="eq">A</emph> and
<emph role="eq">B</emph> are not related by
<termref def="derivation-by-restriction"/>,
for every pair of values <emph role="eq">a</emph> from
<emph role="eq">A</emph> and <emph role="eq">b</emph> from
<emph role="eq">B</emph>, <emph role="eq">a != b</emph>.
</p>

</div4>

<div4 id="order">
<head>Order</head>
<p>
<termdef id="dt-order-relation" term="order-relation">An
<term>order relation</term> on a <termref def="dt-value-space"/>
is a mathematical relation which imposes a total order on the
members of the <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-ordered" term="ordered">A
<termref def="dt-value-space"/>, and hence a datatype, is said to be
<term>ordered</term> if there exists an
<termref def="dt-order-relation"/> defined for that
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<term>order relations</term> have the following rules:
</p>
<ulist>
<item>
<p>
for every pair <emph role="eq">(a, b)</emph> from the
<termref def="dt-value-space"/>, either <emph role="eq">a &lt; b</emph>
or <emph role="eq">b &lt; a</emph>, or <emph role="eq">a = b</emph>;
</p>
</item>
<item>
<p>
for every triple <emph role="eq">(a, b, c)</emph> from the
<termref def="dt-value-space"/>, if <emph role="eq">a &lt; b</emph> and
<emph role="eq">b &lt; c</emph>, then <emph role="eq">a &lt; c</emph>.
</p>
</item>
</ulist>
<note>
<p>
The fact that this specification does not define an
<termref def='dt-order-relation'/> for some datatype does not
mean that some other application cannot treat that datatype as
being ordered.
</p>
</note>
</div4>

<div4 id="bounds">
<head>Bounds</head>
<p>
<termdef id="dt-bounded-above" term="bounded above">
A <termref def="dt-value-space"/> is <term>bounded above</term> if there
exists a unique value <emph role="eq">U</emph> in the
<termref def="dt-value-space"/> such that, for all values
<emph role="eq">v</emph> in the <termref def="dt-value-space"/>,
<emph role="eq">v</emph> &lt;= <emph role="eq">U</emph>.
</termdef>
<termdef id="dt-upper-bound" term="upper bound"> The value
<emph role="eq">U</emph> is said to be an <term>upper bound</term> of the
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-bounded-below" term="bounded below">A
<termref def="dt-value-space"/> is <term>bounded below</term> if there
exists a unique value <emph role="eq">L</emph> in the space such that,
for all values <emph role="eq">v</emph> in the
<termref def="dt-value-space"/>, <emph role="eq">L</emph> &lt;=
<emph role="eq">v</emph>.
</termdef>
<termdef id="dt-lower-bound" term="lower bound">
The value <emph role="eq">L</emph> is then said to be a
<term>lower bound</term> of the <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
<termdef id="dt-bounded" term="bounded">A datatype is <term>bounded</term>
if its <termref def="dt-value-space"/> has both an
<termref def="dt-upper-bound"/> and a <termref def="dt-lower-bound"/>.
</termdef>
</p>
</div4>
<div4 id="cardinality">
<head>Cardinality</head>
<p>
<termdef id="dt-cardinality" term="cardinality">Every
<termref def="dt-value-space"/> has associated with it the concept of
<term>cardinality</term>.  Some <termref def="dt-value-space"/>s
are finite, some are countably infinite while still others are uncountably
infinite. A datatype is said to have the cardinality of its
<termref def="dt-value-space"/>.
</termdef>
</p>
<p>
It
is sometimes useful to categorize <termref def="dt-value-space"/>s
(and hence, datatypes) as to their cardinality.  There are two
significant cases:
</p>
<ulist>
<item>
<p>
<termref def="dt-value-space"/>s that are finite
</p>
</item>
<item>
<p>
<termref def="dt-value-space"/>s that are countably infinite
</p>
</item>
</ulist>
</div4>
<div4 id="numeric">
<head>Numeric</head>
<p>
<termdef id="dt-numeric" term="numeric">A datatype is said to be
<term>numeric</term> if its values are conceptually quantities (in some
mathematical number system).
</termdef>
</p>
<p>
<termdef id="dt-non-numeric" term="non-numeric">A datatype whose values
are not <termref def="dt-numeric"/> is said to be
<term>non-numeric</term>.
</termdef>
</p>
</div4>
</div3>
<div3 id="non-fundamental">
<head>Constraining or Non-fundamental facets</head>
<p>
<termdef id="dt-constraining-facet" term="constraining facet">A
<term>constraining facet</term> is an optional property that can be
applied to a datatype to constrain its <termref def="dt-value-space"/>.
</termdef>
</p>
<p>
Constraining the <termref def="dt-value-space"/> consequently constrains
the <termref def="dt-lexical-space"/>.  Adding
<termref def="dt-constraining-facet"/>s to a <termref def="dt-basetype"/>
is described in <specref ref="derivation-by-restriction"/>.
</p>
<p>
In this section we define all <termref def="dt-constraining-facet"/>s
that are available for use when defining <termref def="dt-derived"/>
datatypes.
</p>

<div4 id="length">
<head>length</head>
<p>
<termdef id="dt-length" term="length"><term>length</term> is the number
of <emph>units of length</emph>, where <emph>units of length</emph>
varies depending on the <termref def="dt-basetype"/>.  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 <bibref ref="Unicode"/>
code points.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>length</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>length</term> is measured in list items.
</p>
<!--
<ednote>
<edtext>
For subtypes of string, should length be measured in "Combining sequences",
as specified in section 3 of the "CharMod" WD?  If so, we will probably
need to change the order relation for string.  This note applies equally
to minLength and maxLength.
</edtext>
</ednote>
-->
</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
<termref def="dt-basetype"/>. 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 <bibref ref="Unicode"/>
code points.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>minLength</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>length</term> is measured in list items.
</p>
</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
<termref def="dt-basetype"/>.  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 <bibref ref="Unicode"/>
code points.
For <dtref ref="binary"/> and datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>,
<term>maxLength</term> is measured in octets (8 bits) of binary data.
For datatypes <termref def="dt-derived"/> by <termref def="dt-list"/>,
<term>length</term> is measured in list items.
</p>
</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 <termref def="dt-ordered"/>
property of the datatype involved remains that of the
<termref def="dt-basetype"/>.
<!--
No order or any other relationship is implied between the individual
items of the enumeration set.
-->
</p>
</div4>

<div4 id="maxInclusive">
<head>maxInclusive</head>
<p>
<termdef id="dt-maxInclusive" term="maxInclusive">
<term>maxInclusive</term> is the <termref def="dt-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>inclusive</emph> in the sense that the value is itself included
in the <termref def="dt-value-space"/>.  The value of
<term>maxInclusive</term>&nbsp;<termref def="dt-must"/> be of the same
type as the
<termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="maxExclusive">
<head>maxExclusive</head>
<p>
<termdef id="dt-maxExclusive" term="maxExclusive">
<term>maxExclusive</term> is the <termref def="dt-upper-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is <emph>exclusive</emph>
in the sense that the value is itself excluded from the
<termref def="dt-value-space"/>.  The value of <term>maxExclusive</term>
must be of the same type as the <termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="minInclusive">
<head>minInclusive</head>
<p>
<termdef id="dt-minInclusive" term="minInclusive">
<term>minInclusive</term> is the <termref def="dt-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>inclusive</emph> in the sense that the value is itself included
in the <termref def="dt-value-space"/>.  The value of
<term>minInclusive</term> must be of the same type as the
<termref def="dt-basetype"/>.
</termdef>
</p>
</div4>
<div4 id="minExclusive">
<head>minExclusive</head>
<p>
<termdef id="dt-minExclusive" term="minExclusive">
<term>minExclusive</term> is the <termref def="dt-lower-bound"/>
of the <termref def="dt-value-space"/> for a datatype with the
<termref def="dt-ordered"/> property.  The value is
<emph>exclusive</emph> in the sense that the value is itself excluded
from the <termref def="dt-value-space"/> for the datatype.
The value of <term>minExclusive</term>&nbsp;<termref def="dt-must"/>
be of the same type as the <termref def="dt-basetype"/>.
</termdef>
</p>
</div4>

<div4 id="precision">
<head>precision</head>
<p>
<termdef id="dt-precision" term="precision"><term>precision</term>
is the maximum number of decimal digits in values of datatypes
<termref def="dt-derived"/> from <dtref ref="decimal"/>.  The value of
<term>precision</term>&nbsp;<termref def="dt-must"/> be a
<dtref ref="positiveInteger"/>.
</termdef>
</p>
</div4>
<div4 id="scale">
<head>scale</head>
<p>
<termdef id="dt-scale" term="scale"><term>scale</term>
is the maximum number of decimal digits in the fractional part
of values of datatypes <termref def="dt-derived"/> from
<dtref ref="decimal"/>. The value of <term>scale</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="nonNegativeInteger"/> .
</termdef>
</p>
</div4>

<div4 id="encoding">
<head>encoding</head>
<p>
<termdef id="dt-encoding" term="encoding"><term>encoding</term> is the
encoded form of the <termref def="dt-lexical-space"/> of 
datatypes <termref def="dt-derived"/> from <dtref ref="binary"/>.
The value of <term>encoding</term>&nbsp;<termref def="dt-must"/> be one
of {hex, base64}.
</termdef>
</p>
<p>
If the value of <term>encoding</term> is <emph>hex</emph> then each
binary octet is encoded as a character tuple, consisting the two
hexadecimal digits ([0-9a-fA-F]) representing the octet code. For example,
"20" is the <emph>hex</emph> encoding for the US-ASCII space character.
</p>
<p>
If the value of <term>encoding</term> is <emph>base64</emph> then the
entire binary stream is encoding using the Base64
Content-Transfer-Encoding defined in Section 6.8 <bibref ref="RFC2045"/>.
</p>
</div4>
<div4 id="duration">
<head>duration</head>
<p>
<termdef id="dt-duration" term="duration"><term>duration</term> is
the duration of values for the datatype <dtref ref="recurringDuration"/>
and datatypes <termref def="dt-derived"/> from
<dtref ref="recurringDuration"/>. The value of <term>duration</term>
&nbsp;<termref def="dt-must"/> be a <dtref ref="timeDuration"/>.
</termdef>
</p>
</div4>
<div4 id="period">
<head>period</head>
<p>
<termdef id="dt-period" term="period"><term>period</term> is the frequency
of recurrence for values for the datatype <dtref ref="recurringDuration"/>
and datatypes <termref def="dt-derived"/> from
<dtref ref="recurringDuration"/>. The value of <term>period</term>
&nbsp;<termref def="dt-must"/> be <dtref ref="timeDuration"/>.
</termdef>
</p>
</div4>
</div3>
</div2>
<div2 id="datatype-dichotomies">
<head>Datatype dichotomies</head>
<p>
It is useful to categorize the datatypes defined in this specification
along various dimensions, forming a set of characterization dichotomies.
</p>
<div3 id="atomic-vs-list">
<head>Atomic vs. list vs. union datatypes</head>
<ednote>
<edtext>
I know, now this is a trichotomy and not a dichotomy...hopefully no one
will be picky enough to complain
</edtext>
</ednote>
<p>
The first distinction to be made is that between
<termref def="dt-atomic"/>, <termref def="dt-list"/> and <termref def='dt-union'/>
datatypes.
</p>
<ulist>
<item>
<p>
<termdef id="dt-atomic" term="atomic"><term>Atomic</term> datatypes
are those having values which are regarded by this specification as
being indivisible.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-list" term="list"><term>List</term>
datatypes are those having values each of which which consists of a
finite-length sequence of values of an <termref def="dt-atomic"/> datatype.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-union" term="union"><term>Union</term>
datatypes are those whose <termref def='dt-value-space'/>s and
<termref def='dt-lexical-space'/>s are the union of
the <termref def='dt-value-space'/>s and
<termref def='dt-lexical-space'/>s of two or more other datatypes.
</termdef>
</p>
</item>
</ulist>
<p>
For example, a single token which <termref def="dt-match"/>es
<xspecref href="&xmlspec;#NT-Nmtoken">Nmtoken</xspecref> from
<bibref ref="XML"/> could be the value of an <termref def="dt-atomic"/>
datatype (<dtref ref="NMTOKEN"/>); while a sequence of such tokens
could be the value of a <termref def="dt-list"/> datatype
(<dtref ref="NMTOKENS"/>).
</p>
<div4 id="atomic">
<head>Atomic datatypes</head>
<p>
<termref def="dt-atomic"/> datatypes may be either
<termref def="dt-primitive"/> or <termref def="dt-derived"/>.  The
<termref def="dt-value-space"/> of an <termref def="dt-atomic"/> datatype
is a set of "atomic" values, which for the purposes of this specification,
are not further decomposable.  The <termref def="dt-lexical-space"/> of
an <termref def="dt-atomic"/> datatype is a set of <emph>literals</emph>
whose internal structure is specific to the datatype in question.
</p>
</div4>
<div4 id="list-datatypes">
<head>List datatypes</head>
<!-- question: are lists ordered? answer should be NO...the sequence
within a single value is ordered, but the value space is a list type
is not ordered
-->
<p>
Several type systems (such as the one described in
<bibref ref="ISO11404"/>) treat <termref def="dt-list"/> datatypes as
special cases of the more general notions of aggregate or collection
datatypes.
</p>
<p>
<termref def="dt-list"/> datatypes are always <termref def="dt-derived"/>.
The <termref def="dt-value-space"/> of a <termref def="dt-list"/>
datatype is a set of finite-length sequences of <termref def="dt-atomic"/>
values. The <termref def="dt-lexical-space"/> of a
<termref def="dt-list"/> datatype is a set of literals whose internal
structure is a whitespace separated sequence of literals of the
<termref def="dt-atomic"/> datatype of the items in the
<termref def="dt-list"/>
(where whitespace <termref def="dt-match"/>es
<xspecref href="&xmlspec;#NT-S">S</xspecref> in <bibref ref="XML"/>).
</p>
<note role="example">
<eg><![CDATA[
<simpleType name='sizes'>
  <list itemType='decimal'/>
</simpleType>
]]></eg>
<eg><![CDATA[
<cerealSizes xsi:type='sizes'> 8 10.5 12 </cerealSizes>
]]></eg>
</note>
<p>
A <termref def="dt-list"/> datatype can be <termref def="dt-derived"/>
from an <termref def="dt-atomic"/> datatype whose
<termref def="dt-lexical-space"/> allows whitespace. In such a case,
regardless of the input, list items will be separated at whitespace
boundaries.
</p>

<note role="example">
<eg><![CDATA[
<simpleType name='listOfString'>
  <list itemType='string'/>
</simpleType>
]]></eg>
<eg>
&lt;someElement xsi:type='listOfString'>
this is not list item 1
this is not list item 2
this is not list item 3
&lt;/someElement>
</eg>
<p>
In the above example, the value of the <emph>someElement</emph> element
is not a <termref def="dt-list"/> of <termref def="dt-length"/> 3;
rather, it is a <termref def="dt-list"/> of <termref def="dt-length"/>
18.
</p>
</note>
<!--
     somehow need to get the <has-facets> concept for abstract lists
	 into builtin.xsd, so that the following can be auto-generated
  -->
<p>
When a datatype is <termref def="dt-derived"/> from a
<termref def="dt-list"/> datatype, the following
<termref def="dt-constraining-facet"/>s may be used:
</p>
<ulist>
<item><p><termref def="dt-length"/></p></item>
<item><p><termref def="dt-maxLength"/></p></item>
<item><p><termref def="dt-minLength"/></p></item>
<item><p><termref def="dt-enumeration"/></p></item>
</ulist>
<p>
For each of the above <termref def="dt-facet"/>s, the
<emph>unit of length</emph> is measured in number of list items.
</p>
</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 input types.
<termref def="dt-union"/> datatypes are always <termref def="dt-derived"/>.
Currently, there are no <termref def='dt-built-in'/> <termref def='dt-union'/>
datatypes.
</p>
<note role="example">
<p>
A prototypical example of a <termref def='dt-union'/> type is the
<xspecref href='&xsdl;#p-max_occurs'>maxOccurs attribute</xspecref> on the
<xspecref href='&xsdl;#element-element'>element element</xspecref>
in XML Schema itself: it is a union of nonNegativeInteger
and an enumeration with the single member, the string "unbounded", as shown below.
</p>
<eg><![CDATA[
  <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger" use="default" value="1"/>
    <attribute name="maxOccurs">
      <simpleType>
        <union>
          <simpleType>
            <restriction base='nonNegativeInteger'/>
          </simpleType>
          <simpleType>
            <restriction base='string'>
              <enumeration value='unbounded'/>
            </restriction>
          </simpleType>
        </union>
      </simpleType>
    </attribute>
  </attributeGroup>
]]></eg>
</note>
<p>
Any number (greater than 1) of <termref def='dt-atomic'/> or <termref def='dt-list'/>
<termref def='dt-datatype'/>s may participate in a <termref def='dt-union'/> type.  
The order in which the participating types are specified in the definition (that is,
the order of the &lt;simpleType> children of the &lt;union> element) is significant.
During validation, an element or attribute's value is validated against the
participating types 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>
<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 distinquish between <termref def="dt-primitive"/> and 
<termref def="dt-derived"/> datatypes.
</p>
<ulist>
<item>
<p>
<termdef id="dt-primitive" term="primitive"><term>Primitive</term>
datatypes are those that are not defined in terms of other datatypes;
they exist <emph>ab initio</emph>.
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-derived" term="derived"><term>Derived</term>
datatypes are those that are defined in terms of other datatypes.
</termdef>
</p>
</item>
</ulist>
<p>
For example, in this specification, <dtref ref="float"/> is a well-defined
mathematical
<!-- find example other than float -->
concept that cannot be defined in terms of other datatypes, while
a <dtref ref="date"/> is a special case of the more general datatype
<dtref ref="recurringDuration"/>.
</p>
<p>
The datatypes defined by this specification fall into both
the <termref def="dt-primitive"/> and <termref def="dt-derived"/>
categories.  It is felt that a judiciously chosen set of
<termref def="dt-primitive"/> datatypes will serve the widest
possible audience by providing a set of convenient datatypes that
can be used as is, as well as providing a rich enough base from
which the variety of datatypes needed by schema designers can be
<termref def="dt-derived"/>.
</p>
<p>
<termdef id="dt-basetype" term="base type">Every
<termref def="dt-derived"/> datatype is defined in terms of an
existing datatype, referred to as the <term>base type</term>.
<term>base type</term>s may be either <termref def="dt-primitive"/>
or <termref def="dt-derived"/>.</termdef>
</p>
<p>
In the example above, <dtref ref="date"/> is <termref def="dt-derived"/>
from the <termref def="dt-basetype"/> <dtref ref="recurringDuration"/>.
</p>
<note>
<p>
A datatype which is <termref def="dt-primitive"/> in this specification
need not be a "primitive" datatype in any programming language used to
implement this specification.  Likewise, a datatype which is
<termref def="dt-derived"/> in this specification need not be a
"derived" datatype in any programming language used to implement
this specification.
</p>
</note>
</div3>
<div3 id="built-in-vs-user-derived">
<head>Built-in vs. user-derived datatypes</head>
<ulist>
<item>
<p>
<termdef id="dt-built-in" term="built-in"><term>Built-in</term>
datatypes are those which are defined in this specification,
and may be either <termref def="dt-primitive"/> or
<termref def="dt-derived"/>;
</termdef>
</p>
</item>
<item>
<p>
<termdef id="dt-user-derived" term="user-derived">
<term>User-derived</term> datatypes are those <termref def="dt-derived"/>
datatypes that are defined by individual schema designers.
</termdef>
</p>
</item>
</ulist>
<p>
Conceptually there is no difference between the
<termref def="dt-built-in"/>&nbsp;<termref def="dt-derived"/> datatypes
included in this specification and the <termref def="dt-user-derived"/>
datatypes which will be created by individual schema designers.
The <termref def="dt-built-in"/>&nbsp;<termref def="dt-derived"/> datatypes
are those which are believed to be so common that if they were not
defined in this specification many schema designers would end up
"reinventing" them.  Furthermore, including these
<termref def="dt-derived"/> datatypes in this specification serves to
demonstrate the mechanics and utility of the datatype generation
facilities of this specification.
</p>
<note>
<p>
A datatype which is <termref def="dt-built-in"/> in this specification
need not be a "built-in" datatype in any programming language used
to implement this specification.  Likewise, a datatype which is
<termref def="dt-user-derived"/> in this specification need not
be a "user-derived" datatype in any programming language used to
implement this specification.
</p>
</note>
</div3>
</div2>
</div1>
<div1 id="built-in-datatypes">
<head>Built-in datatypes</head>
<div2 id="namespaces">
<head>Namespace considerations</head>
<p>
The <termref def="dt-built-in"/> datatypes defined by this specification
are designed to be used with the &schema-language; as well as other
XML specifications. To facilitate such usage the <termref def="dt-built-in"/>
datatypes in this specification have the namespace URI:
<!-- should the "namespace URI" be a link to the uriReference type?-->
</p>
<ulist>
<item><p>http://www.w3.org/1999/XMLSchema-datatypes</p></item>
</ulist>
<p>
This applies to both
<termref def="dt-built-in"/> <termref def="dt-primitive"/> and
<termref def="dt-built-in"/> <termref def="dt-derived"/> datatypes.
</p>
<p>
Each <termref def="dt-user-derived"/> datatype is also associated with a
unique namespace.  However, <termref def="dt-user-derived"/> datatypes
do not come from the namespace defined by this specification; rather,
they come from the namespace of the schema in which they are defined
(see <xspecref href="&xsdl;#declare-schema">XML Representation of
Schemas</xspecref> in <bibref ref="structural-schemas"/>).
</p>
<p>
As described in more detail in <specref ref="xr-defn"/>,
each <termref def="dt-user-derived"/> datatype <termref def="dt-must"/>
be defined in terms of another datatype in one of three ways: 1) by assigning
<termref def="dt-constraining-facet"/>s which serve to <emph>restrict</emph> the
<termref def="dt-value-space"/> of the <termref def="dt-user-derived"/>
datatype to a subset of the <termref def="dt-basetype"/>; 2) by creating
a <termref def="dt-list"/> datatype whose <termref def="dt-value-space"/>
consists of finite-length sequences of values of the
<termref def="dt-basetype"/>; 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'/> of two or more other datatypes.
</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 UCS
characters (<bibref ref="ISO10646"/> and <bibref ref="Unicode"/>).  A UCS
character (or just character, for short) is an atomic unit of
communication; it is not further specified except to note that every UCS
character has a corresponding UCS code point, which is an integer.
</termdef>
</p>
<note>
<p>
As noted in <specref ref='order'/>, the fact that this specification does
not specify an <termref def='dt-order-relation'/> for <termref def='dt-string'/>
does not preclude other applications from treating strings as being ordered.
</p>
</note>
<div4 id="string-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="string-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="boolean">
<head>boolean</head>
<p>
<termdef id="dt-boolean" term="boolean"><term>boolean</term> has the
<termref def="dt-value-space"/> required to support the mathematical
concept of binary-valued logic: {true, false}.</termdef>
</p>
<div4 id="boolean-lexical-representation">
<head>Lexical Representation</head>
<p>
An instance of a datatype that is defined as <termref def="dt-boolean"/>
can have the following legal lexical values {true, false}.
</p>
</div4>
<div4 id="boolean-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="float">
<head>float</head>
<p>
<termdef id="dt-float" term="float"><term>float</term> corresponds
to the IEEE single-precision 32-bit floating point type
<bibref ref="ieee754"/>.  The basic <termref def="dt-value-space"/> of
<term>float</term> consists of the values
<emph role="eq">m &times; 2^e</emph>, where <emph role="eq">m</emph>
is an integer whose absolute value is less than
<emph role="eq">2^24</emph>, and <emph role="eq">e</emph> is an integer
between -149 and 104, inclusive.  In addition to the basic
<termref def="dt-value-space"/> described above, the
<termref def="dt-value-space"/> of <term>float</term> also contains the
following <emph>special values</emph>: positive and negative zero,
positive negative infinity and not-a-number.
The <termref def="dt-order-relation"/> on <term>float</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
A literal in the <termref def="dt-lexical-space"/> representing a
decimal number <emph role="eq">d</emph> maps to the normalized value
in the <termref def="dt-value-space"/> of <term>float</term> that is
closest to <emph role="eq">d</emph>; if <emph role="eq">d</emph> is
exactly halfway between two such values then the even value is chosen.
This is the <emph>best approximation</emph> of <emph role="eq">d</emph>
<bibref ref="clinger1990"/> <bibref ref="gay1990"/>, which is more
accurate than the mapping required by <bibref ref="ieee754"/>.
</p>
<div4 id="float-lexical-representation">
<head>Lexical representation</head>
<p>
<term>float</term> values have a lexical representation
consisting of a mantissa followed, optionally, by the character
"E" or "e", followed by an exponent.  The exponent <termref def="dt-must"/>
be an <dtref ref="integer"/>. The mantissa must be a  <dtref ref="decimal"/> number. The representations
for exponent and mantissa must follow the lexical rules for
<dtref ref="integer"/> and <dtref ref="decimal"/>.  If the "E" or "e" and
the following exponent are omitted, an exponent value of 0 is assumed.
</p>
<p>
The <emph>special values</emph> positive and negative zero, positive
and negative infinity and not-a-number have <code>0</code>,
<code>-0</code>, <code>INF</code>, <code>-INF</code> and
<code>NaN</code>, respectively.
</p>
<p>
For example, <code>-1E4, 1267.43233E12, 12.78e-2, 12 and INF</code>
are all legal literals for <term>float</term>.
</p>
</div4>
<div4 id="float-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>float</term> is defined by
prohibiting certain options from the
<specref ref='float-lexical-representation'/>.  Specifically, the preceding optional "+" sign is prohibited from the 
mantissa.  The exponent must be indicated by "E" ande number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point.  Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.  
</p>
</div4>
<div4 id="float-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="double">
<head>double</head>
<p>
<termdef id="dt-double" term="double">The <term>double</term>
datatype corresponds to IEEE double-precision 64-bit floating point
type <bibref ref="ieee754"/>.  The basic <termref def="dt-value-space"/>
of <term>double</term> consists of the values
<emph role="eq">m &times; 2^e</emph>, where <emph role="eq">m</emph>
is an integer whose absolute value is less than
<emph role="eq">2^53</emph>, and <emph role="eq">e</emph> is an
integer between -1075 and 970, inclusive.  In addition to the basic
<termref def="dt-value-space"/> described above, the
<termref def="dt-value-space"/> of <term>double</term> also contains
the following <emph>special values</emph>: positive and negative zero,
positive negative infinity and not-a-number.
The <termref def="dt-order-relation"/> on <term>double</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
A literal in the <termref def="dt-lexical-space"/> representing a
decimal number <emph role="eq">d</emph> maps to the normalized value
in the <termref def="dt-value-space"/> of <term>double</term> that is
closest to <emph role="eq">d</emph>; if <emph role="eq">d</emph> is
exactly halfway between two such values then the even value is chosen.
This is the <emph>best approximation</emph> of <emph role="eq">d</emph>
(<bibref ref="clinger1990"/>, <bibref ref="gay1990"/>), which is more
accurate than the mapping required by <bibref ref="ieee754"/>.
</p>
<div4 id="double-lexical-representation">
<head>Lexical representation</head>
<p>
<term>double</term> values have a lexical representation
consisting of a mantissa followed, optionally, by the character "E" or
"e", followed by an exponent.  The exponent <termref def="dt-must"/> be
an integer.  The mantissa must be a decimal number. The representations
for exponent and mantissa must follow the lexical rules for
<dtref ref="integer"/> and <dtref ref="decimal"/>.  If the "E" or "e"
and the following exponent are omitted, an exponent value of 0 is assumed.
</p>
<p>
The <emph>special values</emph> positive and negative zero, positive
and negative infinity and not-a-number have <code>0</code>,
<code>-0</code>, <code>INF</code>, <code>-INF</code> and
<code>NaN</code>, respectively.
</p>
<p>
For example, <code>-1E4, 1267.43233E12, 12.78e-2, 12 and INF</code>
are all legal literals for <term>double</term>.
</p>
</div4>
<div4 id="double-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>double</term> is defined by
prohibiting certain options from the
<specref ref='double-lexical-representation'/>.  Specifically, the preceding optional "+" sign is prohibited from the 
mantissa.  The exponent must be indicated by "E" ande number representations must be normalized such that for non-zero numbers there is a single non-zero
digit to the left of the decimal point.  Leading and trailing zeroes are
disallowed in the mantissa and leading zeroes are disallowed in the exponent.  
</p>
</div4>
<div4 id="double-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="decimal">
<head>decimal</head>
<p>
<termdef id="dt-decimal" term="decimal"><term>decimal</term>
represents arbitrary precision decimal numbers.
The <termref def="dt-value-space"/> of <term>decimal</term>
is the set of the values <emph role='eq'>i &times; 10^-n</emph>,
where <emph role='eq'>i</emph> and <emph role='eq'>n</emph> are integers
such that <emph role='eq'>n >= 0</emph>.
The <termref def="dt-order-relation"/> on <term>decimal</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
<termdef id='dt-decimal-with-precision' term='decimal-with-precision'>
The <termref def='dt-value-space'/> of types derived from <term>decimal</term>
with a value for <termref def='dt-precision'/> of <emph role='eq'>p</emph>
is the set of values <emph role='eq'>i &times; 10^-n</emph>, where
<emph role='eq'>n</emph> and <emph role='eq'>i</emph> are integers such that
<emph role='eq'>p >= n >= 0</emph> and the number of significant decimal digits
in <emph role='eq'>i</emph> is less than or equal to <emph role='eq'>p</emph>.
</termdef>
</p>
<p>
<termdef id='dt-decimal-with-scale' term='decimal-with-scale'>
The <termref def='dt-value-space'/> of types derived from <term>decimal</term>
with a value for <termref def='dt-scale'/> of <emph role='eq'>s</emph>
is the set of values <emph role='eq'>i &times; 10^-n</emph>, where
<emph role='eq'>i</emph> and <emph role='eq'>n</emph> are integers such
that <emph role='eq'>0 &lt;= n &lt;= s</emph>.
</termdef>
</p>
<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 may impact interchange between
XML schemas and programming languages, databases, etc.
Our design discussions did not reveal convincing evidence of undue
burden because of arbitrary precision decimal numbers in this design,
but we welcome further input from implementors.
</edtext>
</ednote>
<div4 id="decimal-lexical-representation">
<head>Lexical representation</head>
<p>
<term>decimal</term> has a lexical representation
consisting of a finite-length sequence of decimal digits separated
by a period as a decimal indicator, in accordance with the scale and
precision facets, with an optional leading sign. If the sign is
omitted, "+" is assumed.  Leading and trailing zeroes are optional.
If the fractional part is zero, the period and following zero(es) can
be omitted.
For example: <code>-1.23, 12678967.543233, +100000.00</code>.
</p>
</div4>
<div4 id="decimal-canonical-representation">
<head>Canonical representation</head>
<p>
The canonical representation for <term>decimal</term> is defined by
prohibiting certain options from the
<specref ref='decimal-lexical-representation'/>.  Specifically, the preceding optional "+" sign is prohibited.  Leading zeroes are prohibited.  Trailing
zeroes to the right of the decimal point are also prohibited.  
</p>
</div4>
<div4 id="decimal-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="decimal-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>

<div3 id="timeDuration">
<head>timeDuration</head>
<p>
<termdef id="dt-timeDuration" term="timeDuration">
<term>timeDuration</term> represents a duration of time.
The <termref def="dt-value-space"/> of <term>timeDuration</term> is 
<!-- space of time durations as defined in &sect; 5.5.3.2 of
<bibref ref="ISO8601"/>.
The <termref def="dt-order-relation"/> on <term>timeDuration</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.  -->
a six-dimensional space where the coordinates
designate the year, month, day, hour, minute, and second components defined in
&sect; 5.5.3.2 of <bibref ref="ISO8601"/>,
respectively.  These components are ordered
in their significance by their order of appearance i.e. as year, month, day,
hour, minute, and second.
The order-relation on timeDuration is stated as follows: for instances
x and y of timeDuration, x-y is defined as component-wise subtraction.
x > y iff all the components of x-y are non-negative and at least one
component is positive.  x &lt; y iff all the components of x-y are
non-positive and at least one component is negative. x = y iff all
components of x-y are zero.
</termdef>
</p>
<div4 id="timeDuration-lexical-repr">
<head>Lexical representation</head>
<p>
<!-- A single lexical representation, conforming to a subset of the 
representations allowed by <bibref ref="ISO8601"/>, is allowed for  -->
A single lexical representation, similar to the 
representations allowed by <bibref ref="ISO8601"/>, is allowed for
<term>timeDuration</term>.  This lexical representation is the
<bibref ref="ISO8601"/> extended format P<emph>n</emph>Y<emph>n</emph>
M<emph>n</emph>DT<emph>n</emph>H <emph>n</emph>M<emph>n</emph>S, where
<emph>n</emph>Y represents the number of years, <emph>n</emph>M the
number of months, <emph>n</emph>D the number of days, 'T' is the
date/time separator, <emph>n</emph>H the number of hours,
<emph>n</emph>M the number of minutes and <emph>n</emph>S the
number of seconds.  The number of seconds can include decimal digits
to arbitrary precision.</p>
<p>
The values of the
Year, Month, Day, Hour and Minutes components are not restricted but 
allow an arbitrary integer.  Similarly, the value of the Seconds component
allows an arbitrary decimal, that is they do not follow the alternative 
format of &sect; 5.5.3.2.1 of <bibref ref="ISO8601"/>.</p>
<p>
An optional preceding minus sign ('-') is
allowed, to indicate a negative duration.  If the sign is omitted a
positive duration is indicated. See also <specref ref="isoformats"/>.
</p>
<p>
For example, to indicate a duration of 1 year, 2 months, 3 days, 10
hours, and 30 minutes, one would write: <code>P1Y2M3DT10H30M</code>.
One could also indicate a duration of minus 120 days as:
<code>-P120D</code>.
</p>
<p>
Reduced precision and truncated representations of this format are allowed
provided they conform to the following:
</p>
<ulist>
<item>
<p>
The lowest order items may be omitted.  If omitted their value is
assumed to be zero.
</p>
</item>
<item>
<p>
The lowest order item may have a decimal fraction.
</p>
</item>
<item>
<p>
If the number of years, months, days, hours, minutes, or seconds in any
expression equals zero, the number and its corresponding designator may
be omitted.  However, at least one number and its designator must be present.
</p>
</item>
<item>
<p>
The designator 'T' shall be absent if all of the time items are absent.
The designator 'P' must always be present.
</p>
</item>
</ulist>
<p>
For example, P1347Y, P1347M are P1Y2MT2H are all allowed;
P0Y1347M and P0Y1347M0D are allowed. P-1347M is not allowed although
-P1347M is allowed.  P1Y2MT is not allowed.
</p>

<!--
<p>
Both left and right truncated forms of the above representation are
allowed.  In the left truncated form, the truncation occurs after the
leading "P".
For example, <code>P1347Y</code> and <code>P1347M</code> are both
allowed; <code>P0Y1347M</code> is also allowed. <code>P0Y1347M0D</code>
is not allowed and <code>P-1347M</code> is not allowed although
<code>-P1347M</code> is allowed.
</p>
-->
<!-- this is unclear and needs to be rewritten -->
<!-- 
<p>
Time periods, i.e. durations of time with a specific start and end,
 can be represented by
supplying two items of information: a start instant and a duration
or a start instant and an end instant or an end instant and a duration.
</p>
-->
</div4>
<div4 id="timeDuration-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="recurringDuration">
<head>recurringDuration</head>
<p>
<termdef id="dt-recurringDuration" term="recurringDuration">
<term>recurringDuration</term> represents a
<dtref ref="timeDuration"/> that recurs with a specific
<dtref ref="timeDuration"/> starting from a specific origin.
The <termref def="dt-order-relation"/> on <term>recurringDuration</term>
is: <emph role="eq">x &lt; y iff y - x</emph> is positive.
</termdef>
</p>
<p>
Recurring duration has two constraining facets
<termref def="dt-duration"/> and <termref def="dt-period"/> whose values
 <termref def="dt-must"/> be specified when the datatype is defined.
These facets specify the
length of the duration and after what duration it recurs.  The lexical
format used to specify these facet values is the lexical format for
<dtref ref="timeDuration"/>. A value of 0 for the facet
<termref def="dt-period"/> means that the duration does not recur i.e.
there is but a single occurrence.  A value of 0 for the facet
<termref def="dt-duration"/> means that the duration is, in fact, a
single instant of time.
</p>
<p>
<term>recurringDuration</term> is a conceptual datatype which serves as a
basetype
from which the other date and time datatypes are generated.  It can also be
used as a basetype for user-derived datatypes.  A user-derived datatype
can be generated from <term>recurringDuration</term> by specifying the values
for
<termref def="dt-duration"/> and <termref def="dt-period"/>. The value that
appears in an instance document is
the value of the origin when the recurrence begins.
</p>
<constraintnote type="svc" id="duration-and-period-required">
<head>duration and period required for recurringDuration</head>
<p>
It is an <termref def="dt-error"/> for <term>recurringDuration</term>
to be used directly in a schema.  Only datatypes that are
<termref def="dt-derived"/> from <term>recurringDuration</term> by
specifying a value for <termref def="dt-duration"/> and
<termref def="dt-period"/> can be used in a schema.
</p>
</constraintnote>
<div4 id="recurringDuration-lexical-repr">
<head>Lexical representation</head>
<p>
A single lexical representation, which is a subset of the lexical
representations allowed by <bibref ref="ISO8601"/>, is allowed for
<term>recurringDuration</term>.  This lexical representation is the
<bibref ref="ISO8601"/> extended format CCYY-MM-DDThh:mm:ss.sss
where "CC" represents the century, "YY" the year, "MM" the month and
"DD" the day, preceded by an optional leading sign to indicate a
negative number. If the sign is omitted, "+" is assumed. The letter
"T" is the date/time separator and "hh", "mm", "ss.sss" represent hour,
minute and second respectively.  Additional digits can be used to
increase the precision of fractional seconds if desired. To accommodate
year values greater than 9999 additional digits can be added to the
left of this representation.  The year 0000 is prohibited.
</p>
<p>
This representation can be immediately followed by a "Z" to indicate
Coordinated Universal Time (UTC).  To indicate the time zone, i.e. the
difference between the local time and Coordinated Universal Time,
the difference immediately follows the time and consists of a sign,
+ or -, followed by hh:mm.  See also <specref ref="isoformats"/>.
</p>
<p>
The derived datatype <dtref ref="timeInstant"/> uses the same lexical
representation. Other derived datatypes <dtref ref="date"/>, 
<dtref ref="time"/>, <dtref ref="timePeriod"/> and
<dtref ref="recurringDate"/> use truncated versions of this lexical
representation. 
</p>
</div4>
<div4 id="recurringDuration-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>recurringDuration</term> is defined
by prohibiting certain options from the
<specref ref='recurringDuration-lexical-repr'/>.  Specifically, the preceding optional "+" sign is prohibited and the time zone must be Coordinated Universal
Time (UTC) and be indicated by a "Z".  
</p>
</div4>
<div4 id="recurringDuration-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="recurringDuration-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>

<div3 id="binary">
<head>binary</head>
<p>
<termdef id="dt-term" term="binary"><term>binary</term> represents
arbitrary binary data.  The <termref def="dt-value-space"/> of
<term>binary</term> is the set of finite-length sequences of binary
octets.
</termdef>
</p>
<constraintnote type="svc" id="encoding-required">
<head>encoding required for binary</head>
<p>
It is an <termref def="dt-error"/> for <term>binary</term> to be used
directly in a schema.  Only datatypes that are <termref def="dt-derived"/>
from <term>binary</term> by minimally specifying a value for
<termref def="dt-encoding"/> can be used in a schema.
</p>
</constraintnote>
<div4 id="binary-facets">
<head>Constraining facets</head>
<facets/>

<ednote>
<edtext>
What does the pattern facet on binary really mean?  Since pattern
operates on the lexical space, one would have to give a regex for the
base64 or hex that would result for a specific binary sequence that one
wanted to constrain...this is not too far fetched for hex, but almost
impossible for base64, isn't it?
</edtext>
</ednote>
</div4>
</div3>
<div3 id="uriReference">
<head>uriReference</head>
<p>
<termdef id="dt-uriReference" term="uriReference">
<term>uriReference</term> represents a Uniform Resource Identifier (URI)
Reference as defined in Section 4 of <bibref ref="RFC2396"/>.
A <term>uriReference</term> may be absolute or relative, and may have
an optional fragment identifier.
</termdef>
</p>

<p>
<termdef id="dt-absolute-uriReference" term="absolute uriReference">
An <term>absolute uriReference</term> refers to a resource
in a manner which is independent of the context in which the
<termref def="dt-uriReference"/> occurs.
</termdef>
</p>
<p>
<termdef id="dt-relative-uriReference" term="relative uriReference">
A <term>relative uriReference</term> refers to a resource
by describing the difference within a hierarchy of resources between the
context in which the <term>relative uriReference</term> occurs and 
the <termref def="dt-absolute-uriReference"/> of the resource.
</termdef>
</p>
<div4 id="uriReference-lexical-representation">
<head>Lexical representation</head>
<p>
The <termref def="dt-lexical-space"/> of <term>uriReference</term> is
the set of strings that <termref def="dt-match"/> the URI-reference
production in Section 4 of <bibref ref="RFC2396"/>.
</p>

</div4>
<div4 id="uriReference-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="ID">
<head>ID</head>
<p>
<termdef id="dt-ID" term="ID"><term>ID</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">ID attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>ID</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been used in an XML document.  The
<termref def="dt-lexical-space"/> of <term>ID</term> is the set of all
strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>ID</term> is scoped to
a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>)
<term>ID</term> should be used only on attributes.
</p>
<constraintnote type="svc" id="id">
<head>ID Unique</head>
<p>
An <term>ID</term>&nbsp;<termref def="dt-must"/> not appear more than once
in an XML document as a value of this type; i.e., <term>ID</term> values
must uniquely identify the elements which bear them.
</p>
</constraintnote>
<div4 id="ID-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="IDREF">
<head>IDREF</head>
<p>
<termdef id="dt-IDREF" term="IDREF"><term>IDREF</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">IDREF attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>IDREF</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been used in an XML document as the
value of an element or attribute of type <dtref ref="ID"/>.  The
<termref def="dt-lexical-space"/> of <term>IDREF</term> is the set of 
strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>

<note>
<p>
The <termref def="dt-value-space"/> of <term>IDREF</term> is scoped to
a specific instance document.
<!--
and is a restriction of the instance document scoped
<termref def='dt-value-space'/> of <dtref ref='ID'/>.
-->
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) this datatype
should be used only on attributes.
</p>
<constraintnote type="svc" id="idref">
<head>IDREF</head>
<p>
An <term>IDREF</term>&nbsp;<termref def="dt-must"/>&nbsp;<termref def="dt-match"/>
the value of an <dtref ref="ID"/> in the XML document in which it occurs.
</p>
</constraintnote>
<div4 id="IDREF-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="IDREF-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="ENTITY">
<head>ENTITY</head>
<p>
<termdef id="dt-ENTITY" term="ENTITY"><term>ENTITY</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">ENTITY attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>ENTITY</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/> and have been declared as an
<xspecref href="&xmlspec;#dt-unparsed">unparsed entity</xspecref> in
a <xspecref href="&xmlspec;#dt-doctype">document type definition</xspecref>.
The <termref def="dt-lexical-space"/> of <term>ENTITY</term> is the set
of all strings that <termref def="dt-match"/> the
<xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>
<note>
<p>
<!-- isn't this really scoped to a schema? -->
The <termref def="dt-value-space"/> of <term>ENTITY</term> is scoped
to a specific instance document.
</p>
</note>
<constraintnote type="svc" id="entity">
<head>ENTITY declared</head>
<p>
<term>ENTITY</term> values <termref def="dt-must"/>&nbsp;<termref def="dt-match"/>
an unparsed entity name that is declared in the schema.
</p>
</constraintnote>
<p>
For compatibility (see <specref ref="terminology"/>) <term>ENTITY</term>
should be used only on attributes.
</p>
<div4 id="ENTITY-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="ENTITY-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="NOTATION">
<head>NOTATION</head>
<p>
<termdef id="dt-NOTATION" term="NOTATION"><term>NOTATION</term>
represents the <xnt href="&xmlspec;#NT-NotationType">NOTATION attribute
type</xnt> from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>NOTATION</term> is the set of all
<xspecref href="&xsdl;#declare-notation">notations declared</xspecref>
in a schema.  The <termref def="dt-lexical-space"/> of
<term>NOTATION</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName"> NCName</xnt> production in
<bibref ref="XMLNS"/>.
</termdef>
</p>
<note>
<p>
<!-- isn't this really scoped to a schema? -->
The <termref def="dt-value-space"/> of <term>NOTATION</term> is scoped
to a specific instance document.
</p>
</note>
<constraintnote type="svc" id="notation">
<head>NOTATION declared</head>
<p>
<term>NOTATION</term> values <termref def="dt-must"/>&nbsp;<termref def="dt-match"/>
a notation name that is declared in the schema.
</p>
</constraintnote>
<p>
For compatibility (see <specref ref="terminology"/>) <term>NOTATION</term>
should be used only on attributes.
</p>
<div4 id="NOTATION-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="QName">
<head>QName</head>
<p>
<termdef id="dt-QName" term="QName"><term>QName</term> represents
<xspecref href="&xmlnsspec;#dt-qname">XML qualified names</xspecref>.
The <termref def="dt-value-space"/> of <term>QName</term> is the set of
tuples {<xspecref href="&xmlnsspec;#dt-NSName">namespace name</xspecref>,
<xspecref href="&xmlnsspec;#dt-localname">local part</xspecref>},
where <xspecref href="&xmlnsspec;#dt-NSName">namespace name</xspecref>
is a <dtref ref="uriReference"/>
and <xspecref href="&xmlnsspec;#dt-localname">local part</xspecref> is
an <dtref ref="NCName"/>.
The <termref def="dt-lexical-space"/> of <term>QName</term> is the set
of strings that <termref def="dt-match"/> the <xspecref href="&xmlnsspec;#NT-QName">
QName</xspecref> production of <bibref ref="XMLNS"/>.
</termdef>
</p>
<div4 id='QName-facets'>
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
</div2>
<div2 id="built-in-derived">
<head>Derived datatypes</head>
<p>
This section gives conceptual definitions for all
<termref def="dt-built-in"/> <termref def="dt-derived"/> datatypes
defined by this specification. The XML Representation used to define
<termref def="dt-derived"/> datatypes (whether
<termref def="dt-built-in"/> or <termref def="dt-user-derived"/>) is
given in section <specref ref="xr-defn"/> and the complete
definitions of the <termref def="dt-built-in"/>
<termref def="dt-derived"/> datatypes are provided in Appendix
<specref ref="schema"/>.
</p>
<div3 id="language">
<head>language</head>
<p>
<termdef id="dt-language" term="language"><term>language</term>
represents natural language identifiers as defined by
<bibref ref="RFC1766"/>.  The <termref def="dt-value-space"/> of
<term>language</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-LanguageID">LanguageID</xnt> production in
<bibref ref="XML"/>.  The <termref def="dt-lexical-space"/> of
<term>language</term> is the set of all strings that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-LanguageID">LanguageID</xnt> production in
<bibref ref="XML"/>.  The <termref def="dt-basetype"/> of
<term>language</term> is <dtref ref="string"/>.
</termdef>
</p>
<div4 id="language-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="IDREFS">
<head>IDREFS</head>
<p>
<termdef id="dt-IDREFS" term="IDREFS"><term>IDREFS</term> represents the
<xnt href="&xmlspec;#NT-TokenizedType">IDREFS attribute type</xnt> from
<bibref ref="XML"/>.  The <termref def="dt-value-space"/> of
<term>IDREFS</term> is the set of finite-length sequences of
<termref def="dt-IDREF"/>s that have been used in an XML document.
The <termref def="dt-lexical-space"/> of <term>IDREFS</term> is the
set of whitespace separated tokens, each of which is in the
<termref def="dt-lexical-space"/> of <dtref ref="IDREF"/>.  The
<termref def="dt-basetype"/> of <term>IDREFS</term> is
<dtref ref="IDREF"/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>IDREFS</term> is scoped
to a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) <term>IDREFS</term>
should be used only on attributes.
</p>

<div4 id="IDREFS-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<!--
<constraintnote type='svc' id='idref'>
<head>IDREF</head>
<p>
Each <term>IDREF</term>&nbsp;<termref def='dt-must'/>&nbsp;<termref def='dt-match'/>
the value of an <dtref ref='ID'/> in the XML document.
</p>
</constraintnote>
-->
</div3>
<div3 id="ENTITIES">
<head>ENTITIES</head>
<p>
<termdef id="dt-ENTITIES" term="ENTITIES"><term>ENTITIES</term>
represents the <xnt href="&xmlspec;#NT-TokenizedType">ENTITIES attribute
type</xnt> from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>ENTITIES</term> is the set of finite-length sequences of
<termref def="dt-ENTITY"/>s that have been declared as
<xspecref href="&xmlspec;#dt-unparsed">unparsed entities</xspecref>
in a <xspecref href="&xmlspec;#dt-doctype">document type definition</xspecref>.
The <termref def="dt-lexical-space"/> of <term>ENTITIES</term> is the
set of whitespace separated tokens, each of which is in the
<termref def="dt-lexical-space"/> of <dtref ref="NMTOKEN"/>.
The <termref def="dt-basetype"/> of <term>ENTITIES</term> is
<dtref ref="ENTITY"/>.
</termdef>
</p>
<note>
<p>
The <termref def="dt-value-space"/> of <term>ENTITIES</term> is scoped
to a specific instance document.
</p>
</note>
<p>
For compatibility (see <specref ref="terminology"/>) <term>ENTITIES</term>
should be used only on attributes.
</p>
<div4 id="ENTITIES-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="NMTOKEN">
<head>NMTOKEN</head>
<p>
<termdef id="dt-NMTOKEN" term="NMTOKEN"><term>NMTOKEN</term> represents
the <xnt href="&xmlspec;#NT-TokenizedType">NMTOKEN attribute type</xnt>
from <bibref ref="XML"/>. The <termref def="dt-value-space"/> of
<term>NMTOKEN</term> is the set of tokens that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Nmtoken">Nmtoken</xnt> production in
<bibref ref="XML"/>. The <termref def="dt-lexical-space"/> of
<term>NMTOKEN</term> is the set of strings that <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Nmtoken">Nmtoken</xnt> production in
<bibref ref="XML"/>.  The <termref def="dt-basetype"/> of
<term>NMTOKEN</term> is <dtref ref="string"/>.
</termdef>
</p>
<p>
For compatibility (see <specref ref="terminology"/>) <term>NMTOKEN</term>
should be used only on attributes.
</p>
<div4 id="NMTOKEN-facets">
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id="NMTOKEN-derived-types">
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="NMTOKENS">
<head>NMTOKENS</head>
<p>
<termdef id="dt-NMTOKENS" term="NMTOKENS"><term>NMTOKENS</term>
represents the <xnt href="&xmlspec;#NT-TokenizedType">NMTOKENS attribute
type</xnt> from <bibref ref="XML"/>. The <termref def="dt-value-space"/>
of <term>NMTOKENS</term> is the set of finite-length sequences of
<termref def="dt-NMTOKEN"/>s.  The <termref def="dt-lexical-space"/>
of <term>NMTOKENS</term> is the set of whitespace separated tokens,
each of which is in the <termref def="dt-lexical-space"/> of
<dtref ref="NMTOKEN"/>.  The <termref def="dt-basetype"/> of
<term>NMTOKENS</term> is <dtref ref="NMTOKEN"/>.
</termdef>
</p>
<p>
For compatibility (see <specref ref="terminology"/>)
<term>NMTOKENS</term> should be used only on attributes.
</p>
<div4 id="NMTOKENS-facets">
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="Name">
<head>Name</head>
<p>
<termdef id="dt-Name" term="Name"><term>Name</term>
represents <xspecref href="&xmlspec;#dt-name">XML Names</xspecref>.
The <termref def="dt-value-space"/> of <term>Name</term> is
the set of all strings which <termref def="dt-match"/> the
<xspecref href="&xmlspec;#NT-Name"> Name</xspecref> production of
<bibref ref="XML"/>.  The <termref def="dt-lexical-space"/> of
<term>Name</term> is the set of all strings which <termref def="dt-match"/>
the <xnt href="&xmlspec;#NT-Name">Name</xnt> production of
<bibref ref="XML"/>. The <termref def="dt-basetype"/> of <term>Name</term>
is <dtref ref="string"/>.</termdef>
</p>
<div4 id='Name-facets'>
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id='Name-derived-types'>
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="NCName">
<head>NCName</head>
<p>
<termdef id="dt-NCName" term="NCName"><term>NCName</term> represents XML
"non-colonized" Names.  The <termref def="dt-value-space"/> of
<term>NCName</term> is the set of all strings which <termref def="dt-match"/>
the <xspecref href="&xmlnsspec;#NT-NCName"> NCName</xspecref> production of
<bibref ref="XMLNS"/>.  The <termref def="dt-lexical-space"/> of
<term>NCName</term> is the set of all strings which <termref def="dt-match"/>
the <xnt href="&xmlnsspec;#NT-NCName">NCName</xnt> production of
<bibref ref="XMLNS"/>.  The <termref def="dt-basetype"/> of
<term>NCName</term> is <dtref ref="Name"/>.
</termdef>
</p>
<div4 id='NCName-facets'>
<head>Constraining facets</head>
<facets/>
</div4>
</div3>
<div3 id="integer">
<head>integer</head>
<p>
<termdef id="dt-integer" term="integer"><term>integer</term> is
<termref def="dt-derived"/> from <dtref ref="decimal"/> by fixing the
value of <termref def="dt-scale"/> to be 0. This results in the standard
mathematical concept of the integer numbers. The
<termref def="dt-value-space"/> of <term>integer</term> is the infinite
set {...,-2,-1,0,1,2,...}.  The <termref def="dt-basetype"/> of
<term>integer</term> is <dtref ref="decimal"/>.
</termdef>
</p>
<div4 id="integer-lexical-representation">
<head>Lexical representation</head>
<p>
<term>integer</term> has a lexical representation consisting of a finite-length sequence
of decimal digits with an optional leading sign.  If the sign is omitted,
"+" is assumed.  For example: -1, 0, 12678967543233, +100000.
</p>
</div4>
<div4 id="integer-canonical-repr">
<head>Canonical representation</head>
<p>
The canonical representation for <term>integer</term> is defined
by prohibiting certain options from the
<specref ref='integer-lexical-representation'/>.  Specifically, the preceding optional "+" sign is prohibited and leading zeroes are prohibited.  
</p>
</div4>
<div4 id='integer-facets'>
<head>Constraining facets</head>
<facets/>
</div4>
<div4 id='integer-derived-types'>
<head>Derived datatypes</head>
<subtypes/>
</div4>
</div3>
<div3 id="nonPositiveInteger">
<head>nonPositiveInteger</head>
<p>
<termdef id="dt-nonPositiveInteger" term="nonPositiveInteger">
<term>nonPositiveInteger</term> is <termref def="dt-derived"/> from
<dtref ref="integer"/> by setting the value of
<termref def="dt-maxInclusive"/> to be 0.  This results in the
standard mathematical concept of the non-positive integers.
The <termref def="dt-valu