<?xml version='1.0'?>
<!-- Id: structures.xml,v 1.9 2004/10/07 22:05:03 cmsmcq Exp  -->
<?xml-stylesheet type='text/xsl' href='xmlschema_nodiffs.xsl'?>
<!DOCTYPE spec PUBLIC "-//W3C//DTD Specification V2.2//EN" "schemaSpecs.dtd" [
   <!ENTITY suffix "">
   <!ENTITY meForTxt "structures">
   <!ENTITY SchemaWG "<loc
href='http://www.w3.org/XML/Activity#schema-wg'>W3C XML Schema Working
Group</loc>">
   <!ENTITY XSP1 "<emph>XML Schema: Structures</emph>">
   <!ENTITY XSP2 "<bibref ref='ref-xsp2'/>">
   <!ENTITY xsp2Xref "../REC-xmlschema-2-20041028/datatypes.xml">
   <!ENTITY schemaExample "example.xsd.dmp">

   <!ENTITY eacute "&#233;" > <!-- small e, acute accent -->
   <!ENTITY rsquo "&#8217;"> <!-- right single quote -->
   <!ENTITY constraint "identity-constraint">
   <!ENTITY Constraint "Identity-constraint"> <!-- for replacement later? -->
   <!ENTITY raw-PSVI 'post-schema-validation infoset'>
   <!ENTITY PSVI '<termref def="key-psvi">&raw-PSVI;</termref>'>
   <!ATTLIST spec xml:lang CDATA #IMPLIED>
   <!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
                     role (psvi) #IMPLIED>
   <!ELEMENT xpropref (#PCDATA|phrase)*>
   <!ATTLIST xpropref href CDATA #IMPLIED
                      role (anon|psviAnon) #IMPLIED>
   <!ELEMENT compdef (proplist)>
   <!ATTLIST compdef name CDATA #REQUIRED
                     ref IDREF #REQUIRED>

   <!ELEMENT compref EMPTY>
   <!ATTLIST compref ref IDREF #REQUIRED>

   <!ELEMENT proplist (propdef*)>
   <!ATTLIST proplist role (psvi) #IMPLIED
                      item CDATA #IMPLIED>
   <!ELEMENT reprdef (reprelt|reprcomp|p)*>
   <!ELEMENT reprelt EMPTY>
   <!ATTLIST reprelt eltname NMTOKENS #REQUIRED
                     type NMTOKEN #IMPLIED
                     local NMTOKEN #IMPLIED
                     diff CDATA #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
                    inside NMTOKEN #IMPLIED>
   <!ELEMENT clauseref EMPTY>
   <!ATTLIST clauseref ref IDREF #REQUIRED>
   <!ELEMENT stale ANY>
   <!ELEMENT restrictCases (restrict+)>
   <!ELEMENT restrict (any|all|choice|elt|seq)*>
   <!ATTLIST restrict case CDATA #REQUIRED>
   <!ELEMENT any (#PCDATA)>
   <!ATTLIST any ref NMTOKEN #IMPLIED>
   <!ELEMENT all (#PCDATA)>
   <!ATTLIST all ref NMTOKEN #IMPLIED>
   <!ELEMENT elt (#PCDATA)>
   <!ATTLIST elt ref NMTOKEN #IMPLIED>
   <!ELEMENT choice (#PCDATA)>
   <!ATTLIST choice ref NMTOKEN #IMPLIED>
   <!ELEMENT seq (#PCDATA)>
   <!ATTLIST seq ref NMTOKEN #IMPLIED>
   <!ELEMENT schemaComp (head,pvlist+)>
   <!ATTLIST schemaComp id ID #REQUIRED
                        diff CDATA #IMPLIED>
   <!ELEMENT pvlist (pvpair+)>
   <!ATTLIST pvlist diff (chg|add|del|off)           #IMPLIED>
   <!ELEMENT pvpair ANY>
   <!ATTLIST pvpair ref IDREF #REQUIRED>
   <!ATTLIST graphic map IDREF #IMPLIED>
   <!ELEMENT imagemap EMPTY>
   <!ATTLIST imagemap source CDATA #REQUIRED
                      id     ID    #REQUIRED>
   <!ELEMENT local (#PCDATA)>
   <!ELEMENT iiName (#PCDATA)>
   <!ENTITY % local.emph.class '|local|iiName'>
   <!ELEMENT pt (#PCDATA)>
   <!ATTLIST pt diff (chg|add|del|off)           #IMPLIED>
   <!ENTITY % local.term.class "|pt"><!-- ht: for pre-terminal -->
   <!ENTITY % local.tech.class "|pt"><!-- ht: for pre-terminal -->
   <!-- the above used in content model of LHS -->
   <!ENTITY % local.termdef.class "|propdef">
   <!ENTITY % local.ref.class "|propref|xpropref|eltref|clauseref">
   <!ENTITY % local.illus.class "|compdef|reprdef|proplist|schemaComp|restrictCases|imagemap">
   <!ENTITY i-attribute "<xpropref href='http://www.w3.org/TR/xml-infoset/#infoitem.element'>attribute</xpropref>">
   <!ENTITY i-children "<xpropref href='http://www.w3.org/TR/xml-infoset/#infoitem.element'>children</xpropref>">
   <!ENTITY i-attributes "<xpropref href='http://www.w3.org/TR/xml-infoset/#infoitem.element'>attributes</xpropref>">
   <!ENTITY i-value "<termref def='key-nv'>normalized value</termref>">
   <!ENTITY r-value "<termref def='key-iv'>initial value</termref>">
   <!ENTITY v-value "<termref def='key-vv'>actual value</termref>">
   <!ENTITY i-ccode "<xpropref
href='http://www.w3.org/TR/xml-infoset/#infoitem.character'>character code</xpropref>">
   <!ATTLIST spec schemaProper CDATA #FIXED "./XMLSchema.xsd"
           schemaDump CDATA #FIXED "./XMLSchema.xsd.dmp"
           schemaExample CDATA #FIXED "./&schemaExample;"
           datatypeDoc CDATA #FIXED "&xsp2Xref;"
           docStatus CDATA #FIXED "final">
 ]>
<spec xml:lang="en" w3c-doctype="rec" status="final">
  <header>
    <title>XML Schema Part 1: Structures</title>
    <version diff="add">Second Edition</version>
    <w3c-designation>rec-20041028</w3c-designation>
    <w3c-doctype>W3C Recommendation</w3c-doctype>
    <pubdate>
      <day>28</day>
      <month>October</month>
      <year>2004</year><!-- Id: structures.xml,v 1.9 2004/10/07 22:05:03 cmsmcq Exp  -->
    </pubdate>
    <publoc> <loc href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/</loc> </publoc>
   <altlocs diff="chg"><loc href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.xml">XML</loc>
    <loc href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures-with-errata.html">XHTML with visible change markup</loc>
    <loc href="http://www.w3.org/2001/XMLSchema.xsd">Independent copy of the schema for schema
documents</loc>    <loc href="http://www.w3.org/2001/XMLSchema.dtd">Independent copy of the DTD for schema documents</loc></altlocs>
   <latestloc><loc href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1/</loc>
 </latestloc>
   <prevlocs>
    <loc href="http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/">http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/</loc>
   </prevlocs>
    <authlist>
      <author>
        <name>Henry S. Thompson</name>
        <affiliation>University of Edinburgh</affiliation>
        <email href="mailto:ht@cogsci.ed.ac.uk">ht@cogsci.ed.ac.uk</email>
      </author>
     <author>
      <name>David Beech</name>
      <affiliation>Oracle Corporation</affiliation>
      <email href="mailto:David.Beech@oracle.com">David.Beech@oracle.com</email>
     </author>
     <author>
      <name>Murray Maloney</name>
      <affiliation>for Commerce One</affiliation>
      <email href="mailto:murray@muzmo.com">murray@muzmo.com</email>
     </author>
     <author>
      <name>Noah Mendelsohn</name>
      <affiliation>Lotus Development Corporation</affiliation>
      <email href="mailto:Noah_Mendelsohn@lotus.com">Noah_Mendelsohn@lotus.com</email>
     </author>
    </authlist>
<errataloc href="http://www.w3.org/2004/03/xmlschema-errata"/>
<preverrataloc href="http://www.w3.org/2001/05/xmlschema-errata"/>
<translationloc href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema"/>
<status>
<p><emph>This section describes the status of this document at the
time of its publication. Other documents may supersede this document.
<phrase diff="chg">A list of current W3C publications and the latest
revision of this technical report can be found in the <loc
href="http://www.w3.org/TR/">W3C technical reports index</loc> at
http://www.w3.org/TR/.</phrase></emph></p>

<!--* Don't mark the next paragraph deleted: that would suggest
    * it was in the First Edition and has now been deleted. 
    * Instead, just delete it.  Or rather, comment it out
    * (in case we change our minds). 
    *-->
<!--* <p diff="del">This is a <xspecref
href="http://www.w3.org/2004/02/Process-20040205/tr.html#ProposedEditedRec">W3C
Proposed Edited Recommendation</xspecref>, intended to become the
first part of the Second Edition of XML Schema.  It is here made
available for review by W3C members and other interested parties. Note
that a Candidate Recommendation draft has not been deemed necessary by
the Working Group, as there are no substantial implementation issues
arising as a result of this edition, which aims only to incorporate
the published corrigenda to the first edition.</p> *-->

<!--* in next paragraph, the phrase 'or cited as a normative reference
    * from another document' should appear in parts 1 and 2 but not
    * in part 0. *-->
<p><phrase diff="add">This is a <xspecref
href="http://www.w3.org/2004/02/Process-20040205/tr.html#RecsW3C">W3C
Recommendation</xspecref>, which forms part of the Second Edition of XML
Schema.</phrase> This document has been reviewed by W3C Members and
other interested parties and has been endorsed by the Director as a
W3C Recommendation. It is a stable document and may be used as
reference material or cited as a normative reference 
from another document. 
W3C's role in making the Recommendation is to draw attention
to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web. 
</p>

<!--* next paragraph deleted vis-a-vis PER but not vis-a-vis 1E *-->
<!--* <p diff="del">Please send comments on this Proposed Edited
Recommendation to <loc
href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc>,
including <code>2E PER</code> in the subject line, no later than 16
April 2004.</p> *-->

<!--* next paragraph deleted vis-a-vis PER but not vis-a-vis 1E *-->
<!--* <p diff="del">Publication as a Proposed Edited Recommendation does not
imply endorsement by the W3C Membership. This is a draft document and
may be updated, replaced or obsoleted by other documents at any
time. It is inappropriate to cite this document as other than work in
progress.</p> *-->

<p>
This document has been produced by the <loc
href="http://www.w3.org/XML/Schema">W3C XML Schema Working Group</loc>
as part of the W3C <loc href="http://www.w3.org/XML/Activity">XML
Activity</loc>. The goals of the XML Schema language are discussed in
the <loc href="http://www.w3.org/TR/NOTE-xml-schema-req">XML Schema
Requirements</loc> document. The authors of this document are the
members of the XML Schema Working Group.  Different parts of this
specification have different editors.
</p>

<p diff="del">This version of this document incorporates some editorial changes
from earlier versions.</p>
 
<!--* next paragraph deleted vis-a-vis PER but not vis-a-vis 1E *-->
<!--* <p diff="del">Documentation of intellectual property possibly relevant to this
recommendation may be found at the Working Group's <loc
role="disclosure"
href="http://www.w3.org/2002/11/xml-schema-IPR-statements.html">public
IPR disclosure page</loc>.</p> *-->

<p diff="add">
This document was produced under the <loc
href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24
January 2002 Current Patent Practice (CPP)</loc> as amended by the <loc
href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy
Transition Procedure</loc>. The Working Group maintains a <loc
role="disclosure"
href="http://www.w3.org/2002/11/xml-schema-IPR-statements.html">public
list of patent disclosures</loc> relevant to this document;
that page also includes instructions for disclosing a patent. 
An individual who
has actual knowledge of a patent which the individual believes
contains Essential Claim(s) with respect to this specification should
disclose the information in accordance with <loc
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 
6 of the W3C Patent Policy</loc>.
</p>

<p diff="del">Please report errors in this document to <loc
href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> 
(<loc
href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</loc>). 
The list of known errors in this specification is available at <loc
href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</loc>. 
</p>

<p>The English version of this specification is the only normative
version. Information about translations of this document is available
at <loc
href="http://www.w3.org/2001/05/xmlschema-translations">http://www.w3.org/2001/05/xmlschema-translations</loc>.</p>

<p diff="del">A list of current W3C Recommendations and other
technical documents can be found at
<loc href="http://www.w3.org/TR">http://www.w3.org/TR</loc>.</p>

<p diff="add">This second edition is <emph>not</emph> a new version,
it merely incorporates the changes dictated by the corrections to
errors found in the <loc
href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/">first
edition</loc> as agreed by the XML Schema Working Group, as a
convenience to readers.  A separate list of all such corrections is
available at <loc
href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</loc>. 
</p>

<p diff="add">The errata list for this second edition is available at <loc
href="http://www.w3.org/2004/03/xmlschema-errata">http://www.w3.org/2004/03/xmlschema-errata</loc>.</p>

<p diff="add">
Please report errors in this document to <loc
href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> 
(<loc
href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</loc>).
</p>

<note diff="add">
<p>David Beech has retired since the publication of the first edition,
and can be reached at <loc href="mailto:davidbeech@earthlink.net">davidbeech@earthlink.net</loc>.</p>
<p>Murray Maloney is no longer affiliated with Commerce One; his contact
details are unchanged.</p>
<p>Noah Mendelsohn's affiliation has changed since the publication of the
first edition.  He is now at IBM, and can be contacted at <loc href="mailto:noah_mendelsohn@us.ibm.com">noah_mendelsohn@us.ibm.com</loc></p>
</note>

     
</status>
<!--* 
<status>
    <p><emph>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <loc href="http://www.w3.org/TR/">W3C technical reports index</loc> at http://www.w3.org/TR/.</emph></p>
 <p>This is a <xspecref href="http://www.w3.org/2004/02/Process-20040205/tr.html#ProposedEditedRec">W3C Proposed Edited Recommendation</xspecref>, intended to become the second part of the Second Edition of XML Schema.  It is here made available for review by W3C members and other interested parties. Note that a Candidate Recommendation draft has not been deemed necessary by the Working Group, as there are no substantial implementation issues arising as a result of this edition, which aims only to incorporate the published corrigenda to the first edition.</p>
 <p>Please send comments on this Proposed Edited Recommendation to <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc>, including <code>2E PER</code> in the subject line, no later than 16 April 2004.</p>
<p>Publication as a Proposed Edited Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>

    <p>
    This document has been produced by the <loc href="http://www.w3.org/XML/Schema">W3C XML Schema Working Group</loc> as
    part of the W3C <loc href="http://www.w3.org/XML/Activity">XML Activity</loc>. The
    goals of the XML Schema language are discussed in the <loc href="http://www.w3.org/TR/NOTE-xml-schema-req">XML Schema
    Requirements</loc> document. The authors of this document are the
    members of the XML Schema Working Group.  Different parts of this
    specification have different editors.
    </p>
 
 <p>Documentation of intellectual property possibly relevant to this recommendation may be found at the Working Group's <loc role="disclosure" href="http://www.w3.org/2002/11/xml-schema-IPR-statements.html">public IPR disclosure page</loc>.</p>

    <p diff="del">Please report errors in this document to <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> (<loc href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</loc>). The list of known errors in this specification is
    available at <loc href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</loc>. </p>

    <p>The English version of this specification is the only normative
    version. Information about translations of this document is available
    at <loc href="http://www.w3.org/2001/05/xmlschema-translations">http://www.w3.org/2001/05/xmlschema-translations</loc>.</p>

     <p diff="add">This second edition is <emph>not</emph> a new version, it
merely incorporates the changes dictated by the corrections to errors found in
the first edition as agreed by the XML Schema Working Group, as a convenience
to readers.  A separate list of all such corrections is available at <loc href="http://www.w3.org/2001/05/xmlschema-errata">http://www.w3.org/2001/05/xmlschema-errata</loc>.  The errata list for this second edition is available at <loc href="http://www.w3.org/2004/03/xmlschema-errata">http://www.w3.org/2004/03/xmlschema-errata</loc>.</p>
     <p diff="add">
Please report errors in this document to <loc href="mailto:www-xml-schema-comments@w3.org">www-xml-schema-comments@w3.org</loc> (<loc href="http://lists.w3.org/Archives/Public/www-xml-schema-comments/">archive</loc>).</p>
     <note diff="add">
      <p>David Beech has retired since the publication of the first edition,
and can be reached at <loc href="mailto:davidbeech@earthlink.net">davidbeech@earthlink.net</loc>.</p>
      <p>Murray Maloney is no longer affiliated with Commerce One; his contact
details are unchanged.</p>
      <p>Noah Mendelsohn's affiliation has changed since the publication of the
first edition.  He is now at IBM, and can be contacted at <loc href="mailto:noah_mendelsohn@us.ibm.com">noah_mendelsohn@us.ibm.com</loc></p>
     </note>

</status>
*-->
     <abstract>
          <p><emph>XML Schema: Structures</emph> specifies the XML Schema definition language,
          which offers facilities for describing the structure and constraining the contents
            of XML 1.0 documents, including those which exploit the XML
Namespace facility. The schema language, which is itself represented in XML
            1.0 and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML 1.0 document type
            definitions (DTDs).  This specification depends on <emph>XML Schema Part 2:
            Datatypes</emph>.</p>
    </abstract>
    <pubstmt>
      <p>Boston, Mountain View, Toronto, et al.: World-Wide Web Consortium, XML
        Working Group, 1999.</p>
    </pubstmt>
    <sourcedesc>
      <p>Created in electronic form using XML.</p>
    </sourcedesc>
    <langusage>
      <language id="EN">English</language>
      <language id="ebnf">Extended Backus-Naur Form (formal grammar)
      </language>
      <language>Extensible Markup Language (XML)</language> </langusage>
    <revisiondesc>
      <slist>
       <sitem>1999-09-05: HST: Abandoned this method of logging
changes:  see CVS change log at the end of the document</sitem>
       <sitem>1999-09-02: HST: Marked non-status-quo sections as such.</sitem>
       <sitem>1999-09-01: HST: incorporated Section 2 examples from 'Simple',
modified to include some attributes.  Massaged explanatory text.</sitem>
       <sitem>1999-08-22: HST: incorporated 'Simple' section 3 changes and started to smooth over
the joints.</sitem>
       <sitem>1999-07-18: DB: updated definition of "Schema" following WG and IG email discussion.
         Changed "Schemata" to "Schemas" except where directly quoted from Requirements doc.
         Clarified in 2.5 that elements and attributes have separate symbol spaces (public comment).
         Fixed assorted typos.
       </sitem>
       <sitem>1999-06-23: HST: pushed &amp; down to lowest level, fixed incoherent
validity definition in 6.2.3.7 to agree with the note which follows.  Wrapped validation
text from 3.4 in appropriately named div4's.</sitem>
       <sitem>1999-06-20: HST: stripped out validation</sitem>
        <sitem>1999-05-03: MCM: Updated schema and DTD. Package and test.
        </sitem>
        <sitem>1999-05-03 Integration of final editors' concerns for WD1.
          Includes HT work on constraints.</sitem>
        <sitem>1999-05-02 NRM General cleanup of first few chapters. Remove
          chapter 4 redundancy (tuple discussion) with new validity rules. </sitem>
        <sitem>1999-05-02: HST: still chipping away at validity. Redefined the
          XSDL/XDTL entities.</sitem>
        <sitem>19940502: MCM: mostly annotating the schema. Also moved info
          about abstract grammar into Chapter 2. Chapter 3 now starts right into defining
          a schema. Edited text entities to make them easier to manage.</sitem>
        <sitem>19940501: HST: various</sitem>
        <sitem>1999-04-30: NRM : revisions to chapter 4</sitem>
        <sitem>1999-04-28: DB (pp HST) : promised edits for improved
          consistency and definition of 'schema'; suggested modifications to
          3.4.9/10 and 3.5 </sitem>
        <sitem>1999-04-39: HST : integrated DB's edits, completely rewrote
          6.1, replaced virtually all &lt;B&gt; with correct &lt;...ref&gt; </sitem>
        <sitem>1999-04-28: DB (pp HST) : promised edits for improved
          consistency and definition of 'schema'; suggested modifications to
          3.4.9/10 and 3.5 </sitem>
        <sitem>1999-04-23: HST : Got all productions sorted using
          'nt' and correct IDs.</sitem>
        <sitem>1999-04-21 : HST : Added lots of IDs and constraint heads:
          Validates w/o error</sitem>
        <sitem>1999-04-21 : HST : Converted with no content changes to speak of
          from MCM-XSDL-19990416.html. This version has only ID/IDREF related errors
          left.</sitem>
      </slist>
    </revisiondesc>
  </header>
  <body>
    <div1 id="intro">
      <head>Introduction</head>
      <p>This document sets out the structural part (&XSP1;) of the XML Schema definition language.</p>
      <p>Chapter 2 presents a <specref ref="concepts"/> for XML Schemas, including
        an introduction to the nature of XML Schemas and an introduction
to the XML Schema abstract data model, along with
        other terminology used throughout this document. </p>
      <p>Chapter 3, <specref ref="components"/>, specifies the precise
semantics of each component of the abstract model, the representation of each 
component in XML, with reference to a DTD and XML Schema
for an XML Schema document type, along with a detailed mapping between the elements and
attribute vocabulary of this representation and the components and properties
of the abstract model.</p>
      <p>Chapter 4 presents <specref ref="composition"/>, including the
connection between documents and schemas, the import, inclusion and redefinition of declarations and definitions and
        the foundations of schema-validity assessment.</p>
      <p>Chapter 5 discusses <specref ref="conformance"/>, including the
overall approach to schema-validity assessment of documents, and responsibilities of schema-aware
        processors. </p>
      <p>The normative appendices include a <specref ref="normative-schemaSchema"/> for the XML representation of schemas and
        <specref ref="normative-references"/>.</p>
     <p>The non-normative appendices include the <specref ref="nonnormative-schemaDTD"/> and a <specref ref="normative-glossary"/>.</p>
     <p>This document is primarily intended as a language definition reference.
As such, although it contains a few examples, it is <emph>not</emph> primarily designed
to serve as a motivating introduction to the design and its features, or as a
tutorial for new users.
Rather it presents a careful and fully explicit definition of that design, suitable
for guiding implementations.  For those in search of a step-by-step
introduction to the design, the non-normative <bibref ref="bib-expo"/> is a much better
starting point than this document.</p>
    <div2 id="intro-purpose">
      <head>Purpose</head>
      <p>The purpose of &XSP1; is to define the nature of XML schemas
and their component parts,
provide an inventory of XML markup
        constructs with which to represent schemas, and define the
application of schemas to XML documents. </p>
      <p>The purpose of an &XSP1; schema is to define and describe a class of
        XML documents by using schema components to constrain and document the meaning,
        usage and relationships of their constituent parts: datatypes, elements and
        their content and attributes and their values. Schemas may also provide for the specification of additional
        document information, such as normalization and defaulting of attribute
and element values. Schemas have
facilities for self-documentation. Thus, &XSP1; can be used to define, describe and catalogue XML
        vocabularies for classes of XML documents. </p>

     <p>Any application that consumes well-formed XML can use the &XSP1;
        formalism to express syntactic, structural and value constraints applicable to
        its document instances. The &XSP1; formalism allows a useful level of
        constraint checking to be described and implemented for a wide spectrum of XML
        applications.  However, the language defined by this specification does not attempt to provide
        <emph>all</emph> the facilities that might be needed by <emph>any</emph>
        application. Some applications may require constraint capabilities not
        expressible in this language, and so may need to perform their own additional
        validations.</p>
    </div2>
    <div2 id="intro-relatedWork">
      <head>Dependencies on Other Specifications</head>
      <p>The definition of &XSP1; depends on the following specifications:
      <bibref ref="ref-xmlinfo"/>,
      <bibref ref="ref-xml-namespaces"/>,
      <bibref ref="bib-xpath"/>, and
      <bibref ref="ref-xsp2"/>.</p>
     <p>See <specref ref="infoset"/> for a tabulation of the information items
and properties specified in <bibref ref="ref-xmlinfo"/> which this
specification requires as a precondition to schema-aware processing.</p>
    </div2>
    <div2 id="intro-terminology">
        <head>Documentation Conventions and Terminology</head>
        <p>The section introduces the highlighting and typography as used in
          this document to present technical material.</p>
        <p>Special terms are defined at their point of
introduction in the text.  For example <termdef id="key-sampledef" term="term" role="local">a <term>term</term> is
          something used with a special meaning</termdef>.  The definition is
labeled as such and the term it defines is displayed in boldface.  The end of the definition is not specially marked
in the displayed or printed text.  Uses of defined terms are links to
their definitions, set off with middle dots, for instance <termref def="key-sampledef">term</termref>.</p>
          <p>Non-normative examples are set off in boxes and accompanied by a brief
explanation:</p>
        <note role="example">
          <eg xml:space="preserve">&lt;schema targetNamespace="http://www.example.com/XMLSchema/1.0/mySchema"&gt;</eg>
          <p>And an explanation of the example.</p>
      </note>
      <p>The definition of each kind of schema component consists of a list of
      its properties and their contents, followed by descriptions of the
      semantics of the properties:</p>
        <compdef name="Example" ref="intro-terminology">
   <proplist>
  <propdef id="xmpl-prop" name="example property">
Definition of the property.
   </propdef>
  </proplist>
 </compdef>
     <p>References to properties of schema components are links to
the relevant definition as exemplified above, set off with curly braces, for instance <propref ref="xmpl-prop"/>.</p>
      <p>The correspondence between an element information item which is part
of the XML representation of a schema and one or more schema components is presented in a tableau
which illustrates the element information item(s) involved.
This is followed by a tabulation of the correspondence between properties of the component
and properties of the information item.  Where context may determine which of
several different components may arise, several tabulations, one per context,
are given.  The property correspondences are normative,
as are the illustrations of the XML representation element information items.
</p>
     <p>In the XML representation, bold-face
attribute names (e.g. <term>count</term> below) indicate a required
attribute information item, and the rest are
optional.  Where an attribute information item has an enumerated type
definition, the values are shown separated by vertical bars, as for
<code>size</code> below; if there is a default value, it is shown
following a colon.  Where an attribute information item has a built-in simple
type definition defined in <bibref ref="ref-xsp2"/>, a hyperlink to its
definition therein is given.</p>
     <p>The allowed content of the information item is
shown as a grammar fragment, using the Kleene operators <code>?</code>,
<code>*</code> and <code>+</code>.  Each element name therein is a hyperlink to
its own illustration.</p>
     <note>
      <p>The illustrations are derived automatically from the <specref ref="normative-schemaSchema"/>.  In the case of apparent conflict, the <specref ref="normative-schemaSchema"/> takes precedence, as it, together with the <termref def="gloss-src">Schema Representation Constraints</termref>, provide the normative statement of
the form of XML representations.</p>
     </note>
<reprdef>
 <reprelt eltname="example"/>
 <reprcomp abstract="Example" ref="intro-terminology">
<propmap name="xmpl-prop">Description of what the property corresponds to, e.g. the value of the <code>size</code>
&i-attribute;
</propmap>
</reprcomp>
 </reprdef>
     <p>References to elements in the text are links to
the relevant illustration as exemplified above, set off with angle brackets, for instance <eltref ref="example"/>.</p>
     <p>References to properties of information items as defined in <bibref ref="ref-xmlinfo"/> are notated as links to the relevant section thereof, set off with square brackets, for example &i-children;.</p>
     <p>Properties which this specification defines for information items are
introduced as follows:</p>
     <proplist item="example" role="psvi">
      <propdef id="ex-foo" name="new property">The value the property gets.</propdef>
     </proplist>
<p>References to properties of information items defined in this specification
are notated as links to their introduction as exemplified above, set off with square brackets, for example <propref role="psvi" ref="ex-foo"/>.</p>
      <p>The following highlighting is used for non-normative commentary in
        this document:</p>


      <note>
        <p>General comments directed to all readers. </p>
      </note>
     <p>Following <bibref ref="ref-xml"/>, within normative prose in this specification, the words
<emph>may</emph> and <emph>must</emph> are defined as follows:</p>
     <glist>
      <gitem>
       <label>may</label>
       <def>
        <p>Conforming documents and XML Schema-aware processors are permitted to but need not behave as described.</p>
       </def>
      </gitem>
      <gitem>
       <label>must</label>
       <def>
        <p>Conforming documents and XML Schema-aware processors are required to behave as described; otherwise they are in error.</p>
       </def>
      </gitem>
     </glist>
     <p>Note however that this specification provides a definition of error and of conformant processors'
responsibilities with respect to errors (see <specref ref="conformance"/>) which is considerably
more complex than that of <bibref ref="ref-xml"/>.</p>
    </div2>
  </div1>
  <div1 id="concepts">
    <head>Conceptual Framework</head>
<p>This chapter gives an overview of &XSP1; at the level of its abstract data model.  <specref ref="components"/> provides details on this model, including
a normative representation in XML for the components of the model.
Readers interested primarily in learning to write schema documents may wish to
first read <bibref ref="bib-expo"/> for a tutorial introduction, and only then consult the sub-sections of 
<specref ref="components"/> named <emph>XML Representation of ...</emph> for
the details.</p>
   <div2>
    <head>Overview of XML Schema</head>
    <p>An XML Schema
consists of components such as type definitions
and element declarations.  These can be used to assess the validity of
well-formed element and attribute information items (as defined
in <bibref ref="ref-xmlinfo"/>), and furthermore
may specify augmentations to those items and their descendants.  This augmentation makes explicit information which may have
been implicit in the original document, such as normalized and/or default values for
attributes and elements and
the types of element and attribute information items.  <phrase diff="add"><termdef term="post-schema-validation infoset" id="key-psvi">We refer to the augmented infoset which results from conformant processing as defined in this specification as the <term>post-schema-validation infoset</term>, or PSVI</termdef></phrase>.</p>
    <p>Schema-validity assessment has two aspects:
<olist><item id="c-lsv"><p><phrase diff="del">determining</phrase><phrase diff="add">Determining</phrase> local schema-validity, that is
whether an element or attribute information item satisfies the
constraints embodied in the relevant
components of an XML Schema;</p></item>
<item><p>Synthesizing an overall validation outcome for the item,
combining local schema-validity with the results of schema-validity
assessments of its descendants, if any, and
adding appropriate augmentations to the infoset to record this outcome.</p></item></olist></p>
    <p>Throughout this specification, <termdef id="key-vn" term="valid">the
word <term>valid</term> and its derivatives are used to refer to
<clauseref ref="c-lsv"/> above, the determination of local
schema-validity</termdef>.</p>
<p>Throughout this specification, <termdef id="key-va" term="assessment"> the word <term>assessment</term> is used to refer
to the overall process of
local validation, schema-validity assessment and infoset augmentation</termdef>.</p>
   </div2>
   <div2 id="concepts-data-model">
    <head>XML Schema Abstract Data Model</head>
    <p>This specification builds on <bibref ref="ref-xml"/> and
<bibref ref="ref-xml-namespaces"/>.  The concepts and definitions used
herein regarding XML are framed at the abstract level of <xtermref href="http://www.w3.org/TR/xml-infoset/#infoitem">information
items</xtermref> as defined in <bibref ref="ref-xmlinfo"/>.  By
definition, this use of the infoset provides <emph>a priori</emph> guarantees of <xtermref href="http://www.w3.org/TR/REC-xml#sec-well-formed">well-formedness</xtermref>
(as defined in <bibref ref="ref-xml"/>) and <xtermref href="http://www.w3.org/TR/REC-xml-names/#Conformance">namespace
conformance</xtermref> (as defined in <bibref ref="ref-xml-namespaces"/>) for
all candidates for <termref def="key-va">assessment</termref> and for all <termref def="key-schemaDoc">schema documents</termref>.</p>
    <p>Just as <bibref ref="ref-xml"/> and
<bibref ref="ref-xml-namespaces"/> can be described in terms of
information items, XML Schemas can be described in terms of an
abstract data model.  In defining XML Schemas in terms of an abstract
data model, this specification rigorously specifies the information which
must be available to a conforming XML Schema processor.  The abstract
model for schemas is conceptual only, and does not mandate any
particular implementation or representation of this information.  To
facilitate interoperation and sharing of schema information, a
normative XML interchange format for schemas is provided.</p>
<p><termdef id="key-component" term="schema component"> <term>Schema component</term> is the generic term for the building blocks that comprise the abstract data model of the schema.
</termdef>
<termdef id="key-schema" term="XML Schema">
An <term>XML Schema</term> is a
set of <termref def="key-component">schema components</termref></termdef>.  There are 13 kinds of
component in all, falling into three groups.  The primary components, which may
(type definitions) or must (element and attribute declarations) have names
are as follows:</p>
<ulist>
<item><p>Simple type definitions
</p></item>
<item><p>Complex type definitions</p></item>
<item><p>Attribute declarations</p></item>
 <item><p>Element declarations</p></item>
</ulist><p>The secondary components, which must have names, are as follows:</p>
<ulist>
<item><p>Attribute group definitions</p></item>
<item><p>&Constraint; definitions</p></item>
<item><p>Model group definitions</p></item>
<item><p>Notation declarations</p></item>
</ulist>
<p>Finally, the <quote>helper</quote> components provide small parts of
other components; they are not independent of their context:</p>
<ulist>
<item><p>Annotations</p></item>
<item><p>Model groups</p></item>
<item><p>Particles</p></item>
<item><p>Wildcards</p></item>
 <item><p>Attribute Uses</p></item>
</ulist>
     <p>During <termref def="key-vn">validation</termref>, <termdef id="key-declaration" term="declaration"><term>declaration</term> components are associated by
(qualified) name to information items being <termref def="key-vn">validated</termref></termdef>.</p>
<p>On the other hand, <termdef id="key-definition" term="definition"><term>definition</term> components define
internal schema components that can be used in other schema components</termdef>.
</p>
<p>
<termdef id="key-compName" term="component name">Declarations and
definitions may have and be identified by <term>name</term>s, which are NCNames as defined by <bibref ref="ref-xml-namespaces"/></termdef>.</p>

    <p>  <termdef id="key-targetNS" term="target namespace">Several kinds
of component have a <term>target namespace</term>, which is either
<termref def="key-null">absent</termref> or a namespace name, also as
defined by <bibref ref="ref-xml-namespaces"/></termdef>.  The <termref def="key-targetNS">target
namespace</termref> serves to identify the namespace within which the
association between the component and its name exists.  In the case of
declarations, this in turn determines the namespace name of, for example, the element
information items it may <termref def="key-vn">validate</termref>.</p>
    <note>
     <p>At the abstract level, there is
no requirement that the components of a schema share a
<termref def="key-targetNS">target namespace</termref>.  Any schema for use in
<termref def="key-va">assessment</termref> of documents containing names from more than one namespace
will of necessity include components with different <termref def="key-targetNS">target namespaces</termref>.  This contrasts with
the situation at the level of the XML representation of components, in which each schema document contributes
definitions and declarations to a single target namespace.</p>
    </note>
    <p><termref def="key-vn">Validation</termref>, defined in detail in <specref ref="components"/>, is a
relation between information items and schema components.  For example, an
attribute information item may <termref def="key-vn">validate</termref> with respect to an attribute
declaration, a list of element information items may <termref def="key-vn">validate</termref> with
respect to a content model, and so on.  The following sections briefly
introduce the kinds of components in the
schema abstract data model, other major features of the abstract
model, and how they contribute to <termref def="key-vn">validation</termref>.</p>
     <div3 id="Type_Definition_Summary">
<head>Type Definition Components</head>
<p>The abstract model provides two kinds of type definition component: simple
and complex.</p>
<p><termdef id="key-typeDefn" term="type definition">This specification uses
the phrase <term>type definition</term> in cases where no distinction
need be made between simple and complex types</termdef>.</p>
<p>Type definitions form a hierarchy with a single root.  The subsections below first describe characteristics of that
hierarchy, then provide an introduction to simple and complex type definitions themselves.</p>
<div4 id="Type_Derivation">
<head>Type Definition Hierarchy</head>
<p>
<termdef id="key-typeDefinitionHierarchy" term="Type Definition
Hierarchy">Except for a distinguished <termref def="key-urType">ur-type definition</termref>, every <termref def="key-typeDefn">type definition</termref> is, by construction, either a
<termref def="key-typeRestriction">restriction</termref> or an <termref def="key-typeExtension">extension</termref> of some other type definition.  The graph of these relationships forms a tree known as the <term>Type Definition Hierarchy</term></termdef>.
</p>
<p><termdef id="key-typeRestriction" term="restriction">A type
definition whose
declarations or facets are in a one-to-one relation with those of another
specified type
definition, with each in turn restricting the possibilities of the one it
corresponds to, is said to be a <term>restriction</term></termdef>.
The specific restrictions might include narrowed ranges or reduced
alternatives.
Members of a type, A, whose definition is a <termref def="key-typeRestriction">restriction</termref> of the definition of another type, B, are always members of type B as well.</p>
<p><termdef id="key-typeExtension" term="extension">A complex type definition
which allows element or attribute content in addition to that allowed by
another specified type
definition is said to be an <term>extension</term></termdef>.</p>
<p><termdef id="key-urType" term="ur-type definition">A distinguished <phrase diff="add">complex
type definition, the</phrase> <term>ur-type
definition</term>, whose
name is <pt>anyType</pt><phrase diff="add"> in the XML Schema namespace</phrase>, is present in each <termref def="key-schema">XML Schema</termref>, serving as the root of the type
definition hierarchy for that schema</termdef>.  <phrase diff="del">The ur-type definition, whose
name is <local>anyType</local>, has
the unique characteristic that it can function as a complex or a
simple type definition, according to context.
Specifically, <termref def="key-typeRestriction">restrictions</termref> of the ur-type definition can
themselves be either simple or complex type definitions.</phrase>
</p>
<p><termdef id="key-baseTypeDefinition" term="base type definition">A type definition used as the
basis for an <termref def="key-typeExtension">extension</termref> or
<termref def="key-typeRestriction">restriction</termref> is known as
the <term>base type definition</term> of that definition</termdef>.
</p>
</div4><div4 id="Simple_Type_Definition">

     <head>Simple Type Definition</head>
     <p>A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the &i-value; of an attribute
information item or of an element information item with no element children.
Informally, it applies to the values of attributes and the text-only content of elements.
</p>
     <p>Each simple type definition, whether built-in (that is, defined in &XSP2;) or
user-defined, is a <termref def="key-typeRestriction">restriction</termref> of some particular
simple <termref def="key-baseTypeDefinition">base type
definition</termref>.  For the built-in primitive type definitions, this is  <phrase diff="del">the simple
version</phrase><termdef id="key-simpleUrType" term="simple ur-type definition"><phrase diff="add">the <term>simple
ur-type definition</term>, a special restriction</phrase> of the
<termref def="key-urType">ur-type
definition</termref>, whose name is <local>anySimpleType</local> <phrase diff="add">in the XML Schema namespace</phrase></termdef>. <phrase diff="del">This
 is in turn understood to be a restriction of the <termref def="key-urType">ur-type
definition</termref>.</phrase>  <phrase diff="add">The <termref def="key-simpleUrType">simple ur-type definition</termref> is considered to have an unconstrained lexical space, and a value space consisting of the union of the value spaces of all the built-in primitive datatypes and the set of all lists of all members of the value spaces of all the built-in primitive datatypes.</phrase></p>
        <p diff="add">The mapping from lexical space to value space is
unspecified for items whose type definition is the
<termref def="key-simpleUrType">simple ur-type definition</termref>. 
Accordingly this specification does not constrain processors' behaviour in
areas where this mapping is implicated, for example checking such items against
enumerations, constructing default attributes or elements whose declared type
definition is the
<termref def="key-simpleUrType">simple ur-type definition</termref>, checking
identity constraints involving such items.</p>
        <note diff="add">
         <p>The Working Group expects to return to this area in a future
version of this specification.</p>
        </note>
        <p>Simple types may
also be defined whose members are lists of items
themselves constrained by some other simple type definition, or whose
membership is the union of the memberships of some other simple type
definitions.  <phrase diff="add">Such</phrase> list and union simple type definitions are also <phrase diff="del">understood as
</phrase>restrictions of the <termref def="key-simpleUrType">simple ur-type
definition</termref>.</p>
     <p>For detailed information on simple type definitions, see <specref ref="Simple_Type_Definitions"/> and &XSP2;.  The latter also defines an extensive inventory of
pre-defined simple types.</p>
</div4>
<div4 id="Complex_Type_Definition">
<head>Complex Type Definition</head>
<p>A complex type definition is a set of attribute declarations and a content type, applicable to the &i-attributes; and
&i-children; of an element information item respectively.  The content type may
require the &i-children; to contain neither element nor character information
items (that is, to be empty), to be a string which belongs to a particular simple
type or to contain a sequence of element information items which conforms to a particular model group, with or without character information items as well.</p>
     <p>Each complex type definition <phrase diff="add">other than the
<termref def="key-urType">ur-type definition</termref> </phrase>is either
      <ulist>
       <item>
        <p>a restriction of a complex <termref def="key-baseTypeDefinition">base
type definition</termref></p>
       </item>
      </ulist>
      or
      <ulist><item>
<p>an <termref def="key-typeExtension">extension</termref> of a simple or complex <termref def="key-baseTypeDefinition">base
type definition</termref><phrase diff="add">.</phrase></p>
</item>
</ulist>
      <phrase diff="del">or</phrase>
      <ulist diff="del">
       <item>
<p>a <termref def="key-typeRestriction">restriction</termref> of the
<termref def="key-urType">ur-type definition</termref>.</p>
</item>
      </ulist>
</p>
<p> A
complex type which extends another does so by having additional content model
particles at the end of the other definition's content model,
or by having additional attribute declarations, or both.
  <note>
   <p>This specification allows only appending, and not other kinds of
extensions. This decision
simplifies application processing required to cast instances from derived to
base type.  Future versions may allow more kinds of extension, requiring more
complex transformations to effect casting.</p>
  </note></p>
     <p>
For detailed information on complex type definitions, see <specref ref="Complex_Type_Definitions"/>.</p>
</div4>
</div3>

     <div3 id="Declarations_Summary">
<head>Declaration Components</head>
<p>There are three kinds of declaration component: element, attribute, and
notation.  Each is described in a section below. Also included is a discussion
of element substitution groups, which is a feature provided in conjunction with
element declarations.</p>
<div4 id="Element_Declaration">
<head>Element Declaration</head>
<p>An element declaration is an association of a name with a type definition, either simple or
complex, an (optional) default value and a (possibly empty) set of &constraint;
definitions.  The association is either global or scoped to a containing complex type definition.  A
top-level element declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type definition
fills in the ellipses:</p>
<eg>&lt;!ELEMENT A . . .&gt;
&lt;!ATTLIST A . . .&gt;
</eg>
<p>Element declarations contribute to
<termref def="key-vn">validation</termref> as part of model group <termref def="key-vn">validation</termref>, when their defaults and type components are checked against an element
information item with a matching name and namespace, and by triggering
&constraint; definition <termref def="key-vn">validation</termref>.</p>
     <p>
For detailed information on element declarations, see <specref ref="cElement_Declarations"/>.</p>
</div4>
<div4 id="Element_Equivalence_Class">
<head>Element Substitution Group</head>
<p>In XML 1.0, the name and content of an element must correspond exactly to the element type referenced in the corresponding content model.</p>
<p><termdef id="key-equivalenceClass" term="element substitution group">Through
the new mechanism of <term>element substitution groups</term>, XML Schemas provides a more powerful model supporting substitution of one named element for another</termdef>.
Any top-level element declaration can serve as the defining <phrase diff="del">element</phrase><phrase diff="add">member</phrase>, or
head, for an element substitution group.  Other top-level element declarations,
regardless of target namespace, can be designated as members of the
substitution group headed by this element.  In a suitably enabled content
model, a reference to the head <termref def="key-vn">validates</termref> not just the head itself, but elements
corresponding to any <phrase diff="add">other</phrase> member of the substitution group as well.
</p>
<p>All such members must have type definitions which are either the same as the
head's type definition or
restrictions or extensions of it.
Therefore, although the names of elements can vary widely as new
namespaces and members of the substitution group are defined, the
content of member elements is strictly limited according to the type
definition of the substitution group head.</p>
<p>Note that element substitution groups are not represented as separate components.  They are
specified in the property values for element declarations (see <specref ref="cElement_Declarations"/>).</p>
</div4>
<div4 id="Attribute_Declaration">
<head>Attribute Declaration</head>
<p>An attribute declaration is an association between a name and a simple type definition, together
with occurrence information and (optionally) a default value. The
association is either global, or local to its containing complex type definition.  Attribute declarations contribute to
<termref def="key-vn">validation</termref> as part of complex type definition <termref def="key-vn">validation</termref>, when their
occurrence, defaults and type components are checked against an attribute
information item with a matching name and namespace.</p>
     <p>
For detailed information on attribute declarations, see <specref ref="cAttribute_Declarations"/>.</p>
</div4>
<div4 id="Notation_Declaration">
<head>Notation Declaration</head>
<p>A notation declaration is an association between a name and an identifier for a
notation.  For an attribute information item to be <termref def="key-vn">valid</termref> with respect to a
<code>NOTATION</code> simple type definition, its value must have been declared
with a notation declaration.</p>
     <p>
For detailed information on notation declarations, see <specref ref="cNotation_Declarations"/>.</p>
</div4>
</div3>

     <div3 id="Model_Group_Summary">
<head>Model Group Components</head>
<p>The model group, particle, and wildcard components contribute to
the portion of a complex type definition that controls an element
information item's content.</p>
<div4 id="Model_Group">
<head>Model Group</head>
<p>A model group is a constraint in the form of a grammar fragment that applies to
lists of element information items.  It consists of a list of particles, i.e.
element declarations, wildcards and model groups.  There are three varieties of
model group:</p>
<ulist>
<item><p>Sequence (the element information items
match the particles in sequential order);</p></item>
<item><p>Conjunction (the element information items match the
particles, in any order);</p></item>
<item><p>Disjunction (the element information items match
one of the particles).</p></item>
</ulist>
     <p>
For detailed information on model groups, see <specref ref="Model_Groups"/>.</p>
</div4>
<div4 id="Particle">
<head>Particle</head>
<p>A particle is a term in the grammar for element content, consisting of either an element
declaration, a wildcard or a model group, together with
occurrence constraints.  Particles contribute to
<termref def="key-vn">validation</termref> as part of complex type definition <termref def="key-vn">validation</termref>, when they allow anywhere
from zero to many element information items or sequences thereof, depending on
their contents and occurrence
constraints.</p>
      <p><termdef id="key-contentModel" term="content model">A particle can
be used in a complex type definition to constrain the <termref def="key-vn">validation</termref>
of the &i-children; of an element information item; such a particle is called
a <term>content model</term></termdef>.
<note>
<p>&XSP1; <termref def="key-contentModel">content models</termref> are similar to but more expressive than
<bibref ref="ref-xml"/> content models; unlike <bibref ref="ref-xml"/>, &XSP1; applies <termref def="key-contentModel">content models</termref> to the <termref def="key-vn">validation</termref> of both mixed and element-only content. </p>
</note></p>
     <p>
For detailed information on particles, see <specref ref="cParticles"/>.</p>
</div4>
      <div4 id="Attribute_Use">
       <head>Attribute Use</head>
       <p>An attribute use plays a role similar to that of a particle, but for
attribute declarations:  an attribute declaration within a complex type definition
is embedded within an attribute use, which specifies whether the declaration
requires or merely allows its attribute, and whether it has a default or fixed value.</p>
      </div4>
      <div4 id="Wildcard">
<head>Wildcard</head>
<p>A wildcard is a special kind of particle which matches element and attribute information items dependent on their namespace name, independently
of their local names.</p>
     <p>
For detailed information on wildcards, see <specref ref="Wildcards"/>.</p>
</div4>
</div3>

     <div3 id="&Constraint;_Definition">
<head>&Constraint; Definition Components</head>
<p>An &constraint; definition is an association between a name and one of
several varieties of
&constraint; related to uniqueness and reference.  All the
varieties use <bibref ref="bib-xpath"/> expressions to pick out sets of
information items relative to particular target element
information items which are unique, or a key, or a <termref def="key-vn">valid</termref> reference, within
a specified scope. An element information item is only <termref def="key-vn">valid</termref> with
respect to an element declaration
with &constraint; definitions if those definitions are all satisfied for all the descendants
of that element information item which they pick out.</p>
     <p>
For detailed information on &constraint; definitions, see <specref ref="c&Constraint;_Definitions"/>.</p>
    </div3>
<div3 id="Group_Definitions">
<head>Group Definition Components</head>
<p>There are two kinds of convenience definitions provided to enable
the re-use of pieces of complex type definitions: model group definitions
and attribute group definitions.</p>
<div4 id="Model_Group_Definition">
<head>Model Group Definition</head>
<p>A model group definition is an association between a name and a model group,
enabling re-use of the same model group in several complex type
definitions.</p>
     <p>
For detailed information on model group definitions, see <specref ref="cModel_Group_Definitions"/>.</p>
</div4>
<div4 id="Attribute_Group_Definition">
<head>Attribute Group Definition</head>
<p>An attribute group definition is an association between a name and a set of attribute declarations,
enabling re-use of the same set in several complex type
definitions.</p>
     <p>
For detailed information on attribute group definitions, see <specref ref="cAttribute_Group_Definitions"/>.</p>
</div4>
</div3>
    <div3 id="Annotation">
     <head>Annotation Components</head>
     <p>An annotation is information for human and/or mechanical
consumers. The interpretation of such information is
not defined in this specification.</p>
     <p>
For detailed information on annotations, see <specref ref="cAnnotations"/>.</p>

     </div3>
   </div2>
    <div2 id="concepts-schemaConstraints">
      <head>Constraints and Validation Rules</head>
      <p>The <bibref ref="ref-xml"/> specification describes two kinds of
        constraints on XML documents: <emph>well-formedness</emph> and
        <emph>validity</emph> constraints. Informally, the well-formedness constraints
        are those imposed by the definition of XML itself (such as the rules for the
        use of the &lt; and &gt; characters and the rules for proper nesting of
        elements), while validity constraints are the further constraints on document
        structure provided by a particular DTD. </p>
      <p>The preceding section focused on <termref def="key-vn">validation</termref>, that is
the constraints on information items which schema components supply.  In fact
however this specification provides four different kinds of normative statements about schema
        components, their representations in XML and their contribution to the
<termref def="key-vn">validation</termref> of information items:</p>
      <glist>
        <gitem>
          <label>Schema Component Constraint</label>
          <def>
            <p><termdef id="gloss-cos" term="Schema Component Constraint">Constraints on the schema components themselves, i.e.
conditions components must satisfy to be components at all.  Located in the
sixth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="outcome-cos"/></termdef>.</p>
          </def>
        </gitem>
       <gitem>
        <label>Schema Representation Constraint</label>
        <def>
         <p><termdef id="gloss-src" term="Schema Representation Constraint">Constraints on the
representation of schema components in XML beyond those which are expressed
in <specref ref="normative-schemaSchema"/>.  Located in the
third sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="outcome-src"/></termdef>.</p>
        </def>
       </gitem>
        <gitem>
          <label>Validation Rules</label>
          <def>
            <p><termdef id="gloss-cvc" term="Validation
Rules">Contributions to <termref def="key-vn">validation</termref> associated
with schema components.  Located in the
fourth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="validation_failures"/></termdef>.</p>
          </def>
        </gitem>
       <gitem>
          <label>Schema Information Set
            Contribution</label>
          <def>
            <p><termdef id="gloss-sic" term="Schema Information Set Contribution">Augmentations to &PSVI;s
expressed by schema components, which follow
              as a consequence of <termref def="key-vn">validation</termref> and/or <termref def="key-va">assessment</termref>.
Located in the
fifth sub-section of the per-component sections of <specref ref="components"/>
and tabulated in <specref ref="PSVI_contributions"/></termdef>.</p>
          </def>
        </gitem>
      </glist>
        <p>The last of these, schema information set
          contributions, are not as new as they might at first seem.  XML 1.0
          validation augments the XML 1.0 information set in similar ways,
for example by
          providing values for attributes not present in instances, and by implicitly
          exploiting type information for normalization or access.
(As an example of the latter case, consider the
          effect of <code>NMTOKENS</code> on attribute white space, and the semantics of
          <code>ID</code> and <code>IDREF</code>.) By including schema
information set contributions, this specification makes explicit some features
that XML 1.0 left implicit.</p>

    </div2>
<div2 id="concepts-conformance">
<head>Conformance</head>
<p>This specification describes three levels of conformance for schema aware processors.  The first is
required of all processors.  Support for the other two will depend on the application environments
for which the processor is intended.</p>
<p><termdef id="key-minimallyConforming" term="minimally conforming"><term>Minimally conforming</term> processors must completely and
correctly implement the <termref def="gloss-cos">Schema Component
Constraints</termref>, <termref def="gloss-cvc">Validation Rules</termref>,
and <termref def="gloss-sic">Schema Information
Set Contributions</termref> contained in this specification</termdef>.</p>
<p><termdef id="key-interchange" term="conformance to the XML Representation of Schemas"><termref def="key-minimallyConforming">Minimally conforming</termref> processors which accept
schemas represented in the form of XML documents as described in <specref ref="layer2"/> are
additionally said to provide <term>conformance to the XML Representation of Schemas</term>.
</termdef>
Such processors must, when processing schema documents, completely and
correctly implement all <termref def="gloss-src">Schema Representation
Constraints</termref> in this specification, and must adhere exactly to the
specifications in <specref ref="components"/> for mapping the contents of
such documents to <termref def="key-component">schema
components</termref> for use in <termref def="key-vn">validation</termref> and <termref def="key-va">assessment</termref>.</p>
<note>
<p>By separating the conformance requirements relating to the concrete syntax of XML schema
documents, this specification admits processors
which use schemas stored in optimized binary
representations, dynamically created schemas represented as programming language data structures, or implementations in which particular schemas are compiled into executable code
such as C or Java.  Such processors can be said to be <termref def="key-minimallyConforming">minimally conforming</termref> but not necessarily in <termref def="key-interchange">conformance to the XML Representation of Schemas</termref>.</p>
</note>
<p><termdef id="key-fullyConforming" term="fully conforming"> <term>Fully conforming</term>
processors are network-enabled processors which are not only both <termref def="key-minimallyConforming">minimally conforming</termref> and <termref def="key-interchange">in conformance to the XML Representation of Schemas</termref>, but which additionally must be capable of accessing
schema documents from the World Wide Web according to <specref ref="web-representation"/> and <specref ref="schema-loc"/>.
</termdef>.
</p>
<note><p>Although this specification provides just these three standard levels of conformance, it is
anticipated that other conventions can be established in the future.  For example, the World Wide
Web Consortium is considering conventions for packaging on the Web a variety of
resources relating to individual documents and namespaces.  Should such
developments lead to new conventions for representing schemas, or for accessing them on the Web,
new levels of conformance can be established and named at that time.  There is no need to modify
or republish this specification to define such additional levels of conformance.</p></note>
 <p>See <specref ref="composition"/> for a more detailed explanation of the
mechanisms supporting these levels of conformance.</p>
</div2>
    <div2 id="concepts-nameSymbolSpaces">
      <head>Names and Symbol Spaces</head>
      <p>As discussed in <specref ref="concepts-data-model"/>, most schema
        components (may) have <termref def="key-compName">names</termref>.
If all such names were assigned from the same <quote>pool</quote>, then
        it would be impossible to have, for example, a simple type definition and an element
declaration both with the name
<quote>title</quote> in a given <termref def="key-targetNS">target namespace</termref>.</p>
      <p>
        Therefore <termdef id="key-symbolSpace" term="symbol space">this specification introduces the term
<term>symbol space</term> to denote a
collection of names, each of which is unique with respect to the others</termdef>.  A symbol space is similar to the non-normative concept of <xtermref href="http://www.w3.org/TR/REC-xml-names/#ns-breakdown">namespace partition</xtermref> introduced in <bibref ref="ref-xml-namespaces"/>.
There is a single distinct symbol space within a given <termref def="key-targetNS">target
namespace</termref> for each kind of definition and declaration component
identified in <specref ref="concepts-data-model"/>, except that within a target namespace, simple
type definitions and complex type definitions share a symbol space.
Within a given symbol space, names are unique, but the same name may appear in more than one symbol space without conflict. For example, the same name can appear in both a type definition and an element declaration, without conflict or necessary relation between the two.
</p>
      <p>Locally scoped attribute and element
declarations are special with regard to symbol spaces.
Every complex type definition defines its own local attribute and element declaration symbol
        spaces, where these symbol spaces are distinct from each other and from any of the other
symbol spaces.  So, for example, two complex type definitions having
the same target namespace can contain
a local attribute declaration for the unqualified name <quote>priority</quote>, or contain a local element declaration
for the name <quote>address</quote>, without conflict or necessary relation between
the two.</p>
    </div2>
<div2 id="Instance_Document_Constructions"> <head>Schema-Related Markup in
Documents Being Validated</head>
  <p>The XML representation of schema components uses a vocabulary
identified by the namespace name <code>http://www.w3.org/2001/XMLSchema</code>.  For brevity, the text and examples in this specification use the prefix
<code>xs:</code> to stand for this namespace; in practice,
any prefix can be used.</p>
 <p>&XSP1; also defines several attributes for direct use in any XML documents.  These attributes are in a different namespace,
which has the namespace name <code>http://www.w3.org/2001/XMLSchema-instance</code>.
For brevity, the text and examples in this specification use the prefix
<code>xsi:</code> to stand for this latter namespace; in practice,
any prefix can be used.  All schema processors have appropriate attribute
declarations for these attributes built in, see <specref ref="xsi.type"/>,
<specref ref="xsi.nil"/>, <specref ref="xsi.schemaLocation"/> and <specref ref="xsi.noNamespaceSchemaLocation"/>.</p>
<div3 id="xsi_type">
<head>xsi:type</head>
<p>The <specref ref="Simple_Type_Definition"/> or <specref ref="Complex_Type_Definition"/> used in <termref def="key-vn">validation</termref> of an element is usually
determined by reference to the appropriate schema components.
An element information item in an instance may, however,
explicitly assert its type using the attribute <code>xsi:type</code>.
The value of this attribute is a <termref def="gloss-QName">QName</termref>;  see <specref ref="src-qname"/> for
the means by which the <termref def="gloss-QName">QName</termref> is
associated with a type definition.
</p>
</div3>
<div3 id="xsi_nil">
<head>xsi:nil</head>
<p>&XSP1; introduces a mechanism for signaling that an element should
be accepted as <termref def="key-vn">valid</termref> when it has no
content despite a content type which does not require or even necessarily allow empty content.  An
element may be 
<termref def="key-vn">valid</termref> without content if it has the attribute <code>xsi:nil</code> with
the value <code>true</code>.  An element so labeled must be empty, but can
carry attributes if permitted by the corresponding complex type.</p>
</div3>
<div3 id="xsi_schemaLocation">
<head>xsi:schemaLocation, xsi:noNamespaceSchemaLocation</head>
<p>The <code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code> attributes can be used in a document to provide
hints as to the physical location of schema documents which may be used for <termref def="key-va">assessment</termref>.
See <specref ref="schema-loc"/> for details on the use of these attributes.</p>
</div3>
</div2>
<div2 id="web-representation">
<head>Representation of Schemas on the World Wide Web</head>
<p>On the World Wide Web, schemas are conventionally represented as XML
documents (preferably of MIME type
<code>application/xml</code> or <code>text/xml</code>, but see <clauseref ref="c-vxd"/> of <specref ref="src-include"/>), conforming to the specifications in <specref ref="layer2"/>. For more information on
the representation and use of schema documents on the World Wide Web see <specref ref="schema-repr"/> and
<specref ref="schema-loc"/>. </p>
</div2>
 </div1>
  <div1 id="components">
   <head>Schema Component Details</head>
   <div2 id="scIntro">
    <head>Introduction</head>
    <p>The following sections provide full details on the composition of all schema components, together
with their XML representations and their contributions to <termref def="key-va">assessment</termref>.  Each section is devoted to a single component, with separate subsections for
     <olist>
      <item>
       <p>properties:  their values and significance</p>
      </item>
      <item>
       <p>XML representation and the mapping to properties</p>
      </item>
      <item>
       <p>constraints on representation</p>
      </item>
      <item>
       <p>validation rules</p>
      </item>
      <item>
       <p>&PSVI; contributions</p>
      </item>
      <item>
       <p>constraints on the components themselves</p>
      </item>
     </olist>
The sub-sections immediately below introduce conventions and terminology used throughout the component sections.</p>
   <div3>
    <head>Components and Properties</head>
    <p>Components are defined in terms of their
properties, and each property in turn is defined by giving its range,
that is the values it may have.  This can be understood as
defining a schema as a labeled directed graph, where the root is a schema,
every other vertex is a schema
component or a literal (string, boolean, number) and every labeled edge is a
property.  The graph is <emph>not</emph> acyclic:  multiple copies of
components with the same name in the same <termref def="key-symbolSpace">symbol space</termref> may not exist, so in some cases re-entrant chains
of properties must exist.  Equality of components for the purposes of this
specification is always defined as equality of names (including target
namespaces) within symbol spaces.</p>
    <note>
    <p>A schema and its components as defined in this chapter are an idealization of the information a schema-aware
processor requires:  implementations are not constrained in how they provide
it.  In particular, no implications about literal embedding versus indirection
follow from the use below of language such as "properties . . . having . . .
components as values".</p>
   </note>
   <p><termdef id="key-null" term="absent">Throughout this specification, the
term <term>absent</term> is used as a distinguished property value denoting absence</termdef>.</p>
   <p>Any property not
identified as optional is required to be present; optional properties which are
not present are taken to have <termref def="key-null">absent</termref> as their value.  Any
property identified as a having a set, subset or list value may have an empty value unless this is explicitly
ruled out:  this is <emph>not</emph> the same as <termref def="key-null">absent</termref>.  Any property value identified as a superset or subset of some set may be equal to that set, unless a proper superset or subset is explicitly called for.
By 'string' in Part 1 of this specification is meant a
sequence of ISO 10646 characters identified as <xtermref href="http://www.w3.org/TR/REC-xml#charsets">legal XML characters</xtermref>
in <bibref ref="ref-xml"/>.</p></div3>
   <div3>
    <head>XML Representations of Components</head>
    <p>The principal purpose of &XSP1; is to define a set of
      schema components that constrain the contents of instances and augment the
      information sets thereof.  Although no external representation
of schemas is required for this purpose, such representations will
obviously be widely used. To provide for this in an appropriate and
interoperable way, this specification provides a normative XML representation for schemas which
makes provision for every kind of schema
component.  <termdef id="key-schemaDoc" term="schema document">A document in
this form (i.e. a <eltref ref="schema"/> element information item) is a <term>schema document</term></termdef>.  For the schema document as a whole, and
its constituents, the sections below define correspondences between element
information items (with declarations in
<specref ref="normative-schemaSchema"/> and <specref ref="nonnormative-schemaDTD"/>) and
schema components.  All the element information items in the XML representation
of a schema must be in the XML Schema namespace, that is their <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace name</xpropref> must be <code>http://www.w3.org/2001/XMLSchema</code>.  Although a common way of creating the XML Infosets which are or contain <termref def="key-schemaDoc">schema documents</termref> will be using an XML parser, this is not required:  any mechanism which constructs conformant infosets as defined in <bibref ref="ref-xmlinfo"/> is a possible starting point.</p>
    <p>Two aspects of the XML representations of components presented in the
following sections are constant across them all:
    <olist>
     <item>
      <p>All of them allow attributes qualified with namespace names other than
the XML Schema namespace itself: these appear as annotations in the
corresponding schema component;</p>
     </item>
     <item>
      <p>All of them allow an <eltref ref="annotation"/> as their first child, for human-readable documentation and/or machine-targeted information.</p>
     </item>
    </olist>
   </p>
   </div3>
    <div3>
    <head>The Mapping between XML Representations and Components</head>
    <p>For each kind of schema component there is a corresponding normative XML representation.
The sections below describe the correspondences between the properties of each kind of
schema component on the one hand and the properties of information items in
that XML representation on the other, together
with constraints on that representation above and beyond those implicit in the
<specref ref="normative-schemaSchema"/>.</p>
 <p>The language used is as if the correspondences were mappings from XML representation to
schema component, but the mapping in the other direction, and therefore the
correspondence in the abstract, can always be
constructed therefrom.</p>
     <p>In discussing the mapping from XML representations to schema
components below, the value of a component property is often determined by the
value of an attribute information item, one of the &i-attributes; of an element
information item.  Since schema documents are constrained by the
<specref ref="normative-schemaSchema"/>, there is always a simple type
definition associated with any such attribute information item.  <termdef id="key-vv" term="actual value">The
phrase <term>actual value</term> is used to refer to the member of the value space of the
simple type definition associated with an attribute information item which corresponds to
its &i-value;</termdef>.  This will often be a string, but may also be an
integer, a boolean, a URI reference, etc.  This term is also occasionally used with respect to element or attribute information items in a document being <termref def="key-va">validated</termref>.</p>
   <p>Many properties are identified below as having
other schema components or sets of components as values.  For the purposes of exposition, the definitions in
this section assume that (unless the property is explicitly identified as
optional) all such values are in fact present.  When schema
components are constructed from XML representations involving reference by name
to other components, this assumption may be violated if one or more references
cannot be resolved.  This specification addresses the matter of missing
components in a uniform manner, described in <specref ref="conformance-missing"/>:  no mention of
handling missing components will be found in the individual component
descriptions below.</p>
   <p>Forward reference to named definitions and declarations <emph>is</emph>
allowed, both within and between <termref def="key-schemaDoc">schema documents</termref>. 
By the time the component corresponding to an XML representation which
contains a forward reference is actually needed for <termref def="key-vn">validation</termref> an appropriately-named component may have become available to discharge the reference: see <specref ref="composition"/> for details.</p>
   </div3>
   <div3>
    <head>White Space Normalization during Validation</head>
    <p>Throughout this specification, <termdef id="key-iv" term="initial value">the
<term>initial value</term> of some
attribute information item is the value of the
<xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">normalized
value</xpropref> property of that item.  Similarly, the <term>initial value</term> of an element information item is the string composed of, in order, the
&i-ccode; of each character information item in the &i-children; of that
element information item</termdef>.</p>
   <p>The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all <termref def="key-vn">validation</termref> purposes.</p>
   <p><termdef id="key-nv" term="normalized value">The
<term>normalized value</term> of an element or
attribute information item is an &r-value; whose white space, if any, has been
normalized according to the value of the <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#rf-whiteSpace">whiteSpace facet</xtermref> of the
simple type definition used in its <termref def="key-vn">validation</termref>:
 </termdef>
    <glist>
     <gitem>
      <label>preserve</label>
      <def>
       <p>No normalization is done, the value is the &i-value;</p>
      </def>
     </gitem>
     <gitem>
      <label>replace</label>
      <def>
       <p>All occurrences of <code>#x9</code> (tab), <code>#xA</code> (line feed) and
<code>#xD</code> (carriage return) are replaced with <code>#x20</code> (space).</p>
      </def>
     </gitem>
     <gitem>
      <label>collapse</label>
      <def>
       <p>Subsequent to the replacements specified above under <local>replace</local>,
contiguous sequences of <code>#x20</code>s are collapsed to a single
<code>#x20</code>, and initial and/or final <code>#x20</code>s are deleted.</p>
      </def>
     </gitem>
    </glist>
   </p>
    <p diff="add">If the simple type definition used in an item's <termref def="key-vn">validation</termref> is the <termref def="key-simpleUrType">simple ur-type definition</termref>, the <termref def="key-nv">normalized value</termref> must be determined as in the <local>preserve</local> case above.</p>
   <p>There are three alternative validation rules which may supply the
necessary background for the above:  <specref ref="cvc-attribute"/> (<clauseref ref="c-sva"/>), <specref ref="cvc-type"/> (<clauseref ref="c-sv1"/>) or <specref ref="cvc-complex-type"/> (<clauseref ref="c-sv2"/>).</p>
   <p>These three levels of normalization correspond to the processing mandated
in XML 1.0 for element content, CDATA attribute content and tokenized
attributed content, respectively.  See <xspecref href="http://www.w3.org/TR/REC-xml#AVNormalize">Attribute Value Normalization</xspecref> in <bibref ref="ref-xml"/> for the precedent for <local>replace</local> and <local>collapse</local> for attributes.  Extending this processing to element content is necessary to ensure a consistent <termref def="key-vn">validation</termref> semantics for simple types, regardless of whether they are applied to attributes or elements.  Performing it twice in the case of attributes whose <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">normalized
value</xpropref> has already been subject to replacement or collapse on the basis of
information in a DTD is necessary to ensure consistent treatment of attributes
regardless of the extent to which DTD-based information has been made use of
during infoset construction.</p>
   <note>
    <p>Even when DTD-based information <emph>has</emph> been appealed to, and
<xspecref href="http://www.w3.org/TR/REC-xml#AVNormalize">Attribute Value
Normalization</xspecref> has taken place, the above definition of &i-value; may
mean <emph>further</emph> normalization takes place, as for instance when
character entity references in attribute values result in white space characters
other than spaces in their &r-value;s.</p>
   </note>
   </div3>
   </div2>
   <div2 id="cAttribute_Declarations">
    <head>Attribute Declarations</head>
    <p>Attribute declarations provide for:</p>
    <ulist>
     <item><p>Local <termref def="key-vn">validation</termref> of attribute information item values using a simple type definition;</p></item>
     <item><p>Specifying default or fixed values for attribute information items.</p></item>
    </ulist>
 <note role="example">
<eg xml:space="preserve"><![CDATA[<xs:attribute name="age" type="xs:positiveInteger" use="required"/>]]>
</eg>
<p>The XML representation of an attribute declaration.</p>
</note>
    <div3 id="Attribute_Declaration_details">
     <head>The Attribute Declaration Schema Component</head>
    <p>The attribute declaration schema component has the following
properties:</p>
    <compdef name="Attribute Declaration" ref="Attribute_Declaration">
     <proplist>
      <propdef id="a-name" name="name">An NCName as defined by
<bibref ref="ref-xml-namespaces"/>.</propdef>
      <propdef id="a-target_namespace" name="target namespace">Either <termref def="key-null">absent</termref> or
a namespace name, as defined in <bibref ref="ref-xml-namespaces"/>.</propdef>
      <propdef id="a-simple_type_definition" name="type definition">A
simple type definition.</propdef>
            <propdef id="a-scope" name="scope">Optional.  Either <pt>global</pt> or a complex type
definition.</propdef>
      <propdef id="a-value_constraint" name="value constraint">Optional.  A pair
consisting of a value and one of <pt>default</pt>, <pt>fixed</pt>.</propdef>
      <propdef id="a-annotation" name="annotation">Optional.  An annotation.</propdef>
     </proplist>
    </compdef>
<p>The <propref ref="a-name"/> property must match the local part of the names of attributes being <termref def="key-vn">validated</termref>.</p>
<p>The value of the attribute must conform to the supplied <propref ref="a-simple_type_definition"/>.</p>
    <p>A non-<termref def="key-null">absent</termref> value of the <propref ref="a-target_namespace"/> property provides for <termref def="key-vn">validation</termref> of
namespace-qualified attribute information items (which must be explicitly
prefixed in the character-level form of XML documents).  <termref def="key-null">Absent</termref> values of
<propref ref="a-target_namespace"/> <termref def="key-vn">validate</termref> unqualified (unprefixed) items.</p>
    <p>A <propref ref="a-scope"/> of <pt>global</pt> identifies attribute declarations
available for use in complex type definitions throughout the schema.  Locally scoped declarations are available for use only within the
complex type definition identified by the <propref ref="a-scope"/> property.  This property is <termref def="key-null">absent</termref> in the case of declarations within attribute group definitions:  their scope will be determined when they are used in the construction of complex type definitions.
</p>
<p><propref ref="a-value_constraint"/> reproduces the functions of XML 1.0 default and <code>#FIXED</code>
attribute values.  <pt>default</pt> specifies that the attribute is to appear unconditionally in
the &PSVI;, with the supplied value used
whenever the attribute is not actually present; <pt>fixed</pt> indicates that the attribute value if present must equal the supplied
constraint value, and if absent receives the supplied value as for
<pt>default</pt>.  Note that it is <emph>values</emph> that are supplied and/or
checked, not strings.</p>
    <p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="a-annotation"/> property.</p>
<note><p>A more complete and formal presentation of the semantics of <propref ref="a-name"/>, <propref ref="a-target_namespace"/> and <propref ref="a-value_constraint"/> is provided in
conjunction with other aspects of complex type <termref def="key-vn">validation</termref> (see <specref ref="cvc-complex-type"/>.)</p></note>
    <p><bibref ref="ref-xmlinfo"/> distinguishes attributes with names such as <code>xmlns</code> or <code>xmlns:xsl</code> from
ordinary attributes, identifying them as <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.element">namespace attributes</xpropref>.  Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see <specref ref="no-xmlns"/>.  No means is provided in
this specification to supply a
default value for a namespace declaration.</p> 
</div3>
    <div3 id="declare-attribute">
<head>XML Representation of Attribute Declaration Schema Components</head>
<p>The XML representation for an attribute declaration schema component is an
<eltref ref="attribute"/> element information item.  It specifies a simple type
definition for an attribute either by reference or explicitly, and may provide default information.  The correspondences between the
properties of the information item and
properties of the component are as follows:</p>
<reprdef>
 <reprelt eltname="attribute" type="attribute"/>
 <p>If the <eltref ref="attribute"/> element information item has <eltref ref="schema"/> as its parent, the corresponding schema component is as follows:</p>
  <reprcomp ref="Attribute_Declaration_details" abstract="Attribute Declaration">
   <propmap name="a-name">The &v-value; of the <code>name</code> &i-attribute;</propmap>
  <propmap name="a-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <eltref ref="schema"/>
element information item, or <termref def="key-null">absent</termref> if there is none.</propmap>
 <propmap name="a-simple_type_definition">The simple type definition
corresponding to the <eltref ref="simpleType"/> element information item in the
&i-children;, if present, otherwise the simple type definition <termref def="src-resolve">resolved</termref> to by
the &v-value; of the <code>type</code> &i-attribute;, if present, otherwise the
<termref def="simple-ur-type-itself">simple ur-type definition</termref>.</propmap>
   <propmap name="a-scope"><pt>global</pt>.</propmap>
 <propmap name="a-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="a-simple_type_definition"/>) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
 <propmap name="a-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
 </reprcomp>
 <p>otherwise if the <eltref ref="attribute"/> element information item has
<eltref ref="complexType"/> or <eltref ref="attributeGroup"/> as an ancestor
and the <code>ref</code> &i-attribute; is absent, it corresponds to an
attribute use with properties as follows (unless <code>use='prohibited'</code>, in which case the item
corresponds to nothing at all):</p>
 <reprcomp ref="AU_details" abstract="Attribute Use">
  <propmap name="required"><pt>true</pt> if the <code>use</code>
&i-attribute; is present with &v-value; <code>required</code>, otherwise
<pt>false</pt>.</propmap>
  <propmap name="attribute">See the Attribute Declaration mapping
immediately below.</propmap>
  <propmap name="au-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="a-simple_type_definition"/> of the <propref ref="attribute"/>) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
 </reprcomp>
 <reprcomp ref="Attribute_Declaration_details" abstract="Attribute Declaration">
  <propmap name="a-name">The &v-value; of the <code>name</code> &i-attribute;</propmap>
  <propmap name="a-target_namespace">If <code>form</code> is present and its
&v-value; is <code>qualified</code>, or if <code>form</code> is absent and the
&v-value; of <code>attributeFormDefault</code> on the <eltref ref="schema"/>
ancestor is <code>qualified</code>, then the &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <eltref ref="schema"/>
element information item, or <termref def="key-null">absent</termref> if there
is none, otherwise <termref def="key-null">absent</termref>.</propmap>
  <propmap name="a-simple_type_definition">The simple type definition
corresponding to the <eltref ref="simpleType"/> element information item in the
&i-children;, if present, otherwise the simple type definition <termref def="src-resolve">resolved</termref> to by
the &v-value; of the <code>type</code> &i-attribute;, if present, otherwise the
<termref def="simple-ur-type-itself">simple ur-type definition</termref>.</propmap>
  <propmap name="a-scope">If the <eltref ref="attribute"/> element information item
has <eltref ref="complexType"/> as an ancestor, the complex definition
corresponding to that item, otherwise (the <eltref ref="attribute"/> element
information item is within an <eltref ref="attributeGroup"/> definition), <termref def="key-null">absent</termref>.</propmap>
  <propmap name="a-value_constraint"><termref def="key-null">absent</termref>.</propmap>
 <propmap name="a-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
 </reprcomp>
 <p>otherwise (the <eltref ref="attribute"/> element information item has
<eltref ref="complexType"/> or <eltref ref="attributeGroup"/> as an ancestor and the
<code>ref</code> &i-attribute; is present), it corresponds to an
attribute use with properties as follows (unless <code>use='prohibited'</code>, in which case the item
corresponds to nothing at all):</p>
 <reprcomp ref="AU_details" abstract="Attribute Use">
  <propmap name="required"><pt>true</pt> if the <code>use</code>
&i-attribute; is present with &v-value; <code>required</code>, otherwise
<pt>false</pt>.</propmap>
  <propmap name="attribute">The (top-level) attribute declaration <termref def="src-resolve">resolved</termref> to by the
&v-value; of the <code>ref</code> &i-attribute;</propmap>
  <propmap name="au-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="a-simple_type_definition"/> of the <propref ref="attribute"/>) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
 </reprcomp>
 </reprdef>
 <p>Attribute declarations can appear at the top level of a schema document, or within complex
type definitions, either as complete (local) declarations, or by reference to top-level
declarations, or within attribute group definitions.  For complete declarations, top-level or local, the <code>type</code> attribute is used when the declaration can use a
built-in or pre-declared simple type definition.  Otherwise an
anonymous <eltref ref="simpleType"/> is provided inline.</p>
 <p>The default when no simple type definition is referenced or
provided is the <termref def="key-simpleUrType">simple ur-type definition</termref>, which imposes no constraints at all.</p>
 <p>Attribute information items <termref def="key-vn">validated</termref> by a top-level declaration must be qualified with the
<propref ref="a-target_namespace"/> of that declaration (if this is <termref def="key-null">absent</termref>, the item must be unqualified).  Control over whether attribute information items
<termref def="key-vn">validated</termref> by a local declaration must be similarly qualified or not
is provided by the <code>form</code> &i-attribute;, whose default is provided
by the <code>attributeFormDefault</code> &i-attribute; on the enclosing <eltref ref="schema"/>, via its determination of <propref ref="a-target_namespace"/>.</p>
 <p>The names for top-level attribute declarations are in their own
<termref def="key-symbolSpace">symbol space</termref>.  The names of locally-scoped
attribute declarations reside in symbol spaces local to the type definition which contains
them.</p>
    </div3>
    <div3>
     <head>Constraints on XML Representations of Attribute Declarations</head>
 <constraintnote id="src-attribute" type="src">
  <head>Attribute Declaration Representation OK</head>
  <p>In addition to the conditions imposed on <eltref ref="attribute"/> element
information items by the schema for schemas,
   <olist role="and">
    <item>
     <p><code>default</code> and <code>fixed</code> must not both be present.</p>
    </item>
    <item>
     <p>If <code>default</code> and <code>use</code> are both present,
<code>use</code> must have the &v-value; <code>optional</code>.</p>
    </item>
    <item>
     <p>If the item's parent is not <eltref ref="schema"/>, then
      <olist role="and">
       <item>
     <p>One of <code>ref</code> or <code>name</code> must be present, but not both.</p>
    </item>
       <item>
        <p>If <code>ref</code> is present, then all of <eltref ref="simpleType"/>,
<code>form</code> and <code>type</code> must be absent.</p>
       </item>
      </olist>
     </p>
    </item>
    <item>
     <p><code>type</code> and <eltref ref="simpleType"/>
must not both be present.</p>
    </item>
    <item>
     <p>The corresponding attribute
declaration must satisfy the conditions set out in
<specref ref="coss-attribute"/>.</p>
    </item>
   </olist>
  </p>
 </constraintnote>
    </div3>
    <div3>
     <head>Attribute Declaration Validation Rules</head>
   <constraintnote type="cvc" id="cvc-attribute">
     <head>Attribute Locally Valid</head>
     <p>For an attribute information item to be locally <termref def="key-vn">valid</termref> with respect to an
attribute declaration 
      <olist role="and">
       <item id="c-a1">
        <p>The declaration must not be <termref def="key-null">absent</termref> (see <specref ref="conformance-missing"/> for
how this can fail to be the case).</p>
       </item>
       <item id="c-a2">
        <p>Its <propref ref="a-simple_type_definition"/> must not be absent.</p>
       </item>
       <item id="c-sva">
        <p>The item's &i-value; must be locally <termref def="key-vn">valid</termref> with respect to that <propref ref="a-simple_type_definition"/> as per <specref ref="cvc-simple-type"/>.</p>
       </item>
       <item>
        <p>The item's &v-value; must match the value of the <propref ref="a-value_constraint"/>, if it is
present and <pt>fixed</pt>.</p>
       </item>
      </olist>
     </p>
    </constraintnote>
    <constraintnote id="cvc-assess-attr" type="cvc">
     <head>Schema-Validity Assessment (Attribute)</head>
     <p>The schema-validity assessment of an attribute information item depends
on its <termref def="key-vn">validation</termref> alone.</p>
  <p><termdef id="key-dd" term="context-determined declaration">During <termref def="key-vn">validation</termref>, associations
between element and attribute information items among the &i-children;
and &i-attributes; on the one hand, and element and attribute
declarations on the other, are established as a side-effect.  Such
declarations are called the <term>context-determined declarations</term></termdef>. 
See <clauseref ref="c-ctma"/> (in <specref ref="cvc-complex-type"/>) for
attribute declarations, <clauseref ref="c-cdde"/> (in <specref ref="cvc-particle"/>) for element
declarations.</p>
  <p>For an attribute information item's schema-validity to have been assessed
      <olist role="and">
       <item>
        <p>A non-<termref def="key-null">absent</termref> attribute declaration
must be known for it, namely
         <olist role="orval">
          <item>
           <p>A declaration which has been established as its <termref def="key-dd">context-determined declaration</termref>;</p>
          </item>
          <item id="c-adbyr">
           <p>A declaration resolved to by its <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> and <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">namespace name</xpropref> as defined by <specref ref="cvc-resolve-instance"/>, provided its <termref def="key-dd">context-determined declaration</termref> is
not <pt>skip</pt>.</p>
          </item>
         </olist>
        </p>
       </item>
       <item>
        <p>Its <termref def="key-vn">validity</termref> with respect to that
declaration must have been evaluated as per <specref ref="cvc-attribute"/>.</p>
       </item>
       <item>
        <p>Both <clauseref ref="c-a1"/> and <clauseref ref="c-a2"/> of <specref ref="cvc-attribute"/> must be satisfied.</p>
       </item>
      </olist>
     </p>
<p><termdef id="key-svaa" term="strictly assessed" role="local">For attributes, there is no
difference between assessment and strict assessment, so if the above holds, the attribute information item has been <term>strictly assessed</term></termdef>.</p> 
    </constraintnote>
    </div3>
    <div3>
     <head>Attribute Declaration Information Set Contributions</head>
    <constraintnote id="sic-a-outcome" type="sic">
     <head>Assessment Outcome (Attribute)</head>
     <p>If the schema-validity of an attribute information item has been assessed
as per <specref ref="cvc-assess-attr"/>, then in the &PSVI; it has properties as follows:</p>
     <proplist role="psvi" item="attribute">
       <propdef name="validation context" id="a-validation_context">The nearest ancestor element information
item with a <propref role="psvi" ref="e-schema_information"/> property.</propdef>
       <propdef name="validity" id="a-validity">
        <olist role="Caseval">
       <item>
        <p role="if">it was <termref def="key-svaa">strictly assessed</termref></p>
        <p role="then">
         <olist role="caseval">
          <item>
           <p role="if">it was
<termref def="key-vn">valid</termref> as defined by <specref ref="cvc-attribute"/></p>
           <p role="then"><pt>valid</pt>;</p>
          </item>
          <item>
           <p role="otherwise"><pt>invalid</pt>.</p>
          </item>
         </olist> 
        </p>
       </item>
       <item>
        <p role="otherwise"><pt>notKnown</pt>.</p>
       </item>
      </olist>
       </propdef>
       <propdef name="validation attempted" id="a-validation_attempted">
       <olist role="Caseval">
       <item>
        <p role="if">it was <termref def="key-svaa">strictly assessed</termref></p>
        <p role="then"><pt>full</pt>;</p>
       </item>
       <item>
        <p role="otherwise"><pt>none</pt>.</p>
       </item>
      </olist></propdef>
       <propdef name="schema specified" id="a-schema_specified"><pt>infoset</pt>.  See <specref ref="sic-attrDefault"/> for the other possible value.</propdef>
      </proplist>
    </constraintnote>
    <constraintnote type="sic" id="sic-attr-error-code">
     <head>Validation Failure (Attribute)</head>
     <p>If the local <termref def="key-vn">validity</termref>, as defined by <specref ref="cvc-attribute"/>
above, of an attribute information item has been assessed,
in the &PSVI; the item has a
property:</p>
     <proplist role="psvi" item="attribute">
      <propdef id="a-schema_error_code" name="schema error code">
       <olist role="Caseval">
        <item>
         <p role="if">the item is not <termref def="key-vn">valid</termref></p>
         <p role="then">a list.  Applications wishing to provide
information as to the reason(s) for the <termref def="key-vn">validation</termref> failure are encouraged to record one or more
error codes (see <specref ref="outcomes"/>) herein.</p>
        </item>
        <item>
         <p role="otherwise"><termref def="key-null">absent</termref>.</p>
        </item>
       </olist>
      </propdef>
     </proplist>
    </constraintnote>
    <constraintnote type="sic" id="sic-attr-decl">
     <head>Attribute Declaration</head>
     <p>If an attribute information item is <termref def="key-vn">valid</termref> with respect to an attribute
declaration as per <specref ref="cvc-attribute"/> then in the &PSVI; the attribute
information item may, at processor option, have a property:</p>
     <proplist role="psvi" item="attribute">
      <propdef id="a-declaration" name="attribute declaration">
       An <termref def="key-iso">item isomorphic</termref> to the declaration component itself.
      </propdef>
     </proplist>
    </constraintnote>
    <constraintnote type="sic" id="sic-attrType">
     <head>Attribute Validated by Type</head>
     <p>If <clauseref ref="c-sva"/> of <specref ref="cvc-attribute"/> applies with
respect to an attribute information item, in the &PSVI; the attribute
information item has a property:</p>
     <proplist role="psvi" item="attribute">
      <propdef id="a-schema_normalized_value" name="schema normalized value">
       The &i-value; of the item as <termref def="key-vn">validated</termref>.
      </propdef>
     </proplist>
     <p>Furthermore, the item has one of the following alternative sets of properties:</p>
     <p>Either</p>
    <proplist role="psvi" item="attribute">
      <propdef id="a-type_definition" name="type definition">An <termref def="key-iso">item isomorphic</termref> to the relevant attribute declaration's
<propref ref="a-simple_type_definition"/> component.</propdef>
     <propdef name="member type definition" id="a-member_type_definition">If
and only if that type definition has <propref ref="variety"/> <pt>union</pt>, then an
<termref def="key-iso">item isomorphic</termref> to that member of its <propref ref="st-member_type_definitions"/> which actually <termref def="key-vn">validated</termref> the attribute item's <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">normalized value</xpropref>.</propdef>
     </proplist>     
      <p>or</p>
    <proplist role="psvi" item="attribute">
      <propdef id="a-type_definition_type" name="type definition
type">
<pt>simple</pt>.</propdef>
       <propdef id="a-type_definition_namespace" name="type definition namespace">The <propref ref="st-target_namespace"/> of the <termref def="key-typeDefn">type definition</termref>.</propdef>
        <propdef name="type definition anonymous" id="a-type_definition_anonymous"><pt>true</pt> if the <propref ref="st-name"/> of the <termref def="key-typeDefn">type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
        <propdef name="type definition name" id="a-type_definition_name">The <propref ref="st-name"/> of the <termref def="key-typeDefn">type definition</termref>, if it is not <termref def="key-null">absent</termref>.  If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
       </proplist>
        <p>If the <termref def="key-typeDefn">type definition</termref> has <propref ref="variety"/> <pt>union</pt>, then calling
         <termdef id="a-key-amt" term="actual member type definition" role="local"> that
member of the <propref ref="st-member_type_definitions"/> which actually
<termref def="key-vn">validated</termref> the attribute item's &i-value; the
<term>actual member type definition</term></termdef>, there are three additional properties:</p>
    <proplist role="psvi" item="attribute">
     <propdef name="member type definition namespace" id="a-member_type_definition_namespace">The <propref ref="st-target_namespace"/> of the <termref def="a-key-amt">actual
member type definition</termref>.</propdef>
     <propdef name="member type definition anonymous" id="a-member_type_definition_anonymous"><pt>true</pt> if the <propref ref="st-name"/> of the <termref def="a-key-amt">actual member type definition</termref> is <termref def="key-null">absent</termref>, otherwise <pt>false</pt>.</propdef>
     <propdef name="member type definition name" id="a-member_type_definition_name">The <propref ref="st-name"/> of the <termref def="a-key-amt">actual member type definition</termref>, if it is not <termref def="key-null">absent</termref>.  If it is
<termref def="key-null">absent</termref>, schema processors may, but need not,
provide a value unique to the definition.</propdef>
         </proplist>
     <p>The first (<termref def="key-iso">item isomorphic</termref>) alternative above is provided for applications such as query
processors which need access to the full range of details about an item's
<termref def="key-va">assessment</termref>, for example the type hierarchy; the second, for lighter-weight
processors for whom representing the significant parts of the type hierarchy as
information items might be a significant burden.</p>     
     <p>Also, if the declaration has a <propref ref="a-value_constraint"/>, the
item has a property:</p>
     <proplist role="psvi" item="attribute">
      <propdef id="a-schema_default" name="schema default">
       The <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dt-canonical-representation">canonical lexical representation</xtermref> of
the declaration's <propref ref="a-value_constraint"/> value.
      </propdef>
     </proplist>
     <p>If the attribute information item was not <termref def="key-svaa">strictly assessed</termref>, then instead of the values specified above,
      <olist>
       <item>
        <p>The item's <propref ref="a-schema_normalized_value" role="psvi"/>
property has
the &r-value; of the item as its value;</p>
       </item>
       <item>
        <p>The <propref ref="a-type_definition" role="psvi"/> and
<propref ref="a-member_type_definition" role="psvi"/> properties, or their
alternatives, are based on the <termref def="simple-ur-type-itself">simple ur-type definition</termref>.</p>
       </item>
      </olist>
     </p>   
    </constraintnote>
    </div3>
    <div3 id="coss-attribute">
     <head>Constraints on Attribute Declaration Schema Components</head>
  <p>All attribute declarations (see <specref ref="cAttribute_Declarations"/>) must satisfy the following constraints.</p>
  <constraintnote type="cos" id="a-props-correct">
   <head>Attribute Declaration Properties Correct</head>
   <olist role="And">
    <item>
     <p>The values of the properties of an attribute declaration must be as described in
the property tableau in
<specref ref="Attribute_Declaration_details"/>, modulo the impact of <specref ref="conformance-missing"/>.</p>
    </item>
    <item>
     <p>if there is a <propref ref="a-value_constraint"/>, the <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dt-canonical-representation">canonical lexical representation</xtermref> of its value must be
<termref def="key-vn">valid</termref> with respect to the <propref ref="a-simple_type_definition"/> as
defined in <specref ref="cvc-simple-type"/>.
     </p>
    </item>
    <item>
     <p>If the <propref ref="a-simple_type_definition"/> is or is derived from <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#ID">ID</xtermref> then there must not be a <propref ref="a-value_constraint"/>.</p>
    </item>
   </olist>
  </constraintnote>
  <constraintnote type="cos" id="no-xmlns">
   <head><code>xmlns</code> Not Allowed</head>
   <p>The <propref ref="a-name"/> of an attribute declaration must not match <code>xmlns</code>.</p>
<note>
<p>The <propref ref="a-name"/> of an attribute is an <termref def="gloss-NCName">NCName</termref>, which implicitly
prohibits attribute declarations of the form <code>xmlns:*</code>.</p>
</note>
  </constraintnote>
  <constraintnote type="cos" id="no-xsi">
   <head><code>xsi:</code> Not Allowed</head>
   <p>The <propref ref="a-target_namespace"/> of an attribute declaration,
whether local or top-level, must not match <code>http://www.w3.org/2001/XMLSchema-instance</code>
(unless it is one of the four built-in declarations given in the next section).</p>
   <note>
<p>This reinforces the special status of these attributes, so that they not
only <emph>need</emph> not be declared to be allowed in instances, but
<emph>must</emph> not be declared.  It also removes any temptation to experiment with supplying global or fixed values
for e.g. <code>xsi:type</code> or <code>xsi:nil</code>, which would be
seriously misleading, as they would have no effect.</p>
</note>
  </constraintnote>
    </div3>
    <div3>
     <head>Built-in Attribute Declarations</head>
     <p>There are four attribute declarations present in every
schema by definition:</p>
    <schemaComp id="xsi.type">
     <head>Attribute Declaration for the 'type' attribute</head>
     <pvlist>
      <pvpair ref="a-name"><code>type</code></pvpair>
      <pvpair ref="a-target_namespace"><code>http://www.w3.org/2001/XMLSchema-instance</code></pvpair>
      <pvpair ref="type_definition">The built-in <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#QName">QName</xtermref> simple
type definition</pvpair>
      <pvpair ref="a-scope"><pt>global</pt></pvpair>
      <pvpair ref="a-value_constraint"><termref def="key-null">absent</termref></pvpair>
      <pvpair ref="a-annotation"><termref def="key-null">absent</termref></pvpair>
     </pvlist>
    </schemaComp>
     <schemaComp id="xsi.nil">
     <head>Attribute Declaration for the 'nil' attribute</head>
      <pvlist>
      <pvpair ref="a-name"><code>nil</code></pvpair>
      <pvpair ref="a-target_namespace"><code>http://www.w3.org/2001/XMLSchema-instance</code></pvpair>
      <pvpair ref="type_definition">The built-in <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#boolean">boolean</xtermref> simple
type definition</pvpair>
      <pvpair ref="a-scope"><pt>global</pt></pvpair>
      <pvpair ref="a-value_constraint"><termref def="key-null">absent</termref></pvpair>
      <pvpair ref="a-annotation"><termref def="key-null">absent</termref></pvpair>
     </pvlist>
     </schemaComp>
     <schemaComp id="xsi.schemaLocation">
     <head>Attribute Declaration for the 'schemaLocation' attribute</head>
      <pvlist>
      <pvpair ref="a-name"><code>schemaLocation</code></pvpair>
      <pvpair ref="a-target_namespace"><code>http://www.w3.org/2001/XMLSchema-instance</code></pvpair>
      <pvpair ref="type_definition">An anonymous simple type definition, as follows:
       <pvlist>
        <pvpair ref="st-name"><termref def="key-null">absent</termref></pvpair>
        <pvpair ref="st-target_namespace"><code>http://www.w3.org/2001/XMLSchema-instance</code></pvpair>
        <pvpair ref="st-base_type_definition">The built in <termref def="simple-ur-type-itself">simple ur-type definition</termref></pvpair>
        <pvpair ref="facets"><termref def="key-null">absent</termref></pvpair>
        <pvpair ref="variety"><pt>list</pt></pvpair>
        <pvpair ref="st-item_type_definition">The built-in <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI">anyURI</xtermref> simple
type definition</pvpair>
        <pvpair ref="st-annotation"><termref def="key-null">absent</termref></pvpair>
       </pvlist>
      </pvpair>
      <pvpair ref="a-scope"><pt>global</pt></pvpair>
      <pvpair ref="a-value_constraint"><termref def="key-null">absent</termref></pvpair>
      <pvpair ref="a-annotation"><termref def="key-null">absent</termref></pvpair>
     </pvlist>
     </schemaComp>
     <schemaComp id="xsi.noNamespaceSchemaLocation">
     <head>Attribute Declaration for the 'noNamespaceSchemaLocation' attribute</head>
      <pvlist>
      <pvpair ref="a-name"><code>noNamespaceSchemaLocation</code></pvpair>
      <pvpair ref="a-target_namespace"><code>http://www.w3.org/2001/XMLSchema-instance</code></pvpair>
      <pvpair ref="type_definition">The built-in <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#anyURI">anyURI</xtermref> simple
type definition</pvpair>
      <pvpair ref="a-scope"><pt>global</pt></pvpair>
      <pvpair ref="a-value_constraint"><termref def="key-null">absent</termref></pvpair>
      <pvpair ref="a-annotation"><termref def="key-null">absent</termref></pvpair>
     </pvlist>
     </schemaComp>
    </div3>
   </div2>
   <div2 id="cElement_Declarations">
    <head>Element Declarations</head>
       <p>Element declarations provide for:</p>
    <ulist>
     <item><p>Local <termref def="key-vn">validation</termref> of element information item values using a type definition;</p></item>
     <item><p>Specifying default or fixed values for an element information items;</p></item>
     <item><p>Establishing uniquenesses and reference constraint relationships among the values of related elements and
attributes;</p>
</item>
     <item><p>Controlling the substitutability of elements through the
mechanism of <termref def="key-equivalenceClass">element substitution groups</termref>.</p>
     </item>
    </ulist>
    <note role="example">
     <eg xml:space="preserve">&lt;xs:element name="PurchaseOrder" type="PurchaseOrderType"/&gt;

&lt;xs:element name="gift"&gt;
 &lt;xs:complexType&gt;
  &lt;xs:sequence>
   &lt;xs:element name="birthday" type="xs:date"/&gt;
   &lt;xs:element ref="PurchaseOrder"/>
  &lt;/xs:sequence>
 &lt;/xs:complexType&gt;
&lt;/xs:element&gt;
</eg>
     <p>XML representations of several different types of element declaration</p>
    </note>
    <div3 id="Element_Declaration_details">
     <head>The Element Declaration Schema Component</head>
<p>The element declaration schema component has the following
properties:</p>

    <compdef name="Element Declaration" ref="Element_Declaration">
     <proplist>
      <propdef id="e-name" name="name">An NCName as defined by
<bibref ref="ref-xml-namespaces"/>.</propdef>
      <propdef id="e-target_namespace" name="target namespace">Either <termref def="key-null">absent</termref> or
a namespace name, as defined in <bibref ref="ref-xml-namespaces"/>.</propdef>
      <propdef id="type_definition" name="type definition">Either a simple type
definition or a complex type definition.</propdef>
      <propdef id="e-scope" name="scope">Optional.  Either <pt>global</pt> or a complex type
definition.</propdef>
      <propdef id="e-value_constraint" name="value constraint">Optional.  A
pair consisting of a value and one of <pt>default</pt>, <pt>fixed</pt>.</propdef>
      <propdef id="nillable" name="nillable">A boolean.</propdef>
      <propdef id="&constraint;_definitions" name="&constraint; definitions">A set
of constraint definitions.</propdef>
      <propdef id="class_exemplar" name="substitution group affiliation">Optional.  A top-level
element definition.</propdef>
      <propdef id="e-final" name="substitution group exclusions">A subset of
{<pt>extension</pt>,
<pt>restriction</pt>}.</propdef>
      <propdef id="e-exact" name="disallowed substitutions">A subset of {<pt>substitution</pt>, <pt>extension</pt>,
<pt>restriction</pt>}.</propdef>
      <propdef id="e-abstract" name="abstract">A boolean.</propdef>
      <propdef id="e-annotation" name="annotation">Optional.  An annotation.</propdef>
     </proplist>

    </compdef>
<p>The <propref ref="e-name"/> property must match the local part of the names
of element information items being <termref def="key-vn">validated</termref>.</p>
<p>A <propref ref="e-scope"/> of <pt>global</pt> identifies element declarations available for use in content
models throughout the schema.  Locally scoped declarations are available for use only within the
complex type identified by the <propref ref="e-scope"/> property.  This property is <termref def="key-null">absent</termref> in the case of  declarations within named model groups:  their scope is determined when they are used in the construction of complex type definitions.</p>
    <p>A non-<termref def="key-null">absent</termref> value of the <propref ref="e-target_namespace"/> property provides for <termref def="key-vn">validation</termref> of
namespace-qualified element information items.  <termref def="key-null">Absent</termref> values of
<propref ref="e-target_namespace"/> <termref def="key-vn">validate</termref> unqualified items.</p>
<p>An element information item is <termref def="key-vn">valid</termref>
if it satisfies the <propref ref="type_definition"/>.  For such an
item, schema information set contributions appropriate to the <propref ref="type_definition"/> are added to the
corresponding element information item in the &PSVI;.
</p>
<p>If <propref ref="nillable"/> is <pt>true</pt>, then an element may
also be <termref def="key-vn">valid</termref> if it
carries the namespace qualified attribute with <xpropref href="http://www.w3.org/TR/xml-infoset/#infoitem.attribute">local name</xpropref> <code>nil</code> from namespace <code>http://www.w3.org/2001/XMLSchema-instance</code> and value <code>true</code> (see <specref ref="xsi_nil"/>) even if it has
no text or element content despite a <propref ref="content_type"/> which would
otherwise require content. Formal details of element <termref def="key-vn">validation</termref> are described in <specref ref="cvc-elt"/>.</p>
<p><propref ref="e-value_constraint"/> establishes a default or fixed value for an element.  If <pt>default</pt> is specified, and if the element
being <termref def="key-vn">validated</termref> is empty, then the
canonical form of the supplied
constraint value becomes the <propref role="psvi" ref="e-schema_normalized_value"/> of the <termref def="key-vn">validated</termref> element in the &PSVI;.  If <pt>fixed</pt> is specified, then the element's content
must either be empty, in which case <pt>fixed</pt> behaves as <pt>default</pt>,
or its value must match the supplied constraint value.</p>
     <note>
      <p>The provision of defaults for elements goes beyond what is possible in
XML 1.0 DTDs, and does not exactly correspond to defaults for attributes.  In
particular, an element with a non-empty <propref ref="e-value_constraint"/> whose simple
type definition includes the empty string in its lexical space will
nonetheless never receive that value, because the <propref ref="e-value_constraint"/> will override it.</p>
     </note>
<p><propref ref="&constraint;_definitions"/> express constraints establishing uniquenesses and reference relationships among the values of related elements and
attributes.  See <specref ref="c&Constraint;_Definitions"/>.</p>
<p>Element declarations are <phrase diff="add">potential </phrase>members of the substitution group, if any, identified
by <propref ref="class_exemplar"/>.  <phrase diff="del">Membership</phrase><phrase diff="add">Potential membership</phrase> is transitive but not symmetric;  an element
declaration is a <phrase diff="add">potential </phrase>member of any group of which its <propref ref="class_exemplar"/> is a <phrase diff="add">potential </phrase>member.  <phrase diff="add">Actual membership may be blocked by the effects of <propref ref="e-final"/> or <propref ref="e-exact"/>, see below.</phrase></p>
<p>An empty <propref ref="e-final"/> allows a declaration to be nominated as
the <propref ref="class_exemplar"/> of other element declarations having the same <propref ref="type_definition"/> or
types derived therefrom.  The explicit
values of <propref ref="e-final"/> rule out element declarations having types which
are <pt>extension</pt>s or <pt>restriction</pt>s respectively of <propref ref="type_definition"/>.  If
both values are specified, then the declaration may not be nominated as the
<propref ref="class_exemplar"/> of any other declaration.</p>

<p>The supplied values for <propref ref="e-exact"/> determine
whether an element declaration appearing in a <termref def="key-contentModel">content model</termref> will be prevented from additionally
<termref def="key-vn">validating</termref> elements (a) with an <specref ref="xsi_type"/> that identifies an
<pt>extension</pt> or <pt>restriction</pt> of the type of the declared element, and/or (b) from <termref def="key-vn">validating</termref> elements which are in the
substitution group headed by the declared element.
If <propref ref="e-exact"/> is empty, then all derived types and substitution group members are allowed.</p>
<p>Element declarations for which <propref ref="e-abstract"/> is <pt>true</pt> can appear in
content models only when substitution is allowed;
such declarations may not themselves ever be used to <termref def="key-vn">validate</termref> element content.</p>
     <p>See <specref ref="cAnnotations"/> for information on the role of the
<propref ref="e-annotation"/> property.</p>
    </div3>
    <div3 id="declare-element">
<head>XML Representation of Element Declaration Schema Components</head>
<p>The XML representation for an element declaration schema component is an
<eltref ref="element"/> element information item.  It specifies a type
definition for an element either by reference or explicitly, and may provide
occurrence and default information.  The correspondences between the
properties of the information item and
properties of the component(s) it corresponds to are as follows:</p>
<reprdef>
 <reprelt eltname="element" type="element"/>
 <p>If the <eltref ref="element"/> element information item has <eltref ref="schema"/> as its parent, the corresponding schema component is as follows:</p>
 <reprcomp abstract="Element Declaration" ref="Element_Declaration_details">  
<propmap name="e-name">The &v-value; of the <code>name</code> &i-attribute;.</propmap>
  <propmap name="e-target_namespace">The &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <eltref ref="schema"/>
element information item, or <termref def="key-null">absent</termref> if there is none.</propmap>
 <propmap name="e-scope"><pt>global</pt>.</propmap>
  <propmap name="type_definition">The type definition
corresponding to the <eltref ref="simpleType"/> or <eltref ref="complexType"/> element information item in the
&i-children;, if either is present, otherwise the type definition <termref def="src-resolve">resolved</termref> to by
the &v-value; of the <code>type</code> &i-attribute;, otherwise the <propref ref="type_definition"/> of the element declaration <termref def="src-resolve">resolved</termref> to by the &v-value; of the <code>substitutionGroup</code> &i-attribute;, if present, otherwise the
<termref def="ur-type-itself">ur-type definition</termref>.</propmap>
  <propmap name="nillable">The &v-value; of the <code>nillable</code>
&i-attribute;, if present, otherwise <pt>false</pt>.</propmap>
  <propmap name="e-value_constraint">If there is a <code>default</code> or a <code>fixed</code>
&i-attribute;, then a pair consisting of the &v-value; (with respect to the
<propref ref="type_definition"/>, if it is a simple type definition, or the
<propref ref="type_definition"/>'s <propref ref="content_type"/>, if that is a
simple type definition, or else with respect to the built-in <xtermref href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string">string</xtermref> simple type definition) of that &i-attribute; and
either <pt>default</pt> or <pt>fixed</pt>, as appropriate, otherwise <termref def="key-null">absent</termref>.</propmap>
  <propmap name="&constraint;_definitions">A set consisting of the
&constraint;-definitions corresponding to all the <eltref ref="key"/>, <eltref ref="unique"/> and <eltref ref="keyref"/> element information items in the
&i-children;, if any, otherwise the empty set.</propmap>
  <propmap name="class_exemplar">The element declaration <termref def="src-resolve">resolved</termref> to by the
&v-value; of the
<code>substitutionGroup</code> &i-attribute;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
  <propmap name="e-exact">A set depending on the &v-value; of the
<code>block</code> &i-attribute;, if present, otherwise on the &v-value; of the
<code>blockDefault</code> &i-attribute; of the ancestor <eltref ref="schema"/> element
information item, if present, otherwise on the empty string.  Call this the <local>EBV</local> (for effective block value).  Then the value of this property is
 <olist role="caseval">
  <item>
   <p role="if">the <local>EBV</local> is the empty string</p>
   <p role="then">the empty set;</p>
  </item>
  <item>
   <p role="if">the <local>EBV</local> is <code>#all</code></p>
   <p role="then"><code>{</code><pt>extension</pt>, <pt>restriction</pt>, <pt>substitution</pt><code>}</code>;</p>
  </item>
  <item>
   <p role="otherwise">a set with members drawn from the set above, each being present or
absent depending on whether the &v-value; (which is a list) contains an
equivalently named item.
   <note>
       <p>Although the <code>blockDefault</code> &i-attribute; of <eltref ref="schema"/> may include values other than <pt>extension</pt>, <pt>restriction</pt> or <pt>substitution</pt>, those values are ignored in the determination of <propref ref="e-exact"/> for element declarations (they <emph>are</emph> used elsewhere).</p>
      </note>
   </p>
  </item>
 </olist>
  </propmap>
  <propmap name="e-final">As for <propref ref="e-exact"/> above, but using the
<code>final</code> and <code>finalDefault</code> &i-attributes; in place of the
<code>block</code> and <code>blockDefault</code>
&i-attributes; and with the
relevant set being <code>{</code><pt>extension</pt>, <pt>restriction</pt><code>}</code>.</propmap>
  <propmap name="e-abstract">The &v-value; of the <code>abstract</code>
&i-attribute;, if present, otherwise <pt>false</pt>.</propmap>
  <propmap name="e-annotation">The annotation corresponding to the <eltref ref="annotation"/> element information item in the
&i-children;, if present, otherwise <termref def="key-null">absent</termref>.</propmap>
</reprcomp>
 <p>otherwise if the <eltref ref="element"/> element information item has
<eltref ref="complexType"/> or <eltref ref="group"/> as an ancestor and the
<code>ref</code> &i-attribute; is absent, the corresponding schema components
are as follows (unless <code>minOccurs=maxOccurs=0</code>, in which case the item
corresponds to no component at all):</p>
 <reprcomp abstract="Particle" ref="Particle_details">
  <propmap name="p-min_occurs">The &v-value; of the <code>minOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
  <propmap name="p-max_occurs"><pt>unbounded</pt>, if the <code>maxOccurs</code>
&i-attribute; equals <pt>unbounded</pt>, otherwise the &v-value; of the <code>maxOccurs</code>
&i-attribute;, if present, otherwise <code>1</code>.</propmap>
  <propmap name="term">A (local) element declaration as given below.</propmap>
  
</reprcomp>
 <p> 
An element declaration as in the first case above, with the exception of its <propref ref="e-target_namespace"/> and <propref ref="e-scope"/> properties, which are as below:</p>
 <reprcomp abstract="Element Declaration" ref="Element_Declaration_details">
  <propmap name="e-target_namespace">If <code>form</code> is present and its
&v-value; is <code>qualified</code>, or if <code>form</code> is absent and the
&v-value; of <code>elementFormDefault</code> on the <eltref ref="schema"/>
ancestor is <code>qualified</code>, then the &v-value; of the
<code>targetNamespace</code> &i-attribute; of the parent <eltref ref="schema"/>
element information item, or <termref def="key-null">absent</termref> if there
is none, otherwise <termref def="key-null">absent</termref>.</propmap>
 <propmap name="e-scope">If the <eltref ref="element"/> element information item
has <eltref ref="complexType"/> as an ancestor, the complex definition
corresponding to that item, otherwise (the <eltref ref="element"/> element
information item is within a named <eltref ref="group"/> definition), <termref def="key-null">absent</termre