<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="xmlspec-ie-dm.xsl"?>
<!DOCTYPE spec SYSTEM "xmlspec.dtd" [
  <!ENTITY date.year "2002">
  <!ENTITY date.month "August">
  <!ENTITY date.MM "08">
  <!ENTITY date.day "16">
  <!ENTITY date.DD "16">
  <!ENTITY doc.date "&date.year;&date.MM;&date.DD;">
  <!ENTITY doc.prefix "WD-query-datamodel">
  <!ENTITY url.group "http://www.w3.org/XML/Group/">
  <!ENTITY url.group.ql "&url.group;xmlquery/">
  <!ENTITY url.publoc "&url.group;&date.year;/&date.MM;/&doc.prefix;-&doc.date;.html">
  <!ENTITY url.internal "http://www.w3.org/Style/XSL/Group/xpath2-tf/&doc.prefix;-&doc.date;.html">
  <!ENTITY url.external "http://www.w3.org/TR/&date.year;/&doc.prefix;-&doc.date;/">
  <!ENTITY url.this "&url.external;">
  <!ENTITY aacute "&#225;">
  
  <!ENTITY % local.loc.class      "|loc-content">
  <!ELEMENT loc-content (#PCDATA|abbr)*>
  <!ATTLIST loc-content
            href    CDATA             #IMPLIED>
  <!ELEMENT abbr (#PCDATA)>
  <!ATTLIST abbr
            lang    CDATA             #IMPLIED
            title    CDATA            #IMPLIED>

  <!ENTITY copy   "&#169;"> <!-- copyright sign, U+00A9 ISOnum -->
  <!ENTITY reg    "&#174;"> <!-- registered sign = registered trade mark sign,
                                  U+00AE ISOnum -->

  <!ATTLIST issue
            date     CDATA             #IMPLIED
            raisedby CDATA             #IMPLIED>
  <!ENTITY % local.p.class        "| description | suggestion">
  <!ATTLIST resolution
            date     CDATA             #IMPLIED>
  <!ELEMENT description (p | olist | eg)+>
  <!ATTLIST description         
            id       ID                #IMPLIED
            role     NMTOKEN           #IMPLIED>
  <!ELEMENT suggestion (p)+>
  <!ATTLIST suggestion
            id       ID                #IMPLIED
            role     NMTOKEN           #IMPLIED>
]>
<spec w3c-doctype="wd">

<header>
  <title>XQuery 1.0 and XPath 2.0 Data Model</title>
  <version/>
  <w3c-designation>&doc.prefix;-&doc.date;</w3c-designation>
  <w3c-doctype>W3C Working Draft</w3c-doctype>
  <pubdate>
    <day>&date.day;</day>
    <month>&date.month;</month>
    <year>&date.year;</year>
  </pubdate>
  <publoc>
     <loc href="&url.this;">&url.this;</loc>
  </publoc>
  <latestloc>
    <loc href="http://www.w3.org/TR/query-datamodel/">http://www.w3.org/TR/query-datamodel/</loc>
  </latestloc>
  <prevlocs role="private">
    <loc href="http://www.w3.org/TR/2002/WD-query-datamodel-20020430/">http://www.w3.org/TR/2002/WD-query-datamodel-20020430/</loc>
    <loc href="http://www.w3.org/TR/2001/WD-query-datamodel-20011220/">http://www.w3.org/TR/2001/WD-query-datamodel-20011220/</loc>
    <loc href="http://www.w3.org/TR/2001/WD-query-datamodel-20010607/">http://www.w3.org/TR/2001/WD-query-datamodel-20010607/</loc>
    <loc href="http://www.w3.org/TR/2001/WD-query-datamodel-20010215/">http://www.w3.org/TR/2001/WD-query-datamodel-20010215/</loc>
  </prevlocs>
  <authlist>
    <author>
      <name>Mary Fern&aacute;ndez (XML Query WG)</name>
      <affiliation>AT&amp;T Labs</affiliation>
      <email href="mailto:mff@research.att.com">mff@research.att.com</email>
    </author>
    <author>
      <name>Jonathan Marsh (XSL WG)</name>
      <affiliation>Microsoft</affiliation>
      <email href="mailto:jmarsh@microsoft.com">jmarsh@microsoft.com</email>
    </author>
    <author>
      <name>Marton Nagy (XML Query WG)</name>
      <affiliation>Science Applications International Corporation (SAIC)</affiliation>
      <email href="mailto:marton.nagy@saic.com">marton.nagy@saic.com</email>
    </author>
  </authlist>
  <altformats>
     <p>This document is also available in this non-normative format:
     <loc role="available-format" href="&url.this;Overview.xml">XML</loc>.</p>
  </altformats>
  <copyright>
    <p role="copyright">
    <loc href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</loc>
    &nbsp; &copy; 2002  
    <loc-content href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></loc-content>
    <sup>&reg;</sup>
    (<loc-content href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></loc-content>,
    <loc-content href="http://www.inria.fr/"><abbr lang="fr" title="Institut National de Recherche en Informatique et Automatique">INRIA</abbr></loc-content>, 
    <loc href="http://www.keio.ac.jp/">Keio</loc>), All Rights Reserved.
    W3C <loc href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</loc>,
    <loc href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</loc>,
    <loc href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document use</loc>
    and <loc href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software licensing</loc>
    rules apply.</p>
  </copyright>

  <status>
    <p>This section describes the status of this document at the time of its
    publication. Other documents may supersede this document. The latest status
    of this document series is maintained at the W3C.</p>

    <p>This is a Public Working Draft for review by W3C Members and 
    other interested parties. It is a draft document and may be updated, 
    replaced or made obsolete by other documents at any time. It is 
    inappropriate to use W3C Working Drafts as reference material or to 
    cite them as other than "work in progress". This is work in progress 
    and does not imply endorsement by the W3C membership.</p>

    <p>The most significant changes since the previous version are
    the following.
    The subsections on Nodes (4.1-4.7) have been reorganized to "sandbox" the
    mapping from the PSVI, i.e. make the definition of the accessors depend not
    on the PSVI properties, but on the arguments passed to the constructor.
    In particular the definition of the dm:typed-value() accessor has
    been updated and made more precise.
    We have defined the mapping from the data model to the XML Information Set
    in the sections 4.X.5. 
    The section on Errors and all references to the error value have been
    removed.
    The constructors dm:element-node-atomic and dm:attribute-node-atomic
    have been removed.
    </p>

    <p>The XQuery 1.0 and XPath 2.0 Data Model has been defined jointly by
	 the <loc href="http://www.w3.org/XML/Query">XML Query Working Group</loc>
	 (part of the <loc href="http://www.w3.org/XML/Activity.html">XML Activity</loc>) and
	 the <loc href="http://www.w3.org/Style/XSL/">XSL Working Group</loc>
	 (part of the <loc href="http://www.w3.org/Style/">Style Activity</loc>).
	 </p>

    <!--
    <p>This document has been produced as part of the
    <bibref ref="w3c-style-activity"/> and the <bibref ref="w3c-xml-activity"/>,
    following the procedures set out for the W3C Process. The document has 
    been written by the <bibref ref="XSLWG"/> and <bibref ref="XQWG"/>.</p>
	 -->

    <p>Comments on this document should be sent to the W3C mailing list <loc href="mailto:public-qt-comments@w3.org">public-qt-comments@w3.org</loc>.
    (archived at <loc href="http://lists.w3.org/Archives/Public/public-qt-comments/">http://lists.w3.org/Archives/Public/public-qt-comments/</loc>).
    </p>

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

    <p>
    Patent disclosures relevant to this specification may be found on the
    XML Query Working Group's patent disclosure page at 
    <loc href="http://www.w3.org/2002/08/xmlquery-IPR-statements">http://www.w3.org/2002/08/xmlquery-IPR-statements</loc>
    and the XSL Working Group's patent disclosure page at 
    <loc href="http://www.w3.org/Style/XSL/Disclosures.html">http://www.w3.org/Style/XSL/Disclosures.html</loc>.
    </p>
  </status>
  
  <abstract>
    <p>This document defines the W3C XQuery 1.0 and XPath 2.0 Data Model, which is the data model of at least <bibref ref="XSLT2"/>,
    and <bibref ref="XQuery"/>,
    and any other specifications that reference it.  This data model is based on the data models of <bibref ref="XPath"/> and
    <bibref ref="XQDM00"/> and replaces <bibref ref="XQDM00"/>.
    This document is the result of joint work by the
    <bibref ref="XSLWG"/> and the <bibref ref="XQWG"/>.</p>
  </abstract>
  
  <langusage>
    <language id="en">English</language>
  </langusage>

  <revisiondesc role="public">
    <ednote><edtext>Note that the Revision History section will not appear
    in the public version of this document.</edtext></ednote>

    <p>MN: 12-Aug-2002.
      <ulist>
        <item>
          <p>Updated the document to reflect decisions made and
          actions assigned during the 7/29-7/31 face-to-face meeting:
          Took care of the comments of Jonathan, Mary, Don and Michael Kay
          all of which were approved during the meeting.
          Added a patent disclosure paragraph in the Status section.
          </p>
        </item>
        <item>
          <p>Slightly updated the definition of atomic value.
          Added an issue addressing the misalignment of the data model
          and the F&amp;O related to the definition of typed-value() on
          Document, PI and Comment nodes.
          </p>
        </item>
        <item>
          <p>Added the issues <specref ref="Issue-0076"/>,
          <specref ref="Issue-0077"/>, <specref ref="Issue-0078"/>,
          <specref ref="Issue-0079"/> and <specref ref="Issue-0080"/>.
          </p>
        </item>
      </ulist>
    </p>
    <p>MN: 25-July-2002.
      <ulist>
        <item>
          <p>Reorganzied the subsections on Nodes (4.4-4.7)
          to "sandbox" the mapping from the PSVI, i.e. make the definition
          of the accessors depend not on the PSVI properties, but on the
          arguments passed to the constructor.
          </p>
        </item>
        <item>
          <p>Closed <specref ref="Issue-0036"/> and <specref ref="Issue-0073"/>.</p>
        </item>
      </ulist>
    </p>
    <p>MN: 22-July-2002.
      <ulist>
        <item>
          <p>Defined the mapping from the data model to the XML
          Information Set: Added an overview section to
          3.3 "XML Schemas and the XML Information Set" and added
          new subsections at the end of all the sections describing the
          various node kinds.
          </p>
        </item>
        <item>
          <p>Removed the section on Errors and all references to the error
          value. Closed the related issues <specref ref="Issue-0047"/> and
          <specref ref="Issue-0048"/>.</p>
        </item>
        <item>
          <p>Updated the document to reflect the adoption of "Alternative 1"
          related to element and attribute constructors: Removed the
          constructors dm:element-node-atomic and dm:attribute-node-atomic
          and updated the text referencing them.
          Closed the related issue <specref ref="Issue-0068"/>. Replaced
          section 3.6 "Text Nodes and Sequences of Atomic Values" with
          section 3.5 "Typed Value".
          </p>
        </item>
        <item>
          <p>Updated section 3.3 "XML Schemas and the XML Information Set"
          to mention that the data model supports well-formed document
          fragments, sequences of fragments or sequences of documents.</p>
        </item>
        <item>
          <p>Updated the document in response to public comments. Made several
          editorial changes (expanded-QName description, update of example,
          fixed the namespace names for xf and op prefixes, fixed typos).</p>
        </item>
        <item>
          <p>Added <specref ref="Issue-0075"/>.</p>
        </item>
        <item>
          <p>Closed <specref ref="Issue-0019"/> and 
          <specref ref="Issue-0041"/>.</p>
        </item>
      </ulist>
    </p>
    <p>MN: 20-April-2002.
      <ulist>
        <item>
          <p>Updated and slightly changed the example in the appendix. Also added some graphics.</p>
        </item>
        <item>
          <p>Updates based on WG comments:
          Reworded the explanations about values in section 1.
          Fixed some bugs in the definition of infoitem-to-type() in section
          3.5.
          Added a sentence on the representation of character data for
          attributes and updated the paragraph on implementation options
          in section 3.6.
          Added clarification on the identity of nodes contained in sequences
          in Section 6.
          Added dm: prefix for data model constructors and accessors.
          </p>
        </item>
        <item>
          <p>Editorial updates based on WG comments:
          Updated the bulleted list in the beginning of section 4.
          Updated the PSVI contribution in the XML Information Set
          Conformance Section.
          Added a note to the example in the appendix about our ongoing
          work on whitespace handling.
          </p>
        </item>
      </ulist>
    </p>
    <p>MN: 28-March-2002.
      <ulist>
        <item>
          <p>Added the issues <specref ref="Issue-0072"/>,
           <specref ref="Issue-0073"/> and <specref ref="Issue-0074"/>.
          </p>
        </item>
        <item>
          <p>Closed the issues
            <specref ref="Issue-0024"/>, 
            <specref ref="Issue-0054"/>.
          </p>
        </item>
        <item>
          <p>Updated the document according to the named typing proposal:
          Replaced section 3.4 Schema Components and Values with a section
          on Types.
          Rewrote section 8.1 Mapping PSV Infoset additions to Schema Components
          Moved that subsection to 3.5 and removed the rest of section 8.
          Updated the sections on element nodes, attribute nodes, and simple
          typed values (removed the declaration() accessor, changed type()
          to return xs:QName, replaced SchemaComponent with xs:QName).
          </p>
        </item>
        <item>
          <p>Added the functions <emph>node-equal</emph> and
          <emph>node-before</emph> to sections 3.1 and 3.2.</p>
        </item>
        <item>
          <p>Aligned the terminology with the other working drafts (value,
          atomic value, sequence, item, etc.) Updated the names of the
          element node, attribute node and atomic value constructors.
          Updated the section 5 on atomic values, removed the mention
          of primitive values and the constructor that takes primitive
          values.</p>
        </item>
        <item>
          <p>Aligned the notations with the other working drafts:
          Replaced the Sequence&lt;V&gt; notation with the occurrence
          indicators *,?,+. Updated the pseudo-code to use XQuery syntax
          and closed the corresponding issue <specref ref="Issue-0067"/>.
          </p>
        </item>
        <item>
          <p>Closed the following type-related issues:
            <specref ref="Issue-0009"/>,
            <specref ref="Issue-0011"/>,
            <specref ref="Issue-0022"/>,
            <specref ref="Issue-0026"/>,
            <specref ref="Issue-0031"/>,
            <specref ref="Issue-0049"/>,
            <specref ref="Issue-0056"/>,
            <specref ref="Issue-0064"/>,
            <specref ref="Issue-0066"/>.
          </p>
        </item>
        <item>
          <p>Updated the sections on element, attribute and text nodes
          to reflect the decisions regarding the behavior of the 
          typed-value (data()) function.
          See <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0382.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0382.html</loc> (member only).
          </p>
          <p>Updated the document to reflect the decisions regarding
          the resolution of Issue 17 in the Type Strawman. See
          <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0178.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0178.html</loc> (member only).
          In particular replaced xs:unknownSimpleType with xs:anySimpleType.
          </p>
        </item>

      </ulist>
    </p>
    <p>JM: 11-December-2001.
      <ulist>
        <item>
          <p>Fixed links, minor editorial issues, updated example section,
          reorganized appendices.</p>
        </item>
      </ulist>
    </p>
    <p>MN: 5-December-2001.
      <ulist>
        <item>
<p>Renamed some functions/operators to align with the F&amp;O
document: xf:concat, op:value-equals, op-item-at, op:concatenate.</p>
        </item>
        <item>
<p>Editorial: Slightly modified the definition of value categories in
Section 1 and added examples of values that can be represented by the
data model. Added a note on using elment constructors with heterogeneous
sequences in Section 4.2. Added a note to Sections 4.2 and 4.3 to
signal that we are actively working on the resolution of Issue-0036.
</p>
        </item>
        <item>
<p>Updated the section on simple typed values (formerly called simple
values). Clarified the terminology used. Got rid of the subsections
explaining Primitive Values and Derived Simple Values and merged
some of that content into the main section. Defined a second
constructor parallel to the two constructors of elements and
attributes and specified that the canonical lexical representation
is to be used when applying the string-value accessor.</p>
        </item>
        <item>
<p>Defined the canonical lexical representation for a sequence of
simple typed values. </p>
        </item>
        <item>
          <p>Closed the issues <specref ref="Issue-0027"/>,
          <specref ref="Issue-0046"/>, <specref ref="Issue-0065"/>,
          <specref ref="Issue-0055"/>.
          </p>
        </item>
        <item>
          <p>Added the issues <specref ref="Issue-0067"/>,
          <specref ref="Issue-0068"/>, <specref ref="Issue-0069"/>,
          <specref ref="Issue-0070"/>, <specref ref="Issue-0071"/>.
          </p>
        </item>
      </ulist>
    </p>
    <p>JM: 29-November-2001.
      <ulist>
        <item>
          <p>Added issue:
            <specref ref="Issue-0066"/>
          </p>
        </item>
      </ulist>
    </p>
    <p>JM: 19-November-2001.
      <ulist>
        <item>
          <p>Added issue:
            <specref ref="Issue-0065"/>
          </p>
        </item>
      </ulist>
    </p>
    <p>MN: 11-November-2001.
      <ulist>
        <item>
          <p>Continued updates relating to the treatment of common accessors.
          (In particular removed the prefix and namespace-uri accessors of a
          NamespaceNode.) Fixed sequence-accessor related inconsistencies
          between the data model and the Functions and Operators document:
          Updated the sequence sections and code samples to use the accessors
          defined in the F&amp;O document. Added references to sequence and
          QName accessor functions defined in the F&amp;O document.
          Modified the urls in the examples to use www.example.com.</p>
        </item>
        <item>
          <p>Closed issues:
            <specref ref="Issue-0053"/>
          </p>
        </item>
      </ulist>
    </p>
    <p>JM: 4-November-2001.
      <ulist>
        <item>
          <p>Closed issues:
            <specref ref="Issue-0005"/>, 
            <specref ref="Issue-0007"/>, 
            <specref ref="Issue-0043"/>
          </p>
        </item>
      </ulist>
    </p>
    <p>JM: 16-October-2001.
      <ulist>
        <item>
          <p>Added issues:
            <specref ref="Issue-0051"/>, 
            <specref ref="Issue-0052"/>, 
            <specref ref="Issue-0053"/>,
            <specref ref="Issue-0054"/>,
            <specref ref="Issue-0055"/>,
            <specref ref="Issue-0056"/>,
            <specref ref="Issue-0057"/>,
            <specref ref="Issue-0058"/>,
            <specref ref="Issue-0059"/>,
            <specref ref="Issue-0060"/>,
            <specref ref="Issue-0061"/>,
            <specref ref="Issue-0062"/>,
            <specref ref="Issue-0063"/>,
            <specref ref="Issue-0064"/>
          </p>
        </item>
      </ulist>
    </p>
    <p>JM: 17-August-2001.
      <ulist>
        <item>
          <p>Implemented editorial changes requested in
          <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Aug/0066.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Aug/0066.html</loc>
          and <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Aug/0099.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Aug/0099.html</loc>.</p>
        </item>
        <item>
          <p>Resolved issues:
            <specref ref="Issue-0001"/>, 
            <specref ref="Issue-0003"/>, 
            <specref ref="Issue-0015"/>, 
            <specref ref="Issue-0018"/>, 
            <specref ref="Issue-0020"/>, 
            <specref ref="Issue-0021"/>
          </p>
        </item>
        <item>
          <p>Added issues:
            <specref ref="Issue-0033"/>, 
            <specref ref="Issue-0034"/>, 
            <specref ref="Issue-0035"/>, 
            <specref ref="Issue-0036"/>, 
            <specref ref="Issue-0037"/>, 
            <specref ref="Issue-0038"/>, 
            <specref ref="Issue-0039"/>, 
            <specref ref="Issue-0040"/>, 
            <specref ref="Issue-0041"/>, 
            <specref ref="Issue-0042"/>, 
            <specref ref="Issue-0043"/>, 
            <specref ref="Issue-0044"/>, 
            <specref ref="Issue-0045"/>, 
            <specref ref="Issue-0046"/>, 
            <specref ref="Issue-0047"/>, 
            <specref ref="Issue-0048"/>, 
            <specref ref="Issue-0049"/>, 
            <specref ref="Issue-0050"/>
          </p>
        </item>
      </ulist>
    </p>
    
    <p>JM: 25-May-2001.
      <ulist>
        <item>
          <p>Updated stylesheet to derive from common xmlspec.xsl.</p>
        </item>
        <item>
          <p>Removed dependency on xmlquery-algebra.dtd, now extends xmlspec.dtd
          via internal subset.</p>
        </item>
        <item>
          <p>Added copyright to XML source.</p>
        </item>
        <item>
          <p>Removed mention of XPointer in the abstract.</p>
        </item>
      </ulist>
    </p>

    <p>MF: 17-May-2001.
    Per F2F discussion, tentative title 'XQuery 1.0 and XPath 2.0 Data Model'.
    Added <specref ref="Issue-0031"/>, <specref ref="Issue-0032"/>.</p>
    
    <p>MF: 02-May-2001.
      <ulist>
        <item>
          <p>Added a section on Text Nodes and Simple Typed values
          to explain relationship between them.  See also 
          <specref ref="Issue-0027"/>.</p>
        </item>
        <item>
          <p>Added <specref ref="flags"/>.</p>
        </item>
        <item>
          <p>Added bounded Sequences as suggested by Michael Kay in 
          <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0316.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0316.html</loc>
          to model partial functions.</p>
        </item>
      </ulist>
    </p>
    
    <p>JM and MF: 27-Apr-2001.  
      <ulist>
        <item>
          <p>Integrated relationship of data model to Information Set 
          into subsections.</p>
        </item>
        <item>
          <p>Distributed pseudo-code of Infoset mapping in subsections.</p>
        </item>
        <item>
          <p>Addressed Mike Kay's issues in 
          <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0222.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0222.html</loc></p>
        </item>
        <item>
          <p>Added 'schema component' values that correspond to 
          components in <bibref ref="XSFD"/> as suggested by James 
          Clark in <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0234.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0234.html</loc>. 
          Currently, schema components are values, not nodes. See 
          <specref ref="Issue-0026"/>.</p>
        </item>
        <item>
          <p>Resolved issues <specref ref="Issue-0006"/>, 
          <specref ref="Issue-0013"/>, <specref ref="Issue-0014"/>, 
          <specref ref="Issue-0016"/>, <specref ref="Issue-0017"/>.
          Added issues <specref ref="Issue-0025"/>, 
          <specref ref="Issue-0026"/>.</p>
        </item>
      </ulist>
    </p>
 
    <p>MF: 27-Mar-2001.
    Major revision based on <bibref ref="XQDM00"/>.  Major changes 
    are detailed in:
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Mar/0350.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Mar/0350.html</loc>. 
    They include:
      <ulist>
        <item>
          <p><emph>Terminology</emph>.   'Sequence' replaces 'ordered forest'.
          All node constructors have complete names, e.g., 
          'AttributeNode' replaces 'AttrNode', 'ProcessingInstructionNode' 
          replaces 'PINode', etc.</p>
        </item>
        <item>
          <p><emph>Notation</emph>.  'Sequence&lt;ElementNode&gt;' replaces 
          '[ ElementNode ]'.  The XPath 2.0 task force agreed this 
          notation for collections would be more familiar to 
          programmers.</p>
        </item>
        <item>
          <p><emph>Conceptual</emph>. TextNodes replace ValueNodes. A primary 
          requirement of XSLT is to have access to the original 
          lexical representation of the XML document, including the 
          children of elements that are text nodes.  To support this 
          requirement, TextNodes have been added to the data model. 
          </p>
          <p>ValueNodes have been eliminated.  Access to the Schema 
          simple-typed values of an element or attribute are provided 
          by the typed-value() accessor (See <specref ref="ElementNode"/>).
          The typed value of an element or attribute is derived from 
          the Schema normalized value in the PSV Infoset.</p>
          <p>This change guarantees access to the original lexical 
          form of the document.  It is not always possible to compute 
          the original lexical form from a typed simple value, but it 
          is always possible to compute the simple value from the 
          lexical form provided in the Schema normalized value in the 
          PSV Infoset.</p>
          <p>This introduces some awkwardness into the formal 
          semantics of XQuery, because when constructing a new element,  
          every simple value is (logically) converted into a text node.  
          For example, the XQuery value:</p>
          <p role="definition">&lt;a&gt;{ [1, 2] }&lt;/a&gt;</p>
          <p>is constructed by the data model expression:</p>
          <p role="definition">elementNode(qname(empty_sequence(), "a"), 
            empty_sequence(), empty_sequence(),
            text-node("1 2"))</p>
          <p>Applying typed_value() to the expression above yields:</p>
          <p role="definition">Sequence&lt; simpleValue(1, xs:integer), 
          simpleValue(2, xs:integer) &gt;</p>
        </item>
        <item>
          <p><emph>Conceptual</emph>: separating element construction from 'schema 
          processing'.  Currently, the elementNode constructor takes 
          both the content of the element and the runtime 
          representation of the element's type, called a 
          <emph>SchemaComponent</emph> James suggested separating 
          element construction from 'schema processing', i.e., 
          associating a runtime type with the constructed element.  
          Jerome says this better reflects what happens in an 
          implementation.</p>
          <p>Note that this is a conceptual data model only: this 
          model makes text nodes 'first class', but an implementation 
          could choose to make simple values 'first class' and 
          reconstruct text nodes on demand. This data model eliminates 
          many of the problems with the XML Query data model: 
          providing access to the original lexical form; handling 
          comments and PIs interleaved with simple values.  Overall, it 
          seems to strike a reasonable compromise of the needs of XSLT 
          and XQuery.</p>
        </item>
      </ulist>
    </p>
  </revisiondesc>
</header>

<body>

<div1>
  <head>Introduction</head>

  <p>This document defines the XQuery 1.0 and XPath 2.0 Data Model, 
  which is the data model of <bibref ref="XSLT2"/> and 
  <bibref ref="XQuery"/> 1.0.</p>

  <p>The XQuery 1.0 and XPath 2.0 Data Model (henceforth "data model") 
  serves two purposes.
  First, it defines precisely the information contained in the input to an 
  XSLT or XQuery processor.  Second, it defines all permissible values of 
  expressions in the XSLT, XQuery, and XPath languages.  A 
  language is <emph>closed</emph> with respect to a data model if the value 
  of every expression in a language is guaranteed to be in the data model. 
  XSLT 2.0, XQuery 1.0, and XPath 2.0 are all closed with respect to
  the data model.</p>
  
  <p>The data model is based on the <bibref ref="xml-infoset"/>
  (henceforth "Infoset"), but it requires the following new features to
  meet the <bibref ref="XPathReq"/> and <bibref ref="XQueryReq"/>:</p>
  
  <ulist>
    <item>
      <p>Support for XML Schema types. The XML Schema recommendations 
      define features, such as structures (<bibref ref="xmlschema-1"/>)
      and simple data types (<bibref ref="xmlschema-2"/>), that extend  
      the XML Information Set with precise type information.</p>
    </item>
    <item>
      <p>Representation of collections of documents and of 
      complex values. (<bibref ref="XQueryReq"/>)</p>
    </item>
  </ulist>

  <p>As with the Infoset, the XQuery 1.0 and XPath 2.0 Data Model 
  specifies what 
  information in the documents is accessible, but it does not specify
  the programming-language interfaces or bindings used to represent or 
  access the data.</p>

  <p>Every value handled by the data model is a <emph>sequence</emph> of
  zero or more <emph>item</emph>s. An <emph>item</emph> is either a
  <emph>node</emph> or an <emph>atomic value</emph>.

  A node is defined in <specref ref="Node"/> and is one of seven node kinds.
  An atomic value encapsulates an XML Schema atomic type
  and a corresponding value of that type. They are defined in
  <specref ref="AtomicValue"/>.
  A sequence is an ordered collection of nodes, atomic values, or any 
  mixture of nodes and atomic values.  A sequence cannot be a member of 
  a sequence.  A single item appearing on its own is modeled as a sequence
  containing one item.  Sequences are defined in <specref ref="sequences"/>.
  </p>
  
  <note>
    <p>In XPath 1.0, the data model only
    defines nodes.  The primitive data types (number, boolean, string,
    node-set) are part of the expression language, not 
    the data model.</p>
  </note>

  <p>The data model can represent various
  values including not only the input and the output of a query, but all
  values of expressions used during the intermediate calculations.
  Examples include the input document or document repository (represented
  as a document node or a sequence of document nodes), the result of a
  path expression (represented as a sequence of nodes), the result of an
  arithmetic or a logical expression (represented as an atomic value),
  a sequence expression resulting a sequence of integers, dates, QNames or
  other XML Schema atomic types (represented as a sequence of
  atomic values), etc.
  Examples of values that cannot be expressed directly by the data model
  include schema components, atomic values whose type
  is not an XML Schema atomic type, etc.
  </p>

  <p>In this document, we provide a precise definition of how values in the 
  XQuery 1.0 and XPath 2.0 Data Model are constructed and accessed, and how
  they relate to values in the Infoset.  We note wherever the XQuery 1.0 and 
  XPath 2.0 Data Model differs from that of XPath 1.0.</p>
  
</div1>

<div1>
  <head>Notation and Pseudo-code Syntax</head>

  <p>In addition to using prose, we define the data model using a functional 
  notation.  We chose this notation because it is simple and permits a 
  precise definition of the data model, suitable for use by the formal
  semantics of XQuery.  Although the notation has a functional style, we 
  emphasize that the data model can be realized in a variety of 
  programming languages and styles, for example, as object classes and 
  methods in an object-oriented language.</p>

  <p>Pseudo-code syntax is highlighted as follows:</p>

  <p role="definition">function dm:typed-value(<loc href="#Node">Node</loc> $n) returns <loc href="#AtomicValue">AtomicValue</loc>*</p>

  <p>In the psuedo-code syntax, the term <emph>Node</emph> denotes
  the category of node values, <emph>AtomicValue</emph> denotes the 
  category of atomic values, and <emph>Item</emph> refers to the
  category of either node values or atomic values.
  <emph>V*</emph> denotes the category of sequence 
  values all of whose members are in category <emph>V</emph>.
  <emph>V?</emph> and <emph>V+</emph> denote subcategories of
  <emph>V*</emph>: The former denotes the category of sequences
  containing zero or one items, the latter refers to sequences
  containing one or more items.
  In a sequence, <emph>V</emph> may be a <emph>Node</emph> or 
  <emph>AtomicValue</emph>, or the union (choice) of several categories of 
  <emph>Items</emph>. For example, the following denotes a category of 
  sequence containing any combination of comment and processing instruction 
  nodes:</p>
  
  <p role="definition">(<loc href="#CommentNode">CommentNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>)*</p>
  
  <p>There are some functions in the data model that are <emph>partial
  functions</emph>. We use the occurrence indicators <emph>?</emph> or
  <emph>*</emph> when specifying the return type of such functions.
  For example, a node may have one parent node or no parent.
  If the node argument has a parent, the 
  <emph>dm:parent</emph> accessor returns a singleton sequence.  If the node
  argument does not have a parent, it returns the empty sequence.
  The signature of <emph>dm:parent</emph> specifies that it returns
  an empty sequence or a sequence containing one element or document node:</p>

  <p role="definition">function dm:parent(<loc href="#Node">Node</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?</p>

  <p>The pseudo-code syntax defines functions to construct values, 
  called <emph>constructors</emph>; and functions to access parts of 
  values, called <emph>accessors</emph> (see <specref ref="Issue-0033"/>).
  The constructors and accessors defined by the data model are prefixed
  with <emph>dm</emph></p>
  
<!-- JM- commented out since there aren't actually any constraint expressions!

  We use <emph>constraint expressions</emph> to specify precisely the
  relationships between a constructed value and the values returned by
  its accessors.  For example, this constraint states that 
  the value returned by an element node's <emph>dm:name</emph> accessor
  is always equal to the name argument of the <emph>infoitem-to-element-node</emph> constructor.
  </p>
  <p role="definition">dm:name(infoitem-to-element-node(q, n, a, c, sc)) = q</p>
  <p>This constraint is obvious : we would like an element's name to be
  the same as the one it was constructed to have. 
  Some constraints, however, are not obvious.  For example,
  the order of an element node's attributes 
  do not have to be preserved by its constructor.
  Constraint expressions follow the definitions of constructors and
  accessors.</p>
-->

  <note><p>The XPath 1.0 data model defines accessors, but does not
  define constructors.</p></note>

  <p>The term <emph>signature</emph> of a function specifies the 
  type of its zero or more inputs and the type of its one 
  output. The following signature denotes a function <emph>f</emph> that 
  takes values in the categories <emph>V</emph><sub>1</sub>, ..., 
  <emph>V</emph><sub>m</sub> and returns an output value in the category 
  <emph>V</emph><sub>n</sub>.</p>

  <p role="aside">function f(<emph>V</emph><sub>1</sub> $v<sub>1</sub>, ..., <emph>V</emph><sub>m</sub> $v<sub>m</sub>) returns <emph>V</emph><sub>n</sub></p>

  <p>A member of a particular category is a permissible argument to any 
  function that accepts the category, for example, a 
  <emph>ProcessingInstructionNode</emph> is a permissible argument to a
  function expecting a <emph>Node</emph>.</p>

  <p>This document relies on the <bibref ref="xml-infoset"/>. Information items 
  and properties are indicated by the styles <emph role="info-item">information 
  item</emph> and <emph role="infoset-property">property</emph>, respectively.</p>

  <p>This document also provides pseudo-code syntax describing the mapping
  from the Infoset to the data model.  To facilitate this we introduce accessors
  to the required infoset properties through <emph>InfoItem</emph> objects.
  These infoset accessors are for rhetorical purposes only and are not intended to be exposed outside this
  specification.  We name the accessors of the Infoset using the convention 
  infoset-&lt;<emph>item-name</emph>&gt;-&lt;<emph>property-name</emph>&gt;.  
  Similarly, accessor functions that return PSV Infoset properties use the 
  naming convention psvi-&lt;<emph>item-name</emph>&gt;-&lt;<emph>property-name</emph>&gt;.
  For example, <code>infoset-element-attributes</code> is the accessor that 
  returns an element information item's <emph role="infoset-property">attributes</emph> 
  property:</p>

  <p role="definition">function infoset-element-attributes(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#AttributeItem">AttributeItem</loc>*</p>

  <p>An <emph>InfoItem</emph> is one of eleven kinds of item: document 
  item, element item, attribute item, processing instruction item, 
  unexpanded entity item, character item, comment item, document type declaration item, 
  unparsed entity item, notation item, and namespace item.</p>

  <p>The <emph>infoitem-kind</emph> accessor
  returns a string value representing the information item's kind, either 
  <code>"document"</code>, <code>"element"</code>, <code>"attribute"</code>, 
  <code>"character"</code>, <code>"namespace"</code>, 
  <code>"processing-instruction"</code>, <code>"comment"</code>,
  <code>"document-type-declaration"</code>,
  <code>"notation"</code>, or <code>"unparsed-entity"</code>.</p>

  <p role="definition" id="InfoItem">function infoitem-kind(InfoItem $ii) returns <loc href="#dt-atomic-value">xs:string</loc></p> 

  <p>Throughout this document, the namespace prefix <code>xs</code> indicates
  the <bibref ref="xmlschema-1"/> namespace name 
  <code>http://www.w3.org/2001/XMLSchema</code>.
  The namespace prefixes <code>xf</code> and <code>op</code> indicate
  the namespace of the functions and operators defined in
  Section 1.5 "Namespace Prefix" of <bibref ref="XFO"/>.</p>
  
  <p>The following is a list of some functions and operators that are used
  in this document but precisely defined in <bibref ref="XFO"/>:</p>

  <ulist>
    <item><p id="op_concatenate">op:concatenate</p></item>
    <item><p id="op_item-at">op:item-at</p></item>
    <item><p id="op_value-equal">op:value-equal</p></item>
    <item><p id="xf_anyURI">xf:anyURI</p></item>
    <item><p id="xf_concat">xf:concat</p></item>
    <item><p id="xf_count">xf:count</p></item>
    <item><p id="xf_decimal">xf:decimal</p></item>
    <item><p id="xf_empty">xf:empty</p></item>
    <item><p id="xf_get-local-name">xf:get-local-name</p></item>
    <item><p id="xf_get-namespace-uri">xf:get-namespace-uri</p></item>
    <item><p id="xf_NCName">xf:NCName</p></item>
    <item><p id="xf_QName">xf:QName</p></item>
    <item><p id="xf_QName-from-uri">xf:QName-from-uri</p></item>
    <item><p id="xf_QName-from-string">xf:QName-from-string</p></item>
    <item><p id="xf_string">xf:string</p></item>
    <item><p id="xf_subsequence">xf:subsequence</p></item>
  </ulist>

  <p>This document frequently uses the term <emph>expanded-QName</emph>.
  An expanded-QName is a pair of values consisting of a namespace URI and
  a local name. They belong to the value space of the XML Schema type
  xs:QName. When this document refers to xs:QName we always
  mean the value space, i.e. a namespace URI, local name pair (and not
  the lexical space referring to constructs of the form prefix:local-name).
  </p>

</div1>

<div1>
  <head>Concepts</head>
  <div2>
    <head>Node Identity</head>

    <p>Because XML documents are tree-structured, we define the 
    data model using conventional terminology for trees.  The data model is 
    a node-labeled, tree-constructor representation, but also includes a 
    concept of node identity.  The identity of a node is established 
    when a node-constructor is applied to create the node: each 
    application of a node constructor creates a new node that is 
    identical to itself, and not identical to any other node
    (see <specref ref="Node"/>).</p>
    
    <p>The <emph>dm:node-equal</emph> function takes two nodes as arguments.
    It returns true if the arguments are identical and false otherwise.
    </p>

    <p role="definition">
function dm:node-equal(<loc href="#Node">Node</loc> $n1, <loc href="#Node">Node</loc> $n2)
         returns <loc href="#dt-atomic-value">xs:boolean</loc>
    </p>
    
    <p>This concept should not be confused with the concept of
    <emph>unique ID</emph>, which is a unique name assigned to an
    element by the author to represent references using ID/IDREF
    correlation.</p>
  </div2>
  
  <div2>
    <head>Document Order</head>
      
    <p>A <emph>document order</emph> is defined on all the nodes in a 
    document.  The document node is the first node.  Element nodes, 
    comment nodes, and processing instruction nodes occur in the 
    order of their representation in the XML (after expansion of 
    entities).  Element nodes occur before their children.  The 
    namespace nodes of an element immediately follow the element node
    (see <specref ref="Issue-0051"/>).
    The relative order of namespace nodes is implementation-dependent. 
    The attribute nodes of an element immediately follow the 
    namespace nodes of the element. The relative order of attribute 
    nodes is implementation-dependent. Reverse document order is the 
    reverse of document order.</p>

    <p>The relative order of nodes in distinct documents is 
    implementation-dependent but stable.  In other words, given 
    two distinct documents A and B, if a node in document A is 
    before a node in document B, then every node in document A 
    is before every node in document B.</p>

    <note><p>The relative order of free-floating nodes (those not in
    a document) is not defined.  See <specref ref="Issue-0050"/>.</p></note>

    <p>The <emph>dm:node-before</emph> function takes two nodes as arguments.
    It returns true if the first argument is before (but not identical
    to) the second one in document order and false otherwise
    </p>

    <p role="definition">
function dm:node-before(<loc href="#Node">Node</loc> $n1, <loc href="#Node">Node</loc> $n2)
         returns <loc href="#dt-atomic-value">xs:boolean</loc>
    </p>
    
  </div2>
  
  <div2 id="psv">
    <head>XML Schemas and the XML Information Set</head>

    <p>The data model is defined in terms of the 
    <bibref ref="xml-infoset"/> after XML Schema validity assessment.
    XML Schema validity assessment is the process of assessing an XML
    element information item with respect to an XML Schema and
    augmenting it and some or all of its descendants with properties
    that provide information about validity and type assignment.
    The result of schema validity assessment is an augmented
    Infoset, known as the Post Schema-Validation Infoset, or
    PSVI.  
    </p>

    <p>The data model supports the following classes of XML documents:</p>

    <ulist>
      <item>
        <p>Schema-validated documents, i.e., those validated with respect 
        to a schema,</p>
      </item>
      <item>
        <p>DTD-valid documents, i.e., those documents validated with respect 
        to a DTD, and </p>
      </item>
      <item>
        <p>Well-formed documents with no corresponding DTD or schema.</p>
      </item>
    </ulist>

    <p>
    The data model does not support non-well-formed documents and documents
    that don't conform to XML Namespaces. These are not supported by the
    XML Information Set. On the other hand the data model does support
    some kinds of values that are not supported by the XML Information Set.
    Examples of these are well-formed document fragments, sequences of
    fragments or sequences of documents. The data model also
    supports values that are not nodes. Examples of these are atomic
    values, sequences of atomic values, or sequences mixing nodes and
    atomic values. These are necessary to be able to represent the results
    of intermediate expressions in the data model during expression
    processing.
    </p>
    
    <p>Schema-validated documents include documents in which some elements 
    or attributes have been validated by "lax" or "skip" validation 
    (<bibref ref="xmlschema-2"/>).</p>
    
    <p>An "incompletely validated document" is an XML document that has a
    corresponding schema but whose schema-validity assessment has resulted 
    in one or more element or attribute information items being assigned 
    values other than 'valid' for the <emph role="infoset-property">validity</emph>
    property in the PSVI.</p>

    <p>The data model supports incompletely validated documents.
    See <specref ref="Issue-0024"/>.</p>

    <note><p>This implies accommodation for the case where 
    both a DTD and a schema are applied.  This will probably require some
    reconciliation of the [attribute type] property with type 
    information from the PSVI.  See issue <specref ref="Issue-0004"/>.
    </p></note>

    <p>In addition to specifying the transformation from the Post Schema
    Validation Infoset (PSVI) to the data model this document also specifies
    the transformation from the data model back to the XML Information Set.
    This is a useful notion that can be used for defining serialization and
    validation.
    Serialization can be viewed as a two step process, first transforming
    to the XML Infoset and then to an XML document.
    Validation is described conceptually as a process of mapping the data
    model to the XML Infoset followed by XML Schema validation producing
    a PSVI which is then loaded into the data model.
    The mapping from the data model to the Infoset is specified
    via the function
    </p>
    <p role="definition">
function dm:node-to-infoitem(<loc href="#Node">Node</loc> $n) returns <loc href="#InfoItem">InfoItem</loc>
    </p>
    <p>
    The function takes a data model Node as an argument and returns
    an Information Item. We define this for each data model node type
    in the appropriate section below. The returned InfoItem will be
    specified by having its type identified and its properties described.
    The definition of <emph>dm:node-to-infoitem()</emph> will be recursive.
    Furthermore we will find it convenient to use a second function
    <emph>dm:nodes-to-infoitems()</emph> which takes a sequence of data
    model Nodes and returns a sequence of InfoItems by applying 
    <emph>dm:node-to-infoitem()</emph> on each member of the sequence of
    Nodes in turn and creating a sequence of the resulting InfoItems.
    </p>
    <p role="definition">
define function dm:nodes-to-infoitems(<loc href="#Node">Node</loc>* $seq)
                returns <loc href="#InfoItem">InfoItem</loc>*
{
  for $node in $seq return dm:node-to-infoitem($node)
}
</p>

    <ednote><edtext>
    There is an open issue about how to map namespaces declared globally
    in the query prolog during the data model to infoset transformation.
    </edtext></ednote>

  </div2>
  
  <div2 id="types">
    <head>Types</head>
    <p>
    The data model supports a representation of named types as
    expanded-QNames.
    An expanded-QName is a pair consisting of a namespace URI and a local name.
    Named types include both the built-in types defined by XML Schema
    Part 2 and types declared in a schema and imported by a query.
    Since named types in XML Schema are global, an expanded-QName
    uniquely identifies such a type, be it simple or complex:
    The namespace of the expanded-QName is the target namespace
    of the schema and its local name is the name of the type.

    The data model does not uniquely identify anonymous types and
    represents them by xs:anyType or xs:anySimpleType. 
    </p>

    <p>
    The data model associates type information with element nodes,
    attribute nodes and atomic values. If this type information
    is something other than xs:anyType or xs:anySimpleType, the item is
    guaranteed to be a valid instance of that type as defined by XML Schema.

    The data model defines an accessor <emph>dm:type()</emph> that returns
    an expanded-QName corresponding to the type of the element node,
    attribute node or atomic value, provided that the type is globally
    declared. It returns xs:anyType or xs:anySimpleType if it is
    locally declared or if no type information exists.
    When no type information exists for an element or an attribute node
    we frequently use the terminology "element with unknown type"
    or "attribute with unknown simple type".
    </p>

    <p>
    The data model does not represent element or attribute declaration
    schema components, but it supports various type-related operations.
    The semantics of such operations, e.g. checking if a particular 
    instance of an element node has a given type is defined in
    <bibref ref="XQFS"/>.
    </p>
  </div2>

  <div2 id="typed-value">
    <head>Typed Value and String Value</head>
    <p>
    The content of a text, attribute, or element node can be interpreted
    in either of two ways: as a string value or as a typed value.
    For these types of nodes, the typed value can be extracted by the
    <emph>dm:typed-value</emph> accessor, and the string value can be
    extracted by the <emph>dm:string-value</emph> accessor.
    The typed value of a node is a sequence of atomic values, and the
    string value of a node is a string. The typed value of a node is
    derived from its string value and its type in a way that is
    consistent with schema validation, as described in the definitions
    of the accessor functions for each kind of node.
   </p>
  </div2>

  <div2 id="PSVI2Types">
    <head>Mapping PSV Infoset additions to Types</head>
  
    <p>This section specifies how the type of an element 
    or attribute node is computed from the PSV Infoset additions 
    that specify validity and type assessment for the node's corresponding 
    information item.</p>
  
    <ednote><edtext>
    The rules specifying the computation of the types from the PSVI do not
    yet reflect that this process depends on the conformance level of the
    processor.
    See <specref ref="Issue-0077"/>.
    </edtext></ednote>

    <p>A PSV element (attribute) information item has a 
    <emph role="infoset-property">validity</emph> and a
    <emph role="infoset-property">type definition</emph> property.
    The <emph role="infoset-property">validity</emph> property may be
    <emph>"valid"</emph>, <emph>"invalid"</emph>, or <emph>"notKnown"</emph>
    and reflects the outcome of the element's (attribute's)
    schema-validity assessment.
    The <emph role="infoset-property">type definition</emph>
    property contains an element information item that is
    isomorphic to the XML Schema type definition of the 
    element or attribute information item.
    Roughly speaking these two properties are used to compute the
    type of an element or attribute in the data model, which
    corresponds to the {target namespace} and the {name}
    of the <emph role="infoset-property">type definition</emph>
    property if <emph role="infoset-property">validity</emph> is 
    <emph>"valid"</emph>, or to xs:anyType (xs:anySimpleType) otherwise.
    Notice that the only information that can be inferred from an
    invalid or not known validity value is that the information
    item is well-formed, therefore, we must associate some general
    type information with the element or attribute node.
    </p>
  
    <p>
    The precise definition of the type of an element or attribute
    information item is slightly more complex due to the following
    factors.
    First, XML Schema only guarantees the existence of either the
    <emph role="infoset-property">type definition</emph> property,
    or the 
    <emph role="infoset-property">type definition namespace</emph>,
    <emph role="infoset-property">type definition name</emph> and
    <emph role="infoset-property">type definition anonymous</emph>
    properties.
    Second, if the type definition refers to a union type, there
    are further properties defined, that refer to the type definition
    which actually validated the element item's normalized value.
    These properties are either the
    <emph role="infoset-property">member type definition</emph>,
    or the 
    <emph role="infoset-property">member type definition namespace</emph>,
    <emph role="infoset-property">member type definition name</emph> and
    <emph role="infoset-property">member type definition anonymous</emph>
    properties.
    If these are available the type of an element or attribute will
    refer to the member type that actually validated the schema
    normalized value.
    Having identified all the relevant properties we can now define
    how to compute a type.
    </p>
  
    <p>
    The <emph>type</emph> of an element information item is
    represented by an expanded-QName whose namespace and local name corresponds
    to the first applicable item in the following list:
    </p>
    <ulist>
    <item><p>
    xs:anyType if the <emph role="infoset-property">validity</emph>
    property is <emph>"invalid"</emph> or <emph>"notKnown"</emph>, or
    </p></item>
    <item><p>
    the {target namespace} and {name} properties of the
    <emph role="infoset-property">member type definition</emph>
    schema component if that exists, or
    </p></item>
    <item><p>
    the {target namespace} and {name} properties of the
    <emph role="infoset-property">type definition</emph>
    schema component if that exists, or
    </p></item>
    <item><p>
    the <emph role="infoset-property">member type definition namespace</emph>
    and the <emph role="infoset-property">member type definition name</emph>
    if <emph role="infoset-property">member type definition anonymous</emph>
    exists and is false, or
    </p></item>
    <item><p>
    the <emph role="infoset-property">type definition namespace</emph>
    and the <emph role="infoset-property">type definition name</emph>
    if <emph role="infoset-property">type definition anonymous</emph>
    exists and is false, or
    </p></item>
    <item><p>
    it corresponds to xs:anyType.
    </p></item>
    </ulist>

    <ednote><edtext>
    The last bullet of the above definition is currently under discussion.
    It is very likely that a change will be made in a future draft to
    reflect a more precise definition covering derived types and the
    possible usage of generated type identifiers when no type names
    available. See <specref ref="Issue-0076"/>.
    </edtext></ednote>

    <p>The <emph>type</emph> of an attribute information item is
    represented by an expanded-QName. Its definition is the same as for
    element information items except for using xs:anySimpleType
    instead of xs:anyType above.</p>

    <p>We will find it convenient to define the following function
    that will be used later in various sections.
    The <emph>infoitem-to-type</emph> function takes an element or
    an attribute information item and returns an xs:QName that
    corresponds to the type of its argument. </p>
  
    <p id="infoitem-to-type" role="definition">
function infoitem-to-type((<loc href="#ElementItem">ElementItem</loc>|<loc href="#AttributeItem">AttributeItem</loc>) $ii)
         returns <loc href="#dt-atomic-value">xs:QName</loc>

define function infoitem-to-type(ElementItem $ii)
       returns <loc href="#dt-atomic-value">xs:QName</loc>
{
  if (psvi-element-validity($ii) ne "valid") then
    return <loc href="#xf_QName-from-string">xf:QName-from-string</loc>("xs:anyType") 
  else if (psvi-element-member-type-definition($ii) ne ())
       then
    let $typedef:= psvi-element-member-type-definition($ii)
    let $name:= psvi-typedefinition-name($typedef)
    let $ns:=  psvi-typedefinition-namespace($typedef)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-element-type-definition($ii) ne ()) then
    let $typedef:= psvi-element-type-definition($ii)
    let $name:= psvi-typedefinition-name($typedef)
    let $ns:=  psvi-typedefinition-namespace($typedef)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-element-member-type-definition-anonymous($ii)
           eq false) then
    let $name:= psvi-element-member-type-definition-name($ii)
    let $ns:=
        psvi-element-member-type-definition-namespace($ii)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-element-type-definition-anonymous($ii)
           eq false) then
    let $name:= psvi-element-type-definition-name($ii)
    let $ns:= psvi-element-type-definition-namespace($ii)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else 
    return <loc href="#xf_QName-from-string">xf:QName-from-string</loc>("xs:anyType") 
}

define function infoitem-to-type(AttributeItem $ii)
       returns <loc href="#dt-atomic-value">xs:QName</loc>
{
  if (psvi-attribute-validity($ii) ne "valid") then
    return <loc href="#xf_QName-from-string">xf:QName-from-string</loc>("xs:anySimpleType") 
  else if (psvi-attribute-member-type-definition($ii) ne ())
       then
    let $typedef:= psvi-attribute-member-type-definition($ii)
    let $name:= psvi-typedefinition-name($typedef)
    let $ns:=  psvi-typedefinition-namespace($typedef)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-attribute-type-definition(a) ne ()) then
    let $typedef:= psvi-attribute-type-definition($ii)
    let $name:= psvi-typedefinition-name($typedef)
    let $ns:=  psvi-typedefinition-namespace($typedef)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-attribute-member-type-definition-anonymous($ii)
           eq false) then
    let $name:= psvi-attribute-member-type-definition-name($ii)
    let $ns:=
        psvi-attribute-member-type-definition-namespace($ii)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else if (psvi-attribute-type-definition-anonymous($ii)
           eq false) then
    let $name:= psvi-attribute-type-definition-name($ii)
    let $ns:= psvi-attribute-type-definition-namespace($ii)
    return <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>($ns,$name) 
  else 
    return <loc href="#xf_QName-from-string">xf:QName-from-string</loc>("xs:anySimpleType") 
} </p>

    <ednote><edtext>MF:
    Following two cases need to be completed:
    Given information items that validate with respect to a DTD, ...
    Given information items from 
    a well-formed document, with no corresponding DTD or Schema...
    </edtext></ednote>

  </div2>

<div2 id="flags">
  <head>Ignoring Comments, Processing Instructions, and Whitespace</head>

  <p>Although the data model is able to represent comments, processing 
  instructions, and insignificant whitespace, preservation of this information 
  may be unnecessary and onerous for some applications.</p>

  <p>Construction of a document from an XML information set is 
  parameterized by three flags, <emph>ignore-comments</emph>,
  <emph>ignore-processing-instructions</emph>, and <emph>ignore-whitespace</emph>.  
  If the <emph>ignore-comments</emph> flag is true, comment nodes are not 
  preserved in the data model.  If the <emph>ignore-processing-instructions</emph>
  flag is true, processing-instruction nodes are not preserved in the 
  data model.  If the <emph>ignore-whitespace</emph> flag is true, 
  insignificant whitespace is not preserved.</p>

<p role="definition">
ignore-comments                : xs:boolean
ignore-processing-instructions : xs:boolean
ignore-whitespace              : xs:boolean
</p>

  <note><p>By whom these flags are set is not defined.  
  See <specref ref="Issue-0040"/>.</p></note>
  
  <p>Expressions which rely upon the presence or absence of comments, 
  processing instructions, or insignificant whitespace may produce different 
  results for two data models created from the same infoset (XML document), 
  when each data model is constructed with different settings of these flags.</p>

  <p>Insignificant whitespace is defined as a text node that:</p>
  <olist>
    <item><p>contains no characters other than whitespace characters 
    (as defined in XML 1.0), and</p></item>
    <item><p>has a parent element with a <emph role="infoset-property">validity</emph>
    property with the value "valid", and a
    <emph role="infoset-property">type definition</emph> property yielding
    a complex type with <emph>content-type</emph> of <emph>element-only</emph>.</p></item>
  </olist>
  
  <note><p>See <specref ref="Issue-0034"/>.  Removal of insignificant whitespace 
  might be performed automatically when consistent with the schema.  See 
  <specref ref="Issue-0028"/>.  XSLT's whitespace handling mechanism needs
  to be supported; see <specref ref="Issue-0057"/>.</p></note>
</div2>

</div1>

<div1 id="Node">
  <head>Nodes</head>

  <p>The category of <emph>Node</emph> values contains seven distinct 
  kinds of nodes: <loc href="#DocumentNode">document</loc>, 
  <loc href="#ElementNode">element</loc>, <loc href="#AttributeNode">attribute</loc>,
  <loc href="#TextNode">text</loc>, <loc href="#NamespaceNode">namespace</loc>,
  <loc href="#ProcessingInstructionNode">processing instruction</loc>, and
  <loc href="#CommentNode">comment</loc>.  The seven kinds of nodes are 
  defined in the following subsections.
  See <specref ref="Issue-0078"/>.</p>
  
  <p>Each kind of node has its own constructor.   The effect of a node
  constructor is to create a new node with a unique identity, distinct
  from all other nodes.</p>
  
  <p>A set of accessors is defined on all seven kinds of Nodes.  Some 
  accessors return a constant empty sequence on certain node kinds.</p>
  
  <ulist>
    <item>
      <p>The <emph>dm:node-kind</emph> accessor returns a string value 
      representing the node's kind: either <code>"document"</code>, 
      <code>"element"</code>, <code>"attribute"</code>, <code>"text"</code>, 
      <code>"namespace"</code>, <code>"processing-instruction"</code>, or
      <code>"comment"</code>.</p>
    </item>
    <item>
      <p>The <emph>dm:name</emph> accessor returns a sequence containing
      one <emph>expanded QName</emph> for node kinds that can have names.
      For other node kinds, it always returns an empty sequence.
      An expanded QName is in the value space of <emph>xs:QName</emph>, 
      and consists of a namespace URI and a local name.  See 
      <specref ref="Issue-0063"/>, <specref ref="Issue-0070"/>.</p>
    </item>
    <item>
      <p>The <emph>dm:base-uri</emph> accessor returns a sequence containing
      zero or one uri references for node kinds that can have a base-uri
      (document nodes and element nodes).  For other
      node kinds, it always returns the empty sequence.</p>
    </item>
    <item>
      <p>The <emph>dm:string-value</emph> accessor returns the node's 
      string representation.  For some kinds of nodes, this is part of
      the node; for other kinds of nodes, it is computed from the 
      <emph>dm:string-value</emph> of its descendant nodes.</p>
    </item>
    <item>
      <p>The <emph>dm:typed-value</emph> accessor returns a sequence of
      atomic values corresponding to the node. This may be a non-empty
      sequence for element, attribute and text nodes, but it is always
      the empty sequence for other node kinds.
      The typed value of an element or attribute node is derived from
      its string value and its type in a way that is consistent with
      schema validation, as described in the definitions of the accessor
      functions for these kinds of nodes. See <specref ref="Issue-0080"/>.
      </p>
    </item>
    <item>
      <p>The <emph>dm:parent</emph> accessor returns a sequence containing
      zero or one nodes for node kinds that can have parents.  For other
      node kinds, it always returns the empty sequence.
      Every node has at most one parent, which is either 
      an element node or the document node.  A node that has no parent is 
      regarded as the root of a tree. The one exception is a namespace node, 
      which never has a parent.</p>
      <note>
        <p>In XPath 1.0, Namespace nodes have parents.</p>
      </note>
    </item>
    <item>
      <p>The <emph>dm:children</emph> accessor returns a sequence containing
      zero or more nodes for node kinds that can have children (document
      nodes and element nodes).  For other node kinds, it always returns
      the empty sequence.
      A document node or an element node is the parent of each of 
      its child nodes.  Nodes never share children: if two nodes have 
      distinct identities, then no child of one node will be a child of 
      the other node.</p>
    </item>
    <item>
      <p>The <emph>dm:attributes</emph> accessor returns a sequence containing
      zero or more attribute nodes for element nodes.  For other node kinds,
      it always returns the empty sequence. </p>
    </item>
    <item>
      <p>The <emph>dm:namespaces</emph> accessor returns a sequence containing
      zero or more namespace nodes corresponding to the in-scope namespaces
      for element nodes.
      For other node kinds, it always returns the empty sequence. </p>
    </item>
    <item>
      <p>The <emph>dm:type</emph> accessor returns a sequence containing one
      expanded-QName corresponding to the type of the element node or
      attribute node, provided that the type is globally declared. It
      returns xs:anyType or xs:anySimpleType if it is locally declared
      or if no type information exists.  For other node kinds, it always
      returns the empty sequence. </p>
    </item>
    <item>
      <p>The <emph>dm:unique-ID</emph> accessor returns a sequence containing
      zero or one ID for element nodes.  For other node kinds,
      it always returns the empty sequence. </p>
    </item>
  </ulist>

  <p>The return types of the Node accessors are given below.  Some kinds of nodes
  further restrict the return types; notably, many node kinds return a
  constant empty sequence for some of the accessors.</p>

  <p role="definition">
function dm:node-kind(Node $n)    returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:name(Node $n)         returns <loc href="#dt-atomic-value">xs:QName</loc>?
function dm:base-uri(Node $n)     returns <loc href="#dt-atomic-value">xs:anyURI</loc>?
function dm:string-value(Node $n) returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:typed-value(Node $n)  returns <loc href="#AtomicValue">AtomicValue</loc>*
function dm:parent(Node $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?
function dm:children(Node $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>
                  | <loc href="#CommentNode">CommentNode</loc> | <loc href="#TextNode">TextNode</loc>)*
function dm:attributes(Node $n)   returns <loc href="#AttributeNode">AttributeNode</loc>*
function dm:namespaces(Node $n)   returns <loc href="#NamespaceNode">NamespaceNode</loc>*
function dm:type(Node $n)         returns <loc href="#dt-atomic-value">xs:QName</loc>?
function dm:unique-ID(Node $n)    returns <loc href="#dt-atomic-value">xs:ID</loc>?
</p>

  <p>A tree contains a root plus all nodes that are reachable 
  directly or indirectly from the root via the <emph>dm:children</emph>, 
  <emph>dm:attributes</emph>, and <emph>dm:namespace</emph> accessors.  Every 
  node belongs to exactly one tree, and every tree has exactly one root 
  node.  A tree whose root node is a document node is referred to as a 
  <emph>document</emph>.  A tree whose root node is some other kind of 
  node is referred to as a <emph>fragment</emph>.</p>

<div2 id="DocumentNode">
  <head>Documents</head>

<!--
  <table role="node-summary">
    <thead>
      <tr><td>Document Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"document"</td></tr>
      <tr><td>dm:name</td>         <td>empty sequence</td></tr>
      <tr><td>dm:base-uri</td>     <td>xs:anyURI</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>empty sequence</td></tr>
      <tr><td>dm:parent</td>       <td>empty sequence</td></tr>
      <tr><td>dm:children</td>     <td>arbitrary sequence of one or more 
                                element nodes, zero or more processing 
                                instruction nodes, and zero or more 
                                comment nodes</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>empty sequence</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="DocumentNodeOverview">
  <head>Overview</head>

  <p>
  Document nodes encapsulate XML documents.
  The information associated with a document node includes the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">base-uri</emph> of the document as an xs:anyURI
  </p></item>
  <item><p>
the <emph role="dm-node-property">children</emph> of the document as a
sequence of one or more element, zero or more processing instruction,
comment or text nodes
  </p></item>
  </ulist>

  <p>The above information associated with a document node is set
  during construction and can be accessed later via the accessor functions.</p>

  <note>
    <p>Document nodes and XPath 1.0 root nodes are essentially 
    identical.</p>
  </note>

  <p>In a well-formed document, the children of the document node consist
  exclusively of element nodes, processing-instruction nodes, and comment 
  nodes, and exactly one of these children is an element node.  A document 
  node in the data model is more permissive: it permits more than one 
  element node as a child and also permits text nodes as children.
  See
  <specref ref="Issue-0074"/>.
  </p>
</div3>

<div3 id="DocumentNodeConstructor">
  <head>Constructor</head>
  <p id="document-node">
  A document node can be constructed using <emph>dm:document-node</emph>.
  The constructor takes a base URI value and a non-empty sequence of
  children nodes as arguments.</p>

  <p role="definition">
function dm:document-node(
           <loc href="#dt-atomic-value">xs:anyURI</loc> $base-uri,
           (<loc  href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>
            | <loc href="#CommentNode">CommentNode</loc> | <loc href="#TextNode">TextNode</loc>)+ $children) 
         returns <loc href="#DocumentNode">DocumentNode</loc>
  </p>

  <p>Like all other node constructors, the document-node constructor has the
  effect of creating a new node with a unique identity, distinct from all
  other nodes.</p>
</div3>

<div3 id="DocumentNodeAccessors">
  <head>Accessors</head>
  <p>The accessors <emph>dm:base-uri</emph> and <emph>dm:children</emph>
  return the values passed to the constructor as arguments.</p>

<p role="definition">
function dm:base-uri(<loc href="#DocumentNode">DocumentNode</loc> $n)  returns <loc href="#dt-atomic-value">xs:anyURI</loc>
function dm:children(<loc href="#DocumentNode">DocumentNode</loc> $n) 
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>
                  | <loc href="#CommentNode">CommentNode</loc> | <loc href="#TextNode">TextNode</loc>)+
</p>
 
  <p>The accessor <emph>dm:node-kind</emph> returns the string "document".
  The accessor <emph>dm:string-value</emph> returns the string-value
  of the document which is defined to be the concatenation of the
  string-values of all text-node descendants of the document node in 
  document order.</p>

  <p role="definition">function dm:node-kind(<loc href="#DocumentNode">DocumentNode</loc> $n)    returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:string-value(<loc href="#DocumentNode">DocumentNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc></p>
  
  <p>The accessors <emph>dm:name</emph>, <emph>dm:typed-value</emph>,
  <emph>dm:parent</emph>, <emph>dm:attributes</emph>,
  <emph>dm:namespaces</emph>,
  <emph>dm:type</emph> and <emph>dm:unique-ID</emph>
  applied to a document node always return the empty sequence.</p>
</div3>

<div3 id="DocumentNodeIS2DM">
  <head>PSVI to Datamodel Mapping</head>

  <p>When a data model fragment is created from the PSVI a
  <emph role="info-item">document information item</emph> is mapped
  to a Document Node. The precise transformation is described
  by specifying the PSVI property corresponding to each argument
  of the document node constructor.</p>

  <p>The <emph role="dm-node-property">base-uri</emph> argument
  corresponds to the 
  <emph role="infoset-property">base URI</emph> property.</p>

  <p>The <emph role="dm-node-property">children</emph> argument
  corresponds to the information items found in the
  <emph role="infoset-property">children</emph> property, omitting 
  any <emph role="info-item">document type declaration information 
  items</emph>.</p>

  <note><p>There is no way to determine what DTD might apply to the data model.
  See <specref ref="Issue-0042"/>.</p></note>

  <p>A document node is constructed from a Document Information
  Item by the <emph>infoitem-to-document-node</emph> function:</p>

<p role="definition" id="DocumentItem">
/* Accessors for document information items: */
function infoset-document-children(<loc href="#DocumentItem">DocumentItem</loc> $ii) 
         returns (<loc href="#ElementItem">ElementItem</loc> | <loc href="#ProcessingInstructionItem">ProcessingInstructionItem</loc> 
                  | <loc href="#CommentItem">CommentItem</loc> | DocTypeItem)*
function infoset-document-base-uri(<loc href="#DocumentItem">DocumentItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:anyURI</loc>
</p>

<p role="definition" id="infoitem-to-document-node">
define function infoitem-to-document-node(<loc href="#DocumentItem">DocumentItem</loc> $ii)
       returns <loc href="#DocumentNode">DocumentNode</loc>
{ 
  let $kids:= <loc href="#collapse-text-nodes">collapse-text-nodes</loc>(<loc href="#sequence-map">sequence-map</loc>(
        infoitem-to-node, infoset-document-children($ii)))
  return <loc href="#DocumentNode">dm:document-node</loc>(infoset-document-base-uri($ii),$kids)
}
</p>


  <p>The <code><loc href="#collapse-text-nodes">collapse-text-nodes</loc></code>
  function synthesizes a single text node from multiple text nodes.  The 
  <code><loc href="#sequence-map">sequence-map</loc></code> function 
  applies its first function argument to each member of its second 
  sequence argument and returns a new sequence containing the result 
  of applying the function to each member of the sequence.  In the pseudo-code
  above, <code>infoitem-to-node</code> is applied to each child of the 
  <emph role="info-item">document information item</emph>  
  <emph>$ii</emph> and a new sequence of children nodes is constructed, 
  each of which is a <emph>Node</emph>.  The constructor 
  <code>dm:document-node</code> constructs the document node in the data 
  model.</p>

  <p role="definition" id="sequence-map">
function sequence-map(<emph>function</emph> $map, <emph>Item</emph>* $seq)
         returns <emph>Item</emph>*</p>

  <p>The <emph>infoitem-to-node</emph> function maps an information item 
  to a sequence of zero or one node.</p>
  
  <p id="infoitem-to-node" role="definition">
define function infoitem-to-node(<loc href="#InfoItem">InfoItem</loc> $ii) returns Node?
{ 
  return
    if (infoitem-kind($ii) = "element") then 
      <loc href="#infoitem-to-element-node">infoitem-to-element-node</loc>($ii)
    else if (infoitem-kind($ii) = "character") then 
      <loc href="#infoitem-to-single-character-text-node">infoitem-to-single-character-text-node</loc>($ii)
    else if (infoitem-kind($ii) = "processing-instruction") then
      if (not(ignore-processing-instructions)) then 
        <loc href="#infoitem-to-processing-instruction-node">infoitem-to-processing-instruction-node</loc>($ii)
      else <loc href="#empty-sequence">empty-sequence</loc>()
    else if (infoitem-kind($ii) = "comment") then
      if (not(ignore-comments)) then 
        <loc href="#infoitem-to-comment-node">infoitem-to-comment-node</loc>($ii)
      else <loc href="#empty-sequence">empty-sequence</loc>()
    else 
      <loc href="#empty-sequence">empty-sequence</loc>()
}</p>

</div3>

<div3 id="DocumentNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps a
  Document Node to a <emph role="info-item">document information item</emph>.
  Given a Document Node $n, the properties of the corresponding
  <emph role="info-item">document information item</emph> are specified
  as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Document Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">children</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:children($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">notations</emph>
      </td><td>
        <emph>()</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">unparsed entities</emph>
      </td><td>
        <emph>()</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">base URI</emph>
      </td><td>
        <emph>dm:base-uri($n)</emph>
      </td></tr>
    </tbody>
  </table>

  <p>
  The values of the properties
  <emph role="infoset-property">character encoding scheme</emph>,
  <emph role="infoset-property">standalone</emph>,
  <emph role="infoset-property">version</emph> and
  <emph role="infoset-property">all declarations processed</emph>
  are implementation-defined but must be consistent with the rest of
  the InfoItem properties.
  </p>
  <p>Since Document Nodes are permissive, (for instance allow zero or
  more than one element node children or allow text node children)
  the mapping via dm:node-to-infoitem() may not produce a valid InfoSet.
  </p>

</div3>

</div2>


<div2 id="ElementNode">
  <head>Elements</head>

<!--
   <table role="node-summary">
    <thead>
      <tr><td>Element Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"element"</td></tr>
      <tr><td>dm:name</td>         <td>xs:QName</td></tr>
      <tr><td>dm:base-uri</td>     <td>xs:anyURI</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>sequence of zero or more atomic values</td></tr>
      <tr><td>dm:parent</td>       <td>sequence of zero or one element or document node</td></tr>
      <tr><td>dm:children</td>     <td>sequence of zero or more element nodes, 
                                zero or more processing instruction nodes, 
                                zero or more comment nodes, and zero or more
                                text nodes</td></tr>
      <tr><td>dm:attributes</td>   <td>sequence of zero or more attribute nodes</td></tr>
      <tr><td>dm:namespaces</td>   <td>sequence of zero or more namespace nodes</td></tr>
      <tr><td>dm:type</td>         <td>xs:QName</td></tr>
      <tr><td>dm:unique-ID</td>    <td>zero or one xs:ID</td></tr>
    </tbody>
  </table>
-->

<div3 id="ElementNodeOverview">
  <head>Overview</head>

  <p>
  Element nodes encapsulate XML elements.
  The information associated with an element node includes the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">expanded-QName</emph> of the element as an xs:QName
  </p></item>
  <item><p>
the <emph role="dm-node-property">base-uri</emph> of the element as an xs:anyURI
  </p></item>
  <item><p>
the <emph role="dm-node-property">type</emph> of the element as an xs:QName
  </p></item>
  <item><p>
the <emph role="dm-node-property">children</emph> of the element as a sequence of zero or more element, processing instruction, comment or text nodes
  </p></item>
  <item><p>
the <emph role="dm-node-property">parent</emph> of the element as a sequence of zero or one element or document node
  </p></item>
  <item><p>
the <emph role="dm-node-property">attributes</emph> of the element as a sequence of zero or more attribute nodes
  </p></item>
  <item><p>
the <emph role="dm-node-property">namespaces</emph> of the element as a sequence of zero or more namespace nodes
  </p></item>
  <item><p>
the <emph role="dm-node-property">unique ID</emph> of the element (if any) as a sequence of zero or one xs:ID
  </p></item>
  </ulist>

  <p>The above information associated with an element node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>Element nodes must satisfy the following constraints.</p>
  <olist>
  <item><p>
  An element node's children may not contain two consecutive text
  nodes. Consecutive text nodes are collapsed by the 
  element  constructor into one text node.  The string value of the text
  node is the concatenation of the string values of the consecutive text
  nodes.
  </p></item>
  <item><p>
  The parent of any child of an element must be the element itself
  and any element that has a parent must be among its parent's children.
  </p></item>
  <item><p>
  The attributes of an element must have distinct names.
  </p></item>
  <item><p>
  The namespaces of an element must have distinct prefixes.
  </p></item>
  </olist>
  <p>Due to the definition of the element node constructor the first two
  constraints above are automatically satisfied .
  </p>
</div3>

<div3 id="ElementNodeConstructor">
  <head>Constructor</head>

  <p id="element-node">
  An element node can be constructed using <emph>dm:element-node</emph>.
  The constructor takes an expanded-QName, 
  a sequence of namespace nodes, a sequence of attribute nodes, a 
  sequence of child nodes, and the node's type as arguments.</p>
  
  <p role="definition">
function dm:element-node(
           <loc href="#dt-atomic-value">xs:QName</loc> $qname, 
           <loc href="#NamespaceNode">NamespaceNode</loc>* $nsnodes,
           <loc href="#AttributeNode">AttributeNode</loc>* $attrnodes, 
           (<loc href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> 
            | <loc href="#CommentNode">CommentNode</loc> | <loc href="#TextNode">TextNode</loc>)* $children, 
           <loc href="#dt-atomic-value">xs:QName</loc> $type)
         returns <loc href="#ElementNode">ElementNode</loc>
  </p>

  <p>Like all other node constructors, the element node
  constructor has the effect of creating a new node with a unique 
  identity, distinct from all other nodes.</p>

  <p>If consecutive text nodes are specified as the children of an element
  node they are collapsed into one text node whose string value is the
  concatenation of the string values of the consecutive text nodes.</p>

  <p>To guarantee that the parent-child relationship is invertible, 
  (i.e. that the parent of any child of a node is itself and that any
  node that has a parent is among its parent's children),
  the element constructors logically create a copy of all of their 
  namespace, attribute, and children arguments and set the parent property 
  of these nodes to the newly created element node. As long as the parent-child 
  constraint is satisfied, an implementation of the data model may choose to 
  use specialized techniques to avoid creating physical copies of the 
  arguments to an element constructor.  See <specref ref="Issue-0052"/>.</p>
  
  <p>The data model permits element nodes without parents.
  In fact element nodes created by the element node constructor never
  have parents unless they are enclosed in other node constructors.
  Such nodes may represent partial results during expression processing.
  </p>

  <ednote><edtext>
  Note that the constructor has no base-uri argument.
  In fact base-uri is currently underspecified. Future versions of this
  document will address this. See also <specref ref="Issue-0030"/>
  </edtext></ednote>

</div3>

<div3 id="ElementNodeAccessors">
  <head>Accessors</head>

  <p>The accessors return information associated with an element node.
  Some accessors simply return the values that were passed in as
  arguments to the constructor, while others return values that are
  derived from the information associated with the element node.

  The accessors <emph>dm:name</emph>, <emph>dm:namespaces</emph>,
  <emph>dm:attributes</emph>, <emph>dm:children</emph> and
  <emph>dm:type</emph> are examples of the former kind. </p>

  <p role="definition">
function dm:name(<loc href="#ElementNode">ElementNode</loc> $n)       returns <loc href="#dt-atomic-value">xs:QName</loc>
function dm:namespaces(<loc href="#ElementNode">ElementNode</loc> $n) returns <loc href="#namespace-node">NamespaceNode</loc>*
function dm:attributes(<loc href="#ElementNode">ElementNode</loc> $n) returns <loc href="#AttributeNode">AttributeNode</loc>*
function dm:children(<loc href="#ElementNode">ElementNode</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>
                  | <loc href="#comment-node">CommentNode</loc> | <loc href="#TextNode">TextNode</loc>)* 
function dm:type(<loc href="#ElementNode">ElementNode</loc> $n)       returns <loc href="#dt-atomic-value">xs:QName</loc>
  </p>

  <p>
  The accessor <emph>dm:node-kind</emph> returns the string constant "element".
  The accessor <emph>dm:parent</emph> returns a sequence containing zero
  or one nodes representing the parent of the element node.
  The accessor <emph>dm:base-uri</emph> returns a sequence containing zero
  or one uri references representing the base URI of the element node.
  The accessor <emph>dm:unique-ID</emph> returns a sequence containing
  the unique ID of the element if it has one; otherwise, it returns
  the empty sequence.</p>

  <p role="definition">function dm:node-kind(<loc href="#ElementNode">ElementNode</loc> $n)  returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:parent(<loc href="#ElementNode">ElementNode</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?
function dm:base-uri(<loc href="#ElementNode">ElementNode</loc> $n)   returns <loc href="#dt-atomic-value">xs:anyURI</loc>?
function dm:unique-ID(<loc href="#ElementNode">ElementNode</loc> $n)  returns <loc href="#dt-atomic-value">xs:ID</loc>?
</p>

  <p>The accessor <emph>dm:string-value</emph> returns the string-value
  of the element which is defined to be the concatenation
  of the string-values of all text-node descendants of the element node in 
  document order.</p>

  <ednote><edtext>
  Note that the dm:string-value($n) and dm:string-value(dm:typed-value($n))
  may give different results under this definition.
  The issue of whether to allow or possibly mandate dm:string-value to
  return the same result as the string-value of the typed value is still
  under discussion. See <specref ref="Issue-0079"/>.
  </edtext></ednote>

  <p role="definition">function dm:string-value(<loc href="#ElementNode">ElementNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc></p>

  <p>
  The accessor function <emph>dm:typed-value</emph> returns the typed-value
  of the node, which is a sequence of zero or more atomic values.
  The typed-value is closely related to the node's string-value and its
  type. For instance when the node's string-value is "3.14" and its type
  is xs:decimal the typed-value is a sequence containing the
  atomic value 3.14 of type decimal.
  In fact, when the type is an atomic type, typed-value is the
  atomic-value constructed from the string-value and the type.

  In the general case typed-value is defined via the function 
  <emph>dm:atomic-value-sequence</emph>, which constructs a sequence
  of atomic values from a string and a type, in such a way to
  be consistent with validation.
  </p>

  <p role="definition">
define function dm:typed-value(<loc href="#ElementNode">ElementNode</loc> $n)
       returns <loc href="#AtomicValue">AtomicValue</loc>*
{
  return <loc href="#ctor_atomic-value-sequence">dm:atomic-value-sequence</loc>(dm:string-value($n),
                                  dm:type($n))
}
</p>
  
  <p>
  It is noted that when the element node's type is xs:anyType then
  dm:typed-value returns the node's string-value as xs:anySimpleType.
  If the type is a complex type with complex content
  then invoking dm:typed-value raises an error.
  <!-- See <specref ref="Issue-0068"/>. -->
  </p>
    
  <!--
  <p>The typed-value and the string-value of an element node always
  satisfy the property that the string-value of the typed-value is the
  same as the string value of the element node.</p>

  <p role="definition">
dm:string-value(dm:typed-value(<loc href="#ElementNode">ElementNode</loc> $n)) = dm:string-value(<loc href="#ElementNode">ElementNode</loc> $n)</p>
  -->

</div3>

<div3 id="ElementNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI an
  <emph role="info-item">element information item</emph> is mapped
  to an Element Node. The precise transformation is described
  by specifying the PSVI property corresponding to each argument
  of the element node constructor.</p>

  <p>The <emph role="dm-node-property">expanded-QName</emph> of the element
  is obtained as follows.
  Its local part corresponds to the 
  <emph role="infoset-property">local name</emph> property.  
  Its namespace URI corresponds to the
  <emph role="infoset-property">namespace name</emph> property.</p>
  
  <p>The <emph role="dm-node-property">children</emph> of the element node 
  correspond to the following:</p>
  <ulist>
  <item><p>
  A single text node whose string-value is the
  <emph role="infoset-property">schema normalized value</emph>
  PSVI property if that exists, or
  </p></item>
  <item><p>
  The element, comment, processing instruction, and
  character information items appearing in the
  <emph role="infoset-property">children</emph> property with consecutive
  <emph role="info-item">character information item</emph> children
  being coalesced into a single text node.
  </p></item>
  </ulist>
  <p>
  Because the data model requires 
  that all general entities be expanded, there will never be 
  <emph role="info-item">unexpanded entity reference information item</emph> 
  children.
  See <specref ref="Issue-0073"/>.</p>

  <p>The <emph role="dm-node-property">attributes</emph> of the element node
  are nodes corresponding to <emph role="info-item">attribute information 
  items</emph> appearing in the 
  <emph role="infoset-property">attributes</emph> property.
  See <specref ref="Issue-0071"/>.
  </p>

  <p>The <emph role="dm-node-property">namespaces</emph> of the element node
  are nodes
  corresponding to <emph role="info-item">namespace information items</emph>
  appearing in the <emph role="infoset-property">in-scope namespaces</emph>
  property.
  See <specref ref="Issue-0062"/>.</p>

  <p>The <emph role="dm-node-property">type</emph> of an element is an
  expanded-QName whose namespace and local name is computed as described
  in <specref ref="PSVI2Types"/>.
  It is noted that if the type referenced would be a union type then
  type refers to the member type that actually validated the
  schema normalized value.
  See <specref ref="Issue-0064"/>.
  For an element in a well-formed document with no associated schema,
  type corresponds to xs:anyType. Consequently the typed-value of such an
  element is its string value as an instance of xs:anySimpleType.
  </p>

  <p>The <emph role="dm-node-property">unique ID</emph> of the element node
  is an identifier optionally assigned by the user.  It corresponds to the 
  <emph role="infoset-property">normalized value</emph> property 
  of the <emph role="info-item">attribute information item</emph>
  in the <emph role="infoset-property">attributes</emph> 
  property that has a type <emph>ID</emph>, if one exists.</p>

  <ednote><edtext>
  Need to make it clearer how the unique ID works given that the
  constructor has no unique ID argument.
  </edtext></ednote>

  <note><p>Using this definition, only IDs declared in a DTD are effective.
  See <specref ref="Issue-0004"/>.  Even so, this definition is not
  backward compatible with XPath 1.0.  See <specref ref="Issue-0038"/>.
  Furthermore, it doesn't even work as spec'd, see <specref ref="Issue-0044"/>.
  </p></note>

  <p>An element node is constructed from an 
  <emph role="info-item">element information item</emph> by the
  <emph>infoitem-to-element-node</emph> function:</p>

  <p role="definition" id="ElementItem">
/* Accessors for element information items: */
function infoset-element-namespace-name(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:anyURI</loc>?
function infoset-element-local-name(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
function infoset-element-children(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#InfoItem">InfoItem</loc>*
function infoset-element-attributes(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#AttributeItem">AttributeItem</loc>*
function infoset-element-in-scope-namespaces(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#NamespaceItem">NamespaceItem</loc>*
function infoset-element-base-uri(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:anyURI</loc>

function psvi-element-validity(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns xs:string
function psvi-element-type-definition(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#ElementItem">ElementItem</loc>
function psvi-element-schema-normalized-value(<loc href="#ElementItem">ElementItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>

  <p id="infoitem-to-element-node" role="definition">
define function infoitem-to-element-node(<loc href="#ElementItem">ElementItem</loc> $ii)
       returns <loc href="#ElementNode">ElementNode</loc>
{ 
  let $qname:= <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>(
                 infoset-element-namespace-name($ii), 
                 infoset-element-local-name($ii)) ,
      $nsnodes:= <loc href="#sequence-map">sequence-map</loc>(
                   <loc href="#infoitem-to-namespace-node">infoitem-to-namespace-node</loc>, 
                   infoset-element-in-scope-namespaces($ii)) ,
      $attrnodes:= <loc href="#sequence-map">sequence-map</loc>(
                     <loc href="#infoitem-to-attribute-node">infoitem-to-attribute-node</loc>,
                     infoset-element-attributes($ii)) ,
      $kids:= <loc href="#collapse-text-nodes">collapse-text-nodes</loc>(<loc href="#sequence-map">sequence-map</loc>(
                <loc href="#infoitem-to-node">infoitem-to-node</loc>,
                infoset-element-children($ii))) ,
      $type:= infoitem-to-type($ii)
  return <loc href="#element-node">dm:element-node</loc>(
           $qname, $nsnodes, $attrnodes, $kids, $type)
}</p>

  <note><p>[base URI] is discarded.  See <specref ref="Issue-0030"/>.</p></note>

<!--
  <p role="definition" id="infoitem-to-concat-string">
  /* The <emph>infoitem-to-concat-string</emph> function concatenates two strings */
  concat-string : (string, string) -> string
  </p>
-->
</div3>

<div3 id="ElementNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps an
  Element Node to an <emph role="info-item">element information item</emph>.
  Given an Element Node $n, the properties of the corresponding
  <emph role="info-item">element information item</emph> are specified
  as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Element Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">namespace name</emph>
      </td><td>
        <emph>xf:get-namespace-uri(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">local name</emph>
      </td><td>
        <emph>xf:get-local-name(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">prefix</emph>
      </td><td>
        <emph>get-namespace-prefix(xf:get-namespace-uri(dm:name($n)))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">children</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:children($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">attributes</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:attributes($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">in-scope namespaces</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:namespaces($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">base URI</emph>
      </td><td>
        <emph>dm:base-uri($n)</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">parent</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:parent($n))</emph>
      </td></tr>
    </tbody>
  </table>

  <ednote><edtext>
  The <emph>get-namespace-prefix()</emph> function is not yet defined.
  </edtext></ednote>

  <p>
  The value of the property
  <emph role="infoset-property">namespace attributes</emph>
  is computed based on the difference of the namespaces of this
  element node and its parent's. This property contains a namespace
  attribute information item for each namespace that occurs in
  <emph>dm:namespaces($n)</emph>, but not in
  <emph>dm:namespaces(dm:parent($n))</emph>.
  In addition, this property also contains a namespace
  attribute information item corresponding to xmlns="",
  if <emph>dm:namespaces(dm:parent($n))</emph> contains a namespace
  node for the empty prefix, but <emph>dm:namespaces($n)</emph> does not.
  </p>
</div3>

</div2>


<div2 id="AttributeNode">
  <head>Attributes</head>

<!--
   <table role="node-summary">
    <thead>
      <tr><td>Attribute Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"attribute"</td></tr>
      <tr><td>dm:name</td>         <td>xs:QName</td></tr>
      <tr><td>dm:base-uri</td>     <td>empty sequence</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>sequence of zero or more atomic values</td></tr>
      <tr><td>dm:parent</td>       <td>sequence of zero or one element nodes</td></tr>
      <tr><td>dm:children</td>     <td>empty sequence</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>xs:QName</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="AttributeNodeOverview">
  <head>Overview</head>

  <p>
  Attribute nodes encapsulate XML attributes.
  The information associated with an attribute node includes the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">expanded-QName</emph> of the attribute as an xs:QName
  </p></item>
  <item><p>
the <emph role="dm-node-property">string-value</emph> of the attribute as an xs:string
  </p></item>
  <item><p>
the <emph role="dm-node-property">type</emph> of the attribute as an xs:QName
  </p></item>
  <item><p>
the <emph role="dm-node-property">parent</emph> of the attribute as a sequence of zero or one element node
  </p></item>
  </ulist>

  <p>The above information associated with an attribute node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>For convenience, the element node that owns this attribute is called
  its "parent" even though an attribute node is not a "child" of its
  parent element. </p>
</div3>

<div3 id="AttributeNodeConstructor">
  <head>Constructor</head>

  <p id="attribute-node">An attribute node can be constructed using
  <emph>dm:attribute-node</emph>. The constructor takes the attribute's
  expanded-QName, string value and type.</p>

  <p role="definition">
function dm:attribute-node(
           <loc href="#dt-atomic-value">xs:QName</loc> $qname, <loc href="#dt-atomic-value">xs:string</loc> $value, <loc href="#dt-atomic-value">xs:QName</loc> $type)
         returns <loc href="#AttributeNode">AttributeNode</loc></p>
  
  <p>Like all other node constructors, the attribute node
  constructor has the effect of creating a new node with a unique 
  identity, distinct from all other nodes.  </p>

</div3>

<div3 id="AttributeNodeAccessors">
  <head>Accessors</head>

  <p>The accessors <emph>dm:name</emph>, <emph>dm:string-value</emph>
  and <emph>dm:type</emph> return the values passed to the constructor
  as arguments.
  </p>

  <ednote><edtext>
  Note that the dm:string-value($n) and dm:string-value(dm:typed-value($n))
  may give different results under this definition.
  The issue of whether to allow or possibly mandate dm:string-value to
  return the same result as the string-value of the typed-value is still
  under discussion. See <specref ref="Issue-0079"/>.
  </edtext></ednote>

  <p role="definition">
function dm:name(<loc href="#AttributeNode">AttributeNode</loc> $n)         returns <loc href="#dt-atomic-value">xs:QName</loc>
function dm:string-value(<loc href="#AttributeNode">AttributeNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:type(<loc href="#AttributeNode">AttributeNode</loc> $n)         returns <loc href="#dt-atomic-value">xs:QName</loc></p>

  <p>
  The accessor <emph>dm:node-kind</emph> returns the string constant
  "attribute".
  The accessor <emph>dm:parent</emph> returns a sequence containing zero
  or one element nodes representing the parent of the attribute node.</p>

  <p role="definition">
function dm:node-kind(<loc href="#AttributeNode">AttributeNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:parent(<loc href="#AttributeNode">AttributeNode</loc> $n)    returns <loc href="#ElementNode">ElementNode</loc>?</p>

  <p>
  The accessor function <emph>dm:typed-value</emph> returns the typed-value
  of the node, which is a sequence of zero or more atomic values.
  The typed-value is closely related to the node's string-value and its
  type. It is defined via the function 
  <emph>dm:atomic-value-sequence</emph>, which constructs a sequence
  of atomic values from a string and a type, in such a way to
  be consistent with validation.
  In particular when the type is an atomic type, typed-value is the
  atomic-value constructed from the string-value and the type.
  When the type of the attribute is xs:anySimpleType
  then <emph>dm:typed-value</emph> returns its string value as
  xs:anySimpleType.
  </p>

  <p role="definition">
define function dm:typed-value(<loc href="#AttributeNode">AttributeNode</loc> $n)
                returns <loc href="#AtomicValue">AtomicValue</loc>*
{
  return <loc href="#ctor_atomic-value-sequence">dm:atomic-value-sequence</loc>(dm:string-value($n),
                                  dm:type($n))
}
</p>

  <p>
  The accessors <emph>dm:base-uri</emph>, <emph>dm:attributes</emph>,
  <emph>dm:children</emph>, <emph>dm:namespaces</emph> and
  <emph>dm:unique-ID</emph>
  applied to an attribute node always return the empty sequence.</p>

</div3>

<div3 id="AttributeNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI an
  <emph role="info-item">attribute information item</emph> is mapped
  to an Attribute Node. The precise transformation is described
  by specifying the PSVI property corresponding to each argument
  of the attribute node constructor.</p>

  <p>The <emph role="dm-node-property">expanded-QName</emph> of the
  attribute is obtained as follows.
  Its local part corresponds to the 
  <emph role="infoset-property">local name</emph> property.  
  Its namespace URI corresponds to the
  <emph role="infoset-property">namespace name</emph> property.</p>
  
  <p>The <emph role="dm-node-property">string value</emph> of the attribute
  node corresponds to the following:
  </p>
  <ulist>
  <item><p>
  the <emph role="infoset-property">schema normalized value</emph>
  PSVI property if that exists, or
  </p></item>
  <item><p>
  the <emph role="infoset-property">normalized value</emph> property.
  </p></item>
  </ulist>
  
  <p>The <emph role="dm-node-property">type</emph> of an attribute is an
  expanded-QName whose namespace and local name is computed as described
  in <specref ref="PSVI2Types"/>.
  It is noted that if the type referenced would be a union type then
  type refers to the member type that actually validated the
  schema normalized value.
  For an attribute in a well-formed document with no associated schema,
  type corresponds to xs:anySimpleType. Consequently the typed-value of such
  an attribute is its string value as an instance of xs:anySimpleType.
  </p>

  <p>An attribute node is constructed from an
  <emph role="info-item">attribute information item</emph>
  by the <emph>infoitem-to-attribute-node</emph> function:</p>

  <p role="definition" id="AttributeItem">
/* Accessors for attribute information items: */
function infoset-attribute-namespace-name(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:anyURI</loc>?
function infoset-attribute-local-name(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
function infoset-attribute-normalized-value(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
function infoset-attribute-owner-element(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#ElementItem">ElementItem</loc>

function psvi-attribute-validity(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
function psvi-attribute-type-definition(<loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#ElementItem">ElementItem</loc>
function psvi-attribute-schema-normalized-value(
           <loc href="#AttributeItem">AttributeItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>

  <p role="definition" id="infoitem-to-attribute-node">
define function infoitem-to-attribute-node(<loc href="#AttributeItem">AttributeItem</loc> $ii)
       returns <loc href="#AttributeNode">AttributeNode</loc> 
{
  let $qname:= <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>(
                 infoset-attribute-namespace-name($ii), 
                 infoset-attribute-local-name($ii)),
      $type:= infoitem-to-type($ii)
  return <loc href="#attribute-node">dm:attribute-node</loc>($qname,
           infoset-attribute-normalized-value($ii), $type)
} </p>

  <ednote><edtext>JM: Update the above to accommodate the possibility of
  schema-less and DTD validation.</edtext></ednote>

</div3>


<div3 id="AttributeNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps an
  Attribute Node to an <emph role="info-item">attribute information item</emph>.
  Given an Attribute Node $n, the properties of the corresponding
  <emph role="info-item">attribute information item</emph> are specified
  as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Attribute Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">namespace name</emph>
      </td><td>
        <emph>xf:get-namespace-uri(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">local name</emph>
      </td><td>
        <emph>xf:get-local-name(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">prefix</emph>
      </td><td>
        <emph>get-namespace-prefix(xf:get-namespace-uri(dm:name($n)))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">normalized value</emph>
      </td><td>
        <emph>dm:string-value($n)</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">owner element</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:parent($n))</emph>
      </td></tr>
    </tbody>
  </table>

  <ednote><edtext>
  The <emph>get-namespace-prefix()</emph> function is not yet defined.
  </edtext></ednote>

  <p>
  The values of the properties
  <emph role="infoset-property">specified</emph>,
  <emph role="infoset-property">attribute type</emph> and
  <emph role="infoset-property">references</emph> 
  are implementation-defined.
  </p>

</div3>

</div2>

<div2 id="NamespaceNode">
  <head>Namespaces</head>

<!--
   <table role="node-summary">
    <thead>
      <tr><td>Namespace Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"namespace"</td></tr>
      <tr><td>dm:name</td>         <td>sequence of zero or one xs:QName</td></tr>
      <tr><td>dm:base-uri</td>     <td>empty sequence</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>empty sequence</td></tr>
      <tr><td>dm:parent</td>       <td>empty sequence</td></tr>
      <tr><td>dm:children</td>     <td>empty sequence</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>empty sequence</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="NamespaceNodeOverview">
  <head>Overview</head>

  <p>
  Namespace nodes encapsulate XML namespaces.
  The information associated with a namespace node includes the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">prefix</emph> of the namespace as an xs:string
  </p></item>
  <item><p>
the <emph role="dm-node-property">uri</emph> of the namespace as an xs:anyURI
  </p></item>
  </ulist>

  <p>The above information associated with a namespace node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>Each element node has an associated set of namespace nodes
  corresponding to its in-scope namespaces.</p>
  
  <p>A namespace node has no parent.</p>

  <note><p>From XPath 1.0 : "The <emph>parent</emph> of the
  namespace node is the element node in whose namespaces collection
  this node appears."  See <specref ref="Issue-0039"/> and
  <specref ref="Issue-0060"/>, and <specref ref="Issue-0061"/>.</p></note>


</div3>

<div3 id="NamespaceNodeConstructor">
  <head>Constructor</head>

<p id="namespace-node">
  A namespace node has the constructor
  <emph>dm:namespace-node</emph>, which takes a namespace prefix and 
  the absolute URI of the namespace being declared. The namespace prefix may
  be the empty sequence. If the URI is the zero-length string, the prefix must 
  be the empty sequence.
  Like all other node constructors, the namespace node
  constructor has the effect of creating a new node with a unique identity, 
  distinct from all other nodes.  </p>

  <p role="definition">
function dm:namespace-node(<loc href="#dt-atomic-value">xs:string</loc>? $prefix, <loc href="#dt-atomic-value">xs:string</loc> $uri) 
         returns <loc href="#NamespaceNode">NamespaceNode</loc></p>

</div3>

<div3 id="NamespaceNodeAccessors">
  <head>Accessors</head>

  <p>The accessor <emph>dm:name</emph> returns the namespace prefix
  as the local-part of an xs:QName (whose namespace URI is the empty sequence).
  The accessor <emph>dm:string-value</emph> returns the namespace uri as
  an xs:string.</p>

  <p role="definition">
function dm:name(<loc href="#NamespaceNode">NamespaceNode</loc> $n)         returns <loc href="#dt-atomic-value">xs:QName</loc>?
function dm:string-value(<loc href="#NamespaceNode">NamespaceNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>

  <p> The accessor <emph>dm:node-kind</emph> returns the string constant
  "namespace". </p>

  <p role="definition">
function dm:node-kind(<loc href="#NamespaceNode">NamespaceNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc> </p>

  <p>The accessors <emph>dm:base-uri</emph>, <emph>dm:typed-value</emph>,
  <emph>dm:parent</emph>, <emph>dm:children</emph>, <emph>dm:attributes</emph>,
  <emph>dm:namespaces</emph>, <emph>dm:type</emph> and
  <emph>dm:unique-ID</emph> applied to a namespace node always return the empty
  sequence.</p>

</div3>

<div3 id="NamespaceNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI a
  <emph role="info-item">namespace information item</emph> is mapped
  to a Namespace Node. The precise transformation is described
  by specifying the PSVI property corresponding to each argument
  of the attribute node constructor.</p>

  <p>The <emph role="dm-node-property">prefix</emph> argument
  corresponds to the <emph role="infoset-property">prefix</emph> property.</p>

  <p>The <emph role="dm-node-property">uri</emph> argument corresponds
  to the <emph role="infoset-property">namespace name</emph> property.</p>


  <p>A namespace node is constructed from a 
  <emph role="info-item">namespace information item</emph> by the
  <emph>infoitem-to-namespace-node</emph> function:</p>

  <p role="definition" id="NamespaceItem">
function infoset-namespace-prefix(<loc href="#NamespaceItem">NamespaceItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>?
function infoset-namespace-namespace-name(<loc href="#NamespaceItem">NamespaceItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>

  <p role="definition" id="infoitem-to-namespace-node">
define function infoitem-to-namespace-node(<loc href="#NamespaceItem">NamespaceItem</loc> $ii)
       returns <loc href="#NamespaceNode">NamespaceNode</loc> 
{
   return <loc href="#NamespaceNode">dm:namespace-node</loc>(infoset-namespace-prefix($ii),
            infoset-namespace-namespace-name($ii))
}</p>

</div3>


<div3 id="NamespaceNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps a
  Namespace Node to a <emph role="info-item">namespace information item</emph>.
  Given a Namespace Node $n, the properties of the corresponding
  <emph role="info-item">namespace information item</emph> are specified
  as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Namespace Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">prefix</emph>
      </td><td>
        <emph>xf:get-local-name(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">namespace name</emph>
      </td><td>
        <emph>dm:string-value($n)</emph>
      </td></tr>
    </tbody>
  </table>

</div3>

</div2>

<div2 id="ProcessingInstructionNode">
  <head>Processing Instructions</head>

<!--
   <table role="node-summary">
    <thead>
      <tr><td>Processing Instruction Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"processing-instruction"</td></tr>
      <tr><td>dm:name</td>         <td>xs:QName</td></tr>
      <tr><td>dm:base-uri</td>     <td>empty-sequence</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>empty sequence</td></tr>
      <tr><td>dm:parent</td>       <td>sequence of zero or one element or document nodes</td></tr>
      <tr><td>dm:children</td>     <td>empty sequence</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>empty sequence</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="ProcessingInstructionNodeOverview">
  <head>Overview</head>

  <p>Processing instruction nodes encapsulate XML processing instructions.
  The information associated with a processing instruction node includes
  the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">target</emph> of the processing instruction as an xs:NCName
  </p></item>
  <item><p>
the <emph role="dm-node-property">content</emph> of the processing instruction as an xs:string
  </p></item>
  <item><p>
the <emph role="dm-node-property">parent</emph> of the processing instruction as a sequence of zero or one element or document node
  </p></item>
  </ulist>

  <p>The above information associated with a processing instruction node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>The string '?&gt;' may not occur within a processing instruction's
  target value (<bibref ref="xml-rec"/>).</p>

</div3>


<div3 id="ProcessingInstructionNodeConstructor">
  <head>Constructor</head>

  <p id="processing-instruction-node">
  A processing-instruction node has the constructor
  <emph>dm:processing-instruction-node</emph>, which takes an NCName
  representing the target and a string representing the content.  Like
  all other node constructors, the processing node constructor has the
  effect of creating a new node with a unique identity, distinct from
  all other nodes.  </p>
  
  <p role="definition">
function dm:processing-instruction-node(
           <loc href="#dt-atomic-value">xs:NCName</loc> $target, <loc href="#dt-atomic-value">xs:string</loc> $content)
         returns <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc>
  </p>
  
</div3>

<div3 id="ProcessingInstructionNodeAccessors">
  <head>Accessors</head>

  <p>The accessor <emph>dm:name</emph> returns the target of the
  processing instruction as the local-part of an xs:QName (whose namespace
  URI is the empty sequence).
  The accessor <emph>dm:string-value</emph> returns the content of the
  processing instruction as an xs:string.</p>

  <p role="definition">
function dm:name(<loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> $n)
         returns <loc href="#dt-atomic-value">xs:QName</loc>
function dm:string-value(<loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> $n)
         returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>
  
  <p>
  The accessor <emph>dm:node-kind</emph> returns the string constant
  "processing-instruction".
  The accessor <emph>dm:parent</emph> returns a sequence containing zero
  or one element or document node representing the parent of the
  processing instruction node.</p>

  <p role="definition">
function dm:node-kind(<loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> $n)
         returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:parent(<loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?</p>

  <p>The accessors <emph>dm:base-uri</emph>, <emph>dm:typed-value</emph>,
  <emph>dm:children</emph>, <emph>dm:attributes</emph>, <emph>dm:namespaces</emph>,
  <emph>dm:type</emph> and <emph>dm:unique-ID</emph>
  applied to a processing-instruction node always return the empty sequence.
  </p>

</div3>

<div3 id="ProcessingInstructionNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI a
  <emph role="info-item">processing instruction information item</emph>
  is mapped to a Processing Instruction Node. The precise transformation
  is described by specifying the PSVI property corresponding to each
  argument of the processing instruction node constructor.
  There are no processing instruction nodes for processing instructions
  that are children of a 
  <emph role="info-item">document type declaration information item</emph>.
  </p>

  <p>The <emph role="dm-node-property">target</emph> argument of the
  processing instruction constructor corresponds
  to the <emph role="infoset-property">target</emph> property.</p>

  <p>The <emph role="dm-node-property">content</emph> argument
  corresponds to the <emph role="infoset-property">content</emph> 
  property.</p>


  <p>A processing-instruction node is constructed from an
  <emph role="info-item">processing instruction information item</emph>
  by the <emph>infoitem-to-processing-instruction-node</emph> function:</p>

  <p role="definition" id="ProcessingInstructionItem">
/* Accessors for processing instruction information items */
function infoset-processing-instruction-target(
           <loc href="#ProcessingInstructionItem">ProcessingInstructionItem</loc> $ii)  returns <loc href="#dt-atomic-value">xs:string</loc>
function infoset-processing-instruction-content(
           <loc href="#ProcessingInstructionItem">ProcessingInstructionItem</loc> $ii)  returns <loc href="#dt-atomic-value">xs:string</loc>
</p>

  <p role="definition" id="infoitem-to-processing-instruction-node">
define function infoitem-to-processing-instruction-node(
         <loc href="#ProcessingInstructionItem">ProcessingInstructionItem</loc> $ii)
       returns <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> 
{
  return dm:processing-instruction-node( <loc href="#xf_NCName">xf:NCName</loc>(
           infoset-processing-instruction-target($ii)), 
           infoset-processing-instruction-content($ii))
}</p>

</div3>


<div3 id="ProcessingInstructionNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps a
  Processing Instruction Node to a 
  <emph role="info-item">processing instruction information item</emph>.
  Given a Processing Instruction Node $n, the properties of the corresponding
  <emph role="info-item">processing instruction information item</emph>
  are specified as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Processing Instruction Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">target</emph>
      </td><td>
        <emph>xf:get-local-name(dm:name($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">content</emph>
      </td><td>
        <emph>dm:string-value($n)</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">base URI</emph>
      </td><td>
        <emph>dm:base-uri(dm:parent($n))</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">notation</emph>
      </td><td>
        unknown
      </td></tr>
      <tr><td>
        <emph role="infoset-property">parent</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:parent($n))</emph>
      </td></tr>
    </tbody>
  </table>

</div3>

</div2>

<div2 id="CommentNode">
  <head>Comments</head>
  
<!--
   <table role="node-summary">
    <thead>
      <tr><td>Comment Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"comment"</td></tr>
      <tr><td>dm:name</td>         <td>empty sequence</td></tr>
      <tr><td>dm:base-uri</td>     <td>empty-sequence</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>empty sequence</td></tr>
      <tr><td>dm:parent</td>       <td>sequence of zero or one element or document nodes</td></tr>
      <tr><td>dm:children</td>     <td>empty sequence</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>empty sequence</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="CommentNodeOverview">
  <head>Overview</head>

  <p>Comment nodes encapsulate XML comments.
  The information associated with a comment node includes
  the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">content</emph> of the comment as an xs:string
  </p></item>
  <item><p>
the <emph role="dm-node-property">parent</emph> of the comment as a sequence of zero or one element or document node
  </p></item>
  </ulist>

  <p>The above information associated with a comment node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>The string "--" (double-hyphen) must not occur within a comment's
  string value (<bibref ref="xml-rec"/>).</p>
  
</div3>


<div3 id="CommentNodeConstructor">
  <head>Constructor</head>

  <p id="comment-node">A comment node has the constructor
  <emph>dm:comment-node</emph>, which takes a string value.
  Like all other node constructors, the comment node
  constructor has the effect of creating a new node with a unique identity, 
  distinct from all other nodes.</p>
  
  <p role="definition">
function dm:comment-node(<loc href="#dt-atomic-value">xs:string</loc> $content) 
         returns <loc href="#CommentNode">CommentNode</loc></p>

</div3>

<div3 id="CommentNodeAccessors">
  <head>Accessors</head>

  <p>The accessor <emph>dm:string-value</emph> return the value passed to
  the constructor as the argument.</p>

  <p role="definition">
function dm:string-value(<loc href="#CommentNode">CommentNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>
  
  <p>
  The accessor <emph>dm:node-kind</emph> returns the string constant
  "comment".
  The accessor <emph>dm:parent</emph> returns a sequence containing zero
  or one element or document node representing the parent of the
  comment node.</p>

  <p role="definition">
function dm:node-kind(<loc href="#CommentNode">CommentNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:parent(<loc href="#CommentNode">CommentNode</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?</p>

  <p>The accessors <emph>dm:name</emph>, <emph>dm:base-uri</emph>,
  <emph>dm:typed-value</emph>, <emph>dm:children</emph>,
  <emph>dm:attributes</emph>,
  <emph>dm:namespaces</emph>, <emph>dm:type</emph> and
  <emph>dm:unique-ID</emph> applied to a comment node always return the empty
  sequence.</p>

</div3>

<div3 id="CommentNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI a
  <emph role="info-item">comment information item</emph>
  is mapped to a Comment Node. The precise transformation
  is described by specifying the PSVI property corresponding to the
  argument of the comment node constructor.
  There are no comment nodes for comments that are children of a 
  <emph role="info-item">document type declaration information item</emph>.
  </p>

  <p>The <emph role="dm-node-property">content</emph> argument of the
  comment constructor
  corresponds to the <emph role="infoset-property">content</emph> 
  property.</p>

  <p>A comment node is constructed from a
  <emph role="info-item">comment information item</emph>
  by the <emph>infoitem-to-comment-node</emph> function:</p>

  <p role="definition" id="CommentItem">
/* Accessors for comment information items */
function infoset-comment-value(<loc href="#CommentItem">CommentItem</loc> $ii)
         returns <loc href="#dt-atomic-value">xs:string</loc>
</p>

<p role="definition" id="infoitem-to-comment-node">
define function infoitem-to-comment-node(<loc href="#CommentItem">CommentItem</loc> $ii)
       returns <loc href="#comment-node">CommentNode</loc> 
{
  return <loc href="#CommentNode">dm:comment-node</loc>(infoset-comment-value($ii))
}
</p>
</div3>


<div3 id="CommentNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps a
  Comment Node to a <emph role="info-item">comment information item</emph>.
  Given a Comment Node $n, the properties of the corresponding 
  <emph role="info-item">comment information item</emph> are specified
  as follows:
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Comment Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">content</emph>
      </td><td>
        <emph>dm:string-value($n)</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">parent</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:parent($n))</emph>
      </td></tr>
    </tbody>
  </table>

</div3>

</div2>

<div2 id="TextNode">
  <head>Text</head>

<!--
   <table role="node-summary">
    <thead>
      <tr><td>Text Node accessors</td><td>possible values</td></tr>
    </thead>
    <tbody>
      <tr><td>dm:node-kind</td>    <td>"text"</td></tr>
      <tr><td>dm:name</td>         <td>empty sequence</td></tr>
      <tr><td>dm:base-uri</td>     <td>empty-sequence</td></tr>
      <tr><td>dm:string-value</td> <td>xs:string</td></tr>
      <tr><td>dm:typed-value</td>  <td>sequence containing one atomic value</td></tr>
      <tr><td>dm:parent</td>       <td>sequence of zero or one element or document nodes</td></tr>
      <tr><td>dm:children</td>     <td>empty sequence</td></tr>
      <tr><td>dm:attributes</td>   <td>empty sequence</td></tr>
      <tr><td>dm:namespaces</td>   <td>empty sequence</td></tr>
      <tr><td>dm:type</td>         <td>empty sequence</td></tr>
      <tr><td>dm:unique-ID</td>    <td>empty sequence</td></tr>
    </tbody>
  </table>
-->

<div3 id="TextNodeOverview">
  <head>Overview</head>

  <p>Text nodes encapsulate consecutive XML character data.
  The information associated with a text node includes the following.
  </p>
  <ulist>
  <item><p>
the <emph role="dm-node-property">content</emph> as an xs:string
  </p></item>
  <item><p>
the <emph role="dm-node-property">parent</emph> as a sequence of zero or one element or document node
  </p></item>
  </ulist>

  <p>The above information associated with a text node is set
  during construction and can be accessed later via the accessor functions.</p>

  <p>Text nodes must satisfy the following constraints.</p>
  <olist>
  <item><p>
A text node cannot contain the empty string as its content.  
  </p></item>
  <item><p>
Two consecutive text nodes can never occur as children of a node.  
  </p></item>
  </olist>
</div3>

<div3 id="TextNodeConstructor">
<head>Constructor</head>

  <p id="text-node">A text node has the constructor <code>dm:text-node</code>
  and takes a string value.  Like all other node constructors, the text
  constructor has the effect of creating a new node with a unique identity, 
  distinct from all other nodes.</p>

  <p role="definition">
function dm:text-node(<loc href="#dt-atomic-value">xs:string</loc> $content) returns <loc href="#TextNode">TextNode</loc></p>

</div3>

<div3 id="TextNodeAccessors">
  <head>Accessors</head>

  <p>The accessor <emph>dm:string-value</emph> return the value passed to
  the constructor as the argument.</p>

  <p role="definition">
function dm:string-value(<loc href="#TextNode">TextNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
  </p>
  
  <p>The <emph>dm:typed-value</emph> accessor returns the string-value
  of the text node as xs:anySimpleType.</p>
  
  <p role="definition">
define function dm:typed-value(<loc href="#TextNode">TextNode</loc> $n)
                returns <loc href="#AtomicValue">AtomicValue</loc>
{
  return <loc href="#AtomicValue">dm:atomic-value</loc>(dm:string-value($n),
                         xs:anySimpleType)
}
</p>

  <p>
  The accessor <emph>dm:node-kind</emph> returns the string constant
  "text".
  The accessor <emph>dm:parent</emph> returns a sequence containing zero
  or one element or document node representing the parent of the
  comment node.</p>

  <p role="definition">
function dm:node-kind(<loc href="#TextNode">TextNode</loc> $n) returns <loc href="#dt-atomic-value">xs:string</loc>
function dm:parent(<loc href="#TextNode">TextNode</loc> $n)
         returns (<loc href="#ElementNode">ElementNode</loc> | <loc href="#DocumentNode">DocumentNode</loc>)?</p>

  <p>The accessors <emph>dm:name</emph>, <emph>dm:base-uri</emph>,
  <emph>dm:children</emph>, <emph>dm:attributes</emph>,
  <emph>dm:namespaces</emph>, <emph>dm:type</emph> and
  <emph>dm:unique-ID</emph> applied to a text node always return the empty
  sequence.</p>

</div3>

<div3 id="TextNodePSVI2DM">
  <head>PSVI to Data Model Mapping</head>

  <p>When a data model fragment is created from the PSVI a
  sequence of one or more consecutive
  <emph role="info-item">character information items</emph>
  are mapped to a Text Node.
  As much character data as possible is grouped into each text node:
  a text node never has an immediately following or preceding sibling
  that is a text node.
  The precise transformation
  is described by specifying the PSVI property corresponding to the
  argument of the comment node constructor.
  </p>

  <p>The <emph role="dm-node-property">content</emph> argument of the
  text node is the character data, which corresponds to the concatenated
  <emph role="infoset-property">character code</emph> properties of
  each of the <emph role="info-item">character information items</emph>.
  </p>

  <note><p>The string-value is not W3C normalized as described in the
  <loc href="http://www.w3.org/TR/charmod/#sec-TextNormalization">Character
  Model for the World Wide Web version 1.0</loc> draft.  See
  <specref ref="Issue-0045"/>.</p></note>

<!--
  <p>The <emph>dm:parent</emph> of the text node corresponds to 
  the <emph role="infoset-property">parent</emph> property of 
  any one of the consecutive <emph role="info-item">character 
  information items</emph> (consecutive characters always have 
  the same parent).</p>
-->

  <p>The mapping from character information items to text nodes occurs 
  in the <loc href="#infoitem-to-element-node">infoitem-to-element-node</loc> 
  function.  The <emph>infoset-character-code</emph> accessor maps a 
  character information item to the ISO 10646 character code (in the 
  range 0 to #x10FFFF, though not every value in this range is a legal 
  XML character code) of the character.</p>

  <p role="definition" id="CharacterItem">
function infoset-character-code(<loc href="#CharacterItem">CharacterItem</loc> $ii)
         returns Code</p>

  <p>The function <emph>infoitem-to-single-character-text-node</emph> takes one character
  information item and maps it to a text node with a string value of 
  length one.</p>

  <p id="infoitem-to-single-character-text-node" role="definition">
define function infoitem-to-single-character-text-node(
         <loc href="#CharacterItem">CharacterItem</loc> $ii)
       returns <loc href="#TextNode">TextNode</loc>
{
  {-- convert character code to string of length 1 --}
  return <loc href="#TextNode">dm:text-node</loc>(
           code2string(infoset-character-code($ii)))
}</p>

  <ednote><edtext>JM: need a definition or description of code2string.</edtext></ednote>

  <p>The <emph>collapse-text-nodes</emph> function synthesizes a single text 
  node from multiple text nodes. It calls <emph>infoitem-to-text-nodes</emph>
  to collapse recursively one or more consecutive text nodes in its argument 
  sequence.  If insignificant whitespace is ignored, any text node containing 
  only whitespace is eliminated. All other nodes  are returned unchanged.</p>

  <p id="collapse-text-nodes" role="definition">
define function collapse-text-nodes(Node* $nodes)
       returns Node* 
{
  let $newnodes:= infoitem-to-text-nodes($nodes)
  return 
    if (<loc href="#flags">ignore-whitespace</loc>) then 
      <loc href="#sequence-map">sequence-map</loc>(delete-whitespace-node, $newnodes)
    else $newnodes
}

define function infoitem-to-text-nodes(Node* $nodes)
       returns Node* 
{
  if (<loc href="#xf_empty">xf:empty</loc>($nodes)) then return <loc href="#empty-sequence">empty-sequence</loc>()
  else
    let $head:= <loc href="#op_item-at">op:item-at</loc>($nodes, 1), 
        $tail:= <loc href="#xf_subsequence">xf:subsequence</loc>($nodes, 2)
    return
      if (dm:node-kind($head) = "text") then
        /* Collapse two consecutive text nodes and apply 
           infoitem-to-text-nodes recursively */
        if (<loc href="#xf_empty">xf:empty</loc>($tail)) then $head
        else if (dm:node-kind(<loc href="#op_item-at">op:item-at</loc>($tail,1))="text") then 
          infoitem-to-text-nodes(
            op:concatenate(
              dm:text-node(<loc href="#xf_concat">xf:concat</loc>(dm:string-value($head),
                   dm:string-value(<loc href="#op_item-at">op:item-at</loc>($tail,1)))), 
              <loc href="#xf_subsequence">xf:subsequence</loc>($tail, 2)
            )
          )
        else op:concatenate($head,
               op:concatenate(<loc href="#op_item-at">op:item-at</loc>($tail,1),
                              infoitem-to-text-nodes($tail)))
      else op:concatenate($head, infoitem-to-text-nodes($tail))
  }</p>

  <ednote><edtext>JM: need a definition or description of delete-whitespace-node.</edtext></ednote>

<!--  infoset-character-parent     : (<loc href="#CharacterItem">CharacterItem</loc>) -> Sequence&lt;<loc href="#ElementItem">ElementItem</loc>&gt; /* unused */
  infoset-character-whitespace : (<loc href="#CharacterItem">CharacterItem</loc>) -> <loc href="#dt-atomic-value">xs:boolean</loc> /* unused */
-->  

</div3>


<div3 id="TextNodeDM2IS">
  <head>Data Model to Infoset Mapping</head>

  <p>
  The mapping of the data model to the XML Information Set maps a Text Node
  to a sequence of <emph role="info-item">character information items</emph>.
  Given a Text Node $n, the properties of the <emph>i<sup>th</sup></emph>
  <emph role="info-item">character information items</emph> in the
  sequence are specified as follows
  (for <emph>$i = 1, 2, ..., xf:string-length(dm:string-value())</emph>):
  </p>

  <table role="infoset-mapping">
    <colgroup><col width="35%"/><col width="65%"/></colgroup>
    <thead>
      <tr><td>Character Information Item properties</td><td> </td></tr>
    </thead>
    <tbody>
      <tr><td>
        <emph role="infoset-property">character code</emph>
      </td><td>
        The ISO 10646 character code corresponding to
        <emph>xf:substring(dm:string-value($n),$i,1)</emph>
      </td></tr>
      <tr><td>
        <emph role="infoset-property">element content whitespace</emph>
      </td><td>
        A boolean indicating whether the Text Node consists entirely
        of white space.
      </td></tr>
      <tr><td>
        <emph role="infoset-property">parent</emph>
      </td><td>
        <emph>dm:nodes-to-infoitems(dm:parent($n))</emph>
      </td></tr>
    </tbody>
  </table>

</div3>

</div2>
</div1>


<div1 id="AtomicValue">
  <head>Atomic Values</head>

  <p><termdef id="dt-atomic-value" term="atomic value">
  An <term>atomic value</term> is a value in the value space
  of an <emph>XML Schema atomic type</emph> labeled with that corresponding
  atomic type or it is a string labeled with xs:anySimpleType.
  The type xs:anySimpleType marks a value that has been 
  returned as the typed value of a node whose type is unknown 
  (for instance because it hasn't been validated).
  </termdef></p>

<!-- pre 2002-07-31 definition:
  <p><termdef id="dt-atomic-value" term="atomic value">A <term>atomic 
  value</term> encapsulates an <emph>XML Schema atomic type</emph>
  and a corresponding value of that type.</termdef></p>
-->

  <p>An XMLSchema atomic type <bibref ref="xmlschema-2"/> may be
  <emph>primitive</emph> or <emph>derived</emph>.
  The primitive atomic types are named:
  <emph>xs:string</emph>, 
  <emph>xs:boolean</emph>,
  <emph>xs:decimal</emph>, 
  <emph>xs:float</emph>,
  <emph>xs:double</emph>, 
  <emph>xs:duration</emph>,
  <emph>xs:dateTime</emph>, 
  <emph>xs:time</emph>,
  <emph>xs:date</emph>, 
  <emph>xs:gYearMonth</emph>,
  <emph>xs:gYear</emph>,
  <emph>xs:gMonthDay</emph>,
  <emph>xs:gDay</emph>, 
  <emph>xs:gMonth</emph>,
  <emph>xs:hexBinary</emph>, 
  <emph>xs:base64Binary</emph>,
  <emph>xs:anyURI</emph>, 
  <emph>xs:QName</emph>,
  <emph>xs:NOTATION</emph>.
  
  A derived atomic type is derived by restriction and has a primitive
  base type and a set of constraining facets.</p> 

  <p>It is noted that the value space of the atomic values is the
  union of the value spaces of the nineteen primitive XML Schema types.
  This value space clearly includes those atomic values whose type is
  primitive, but it also includes those whose type is derived, as
  derivation by restriction always limits the value space.
  </p>
  
  <p>An XMLSchema simple type <bibref ref="xmlschema-2"/> may be also
  <emph>primitive</emph> or <emph>derived</emph> with the method of
  derivation being <emph>restriction</emph>, <emph>list</emph> or
  <emph>union</emph>.
  The atomic types are exactly those types where the derivation method
  is restriction only and not list or union. Values corresponding
  to such types are represented by atomic values.
  XML Schema simple types can be derived by list. Values corresponding
  to such types are represented by a sequence of atomic values
  whose type is the item type.
  XML Schema simple types can be derived by union. Values corresponding
  to such types lose the union type information and store one of
  the individual types.
  </p>

  <p>An atomic value can be constructed from its lexical representation.
  <emph>dm:atomic-value</emph> takes a string and a
  corresponding atomic type and constructs an atomic value in such a
  way to be consistent with validation.
  In particular the construction takes into
  consideration the facets of the type. If the string does not
  represent a valid value of the type an error is raised. 
  When xs:anySimpleType is specified as the type no
  validation takes place.
  The details of the construction are described in the "Constructor
  Functions" and the related "Casting Functions" section of 
  <bibref ref="XFO"/>.
  </p>

  <p role="definition" id="ctor_atomic-value">
function dm:atomic-value(<loc href="#dt-atomic-value">xs:string</loc> $value, <loc href="#dt-atomic-value">xs:QName</loc> $type)
         returns <loc href="#AtomicValue">AtomicValue</loc>
</p>

  <p>This constructor corresponds very closely to the atomic
  value constructors specified in <bibref ref="XFO"/>.
  Each of those constructors takes a string in the lexical space of the 
  given primitive type and returns the corresponding atomic value.
  For example, the constructor 
  <code><loc href="#xf_decimal">xf:decimal</loc>(<loc href="#dt-atomic-value">xs:string</loc>)</code>
  constructs an atomic value of type xs:decimal from a string.
  Analogous constructors exist for the other XML Schema primitive types.
  </p>

  <p>Since the above constructor can only be used with atomic
  types we define a second one that works with more general types.
  The constructor <emph>dm:atomic-value-sequence</emph> takes a string
  and a corresponding type and creates a sequence of atomic values.
  The derivation of the sequence of atomic values from the string
  and the type is consistent with validation. If the string does not
  represent a valid value of the type an error is raised. </p>

  <p role="definition" id="ctor_atomic-value-sequence">
function dm:atomic-value-sequence(
           <loc href="#dt-atomic-value">xs:string</loc> $value, <loc href="#dt-atomic-value">xs:QName</loc> $type)
         returns <loc href="#AtomicValue">AtomicValue</loc>*
</p>

  <p>Examples of using the constructor include the following.
  </p>
  <ulist>
  <item><p>
  dm:atomic-value-sequence("3.14",xs:decimal)
  creates a singleton sequence containing the decimal 3.14.
  </p></item>
  <item><p>
  dm:atomic-value-sequence("7 8 9",myns:HatSizeList)
  creates a sequence containing the three values 7,8,9 each of type
  myns:HatSize; assuming that myns:HatSizeList is defined to be a list
  type with the item type being myns:HatSize, which in turn is derived
  from  xs:integer.
  </p></item>
  <item><p>
  dm:atomic-value-sequence("bar baz faz",xs:IDREFS)
  creates a sequence containing the three atomic values "bar","baz",
  "faz" each of type xs:IDREF.
  </p></item>
  <item><p>
  dm:atomic-value-sequence("1 2 3",xs:anySimpleType)
  creates a singleton sequence containing "1 2 3" of type xs:anySimpleType
  </p></item>
  <item><p>
  dm:atomic-value-sequence("1 2 3",xs:anyType)
  creates a singleton sequence containing "1 2 3" of type xs:anySimpleType
  </p></item>
  </ulist>

  <p>If an atomic type is used as the argument to dm:atomic-value-sequence
  it constructs the same atomic value as dm:atomic-value.
  When a list type is used with dm:atomic-value-sequence the resulting
  sequence will contain atomic values whose type is the item type of the
  list type.
  In particular when any of the types xs:IDREFS, xs:NMTOKENS or xs:ENTITIES
  are used as arguments, the resulting sequence will contain atomic values
  whose type is xs:IDREF, xs:NMTOKEN or xs:ENTITY respectively.
  Using xs:anySimpleType as the argument signals that the type information
  is not known. This happens when the typed-value of an unvalidated
  attribute is accessed.
  Using xs:anyType as the argument results an atomic value of type
  xs:anySimpleType. This happens when the typed-value of an unvalidated
  element is accessed.
  If a complex type with complex content is used to invoke the constructor
  an error is raised.
  </p>

  <p>The accessor <emph>dm:type</emph> returns an atomic value's type.
  The accessor <emph>dm:string-value</emph> can be used to recover a
  lexical representation of the atomic value.
  The details of converting an atomic value to its
  string representation are described in the "Casting Functions"
  section of <bibref ref="XFO"/>.
  In particular if the atomic value's type is primitive,
  <emph>dm:string-value</emph> returns the
  atomic value's canonical lexical representation for that primitive
  type as specified in <bibref ref="xmlschema-2"/>.
  If the atomic value's type is derived, the lexical representation
  depends on whether a value is supplied for the type's pattern facet:
  If no such value is supplied <emph>dm:string-value</emph> returns the
  atomic value's canonical lexical representation for the base type
  (which is a primitive type). Otherwise <emph>dm:string-value</emph>
  returns a lexical representation that matches the value specified
  for the pattern facet. (This case includes xs:integers.)
  See <specref ref="Issue-0072"/>.</p>
    
    <p role="definition">
function dm:type(<loc href="#AtomicValue">AtomicValue</loc> $v)         returns <loc href="#dt-atomic-value">xs:QName</loc>
function dm:string-value(<loc href="#AtomicValue">AtomicValue</loc> $v) returns <loc href="#dt-atomic-value">xs:string</loc></p>

  <note>
    <p>Using the canonical lexical representation for atomic values
     as described above may not always be compatible with XPath 1.0.</p>
  </note>

  <p>Note that the data model does not currently represent
  key values and key reference values as described in XML Schema Part 1 : 
  Structures  <bibref ref="xmlschema-1"/>. In a future draft of this 
  document, keys and key references may be represented in the data 
  model (see <specref ref="Issue-0032"/>).</p>

</div1>


<div1 id="sequences">
  <head>Sequences</head>

  <p>A <emph>sequence</emph> is an ordered collection of zero or more
  items. An <emph>item</emph> may be a node or an atomic value, i.e.
  a sequence may contain nodes, atomic values, or any mixture of
  nodes and atomic values (see <specref ref="Issue-0035"/>).
  When a node is added to a sequence its identity remains the same.
  Consequently one node may be contained in more than one sequence
  and a sequence may contain duplicate items.
  Unlike conventional lists, sequences are "flat", i.e., sequences may not 
  contain other sequences.</p>

  <p>An important characteristic of the data model is that there is no
  distinction between an item (i.e., a node or an atomic value) and a 
  singleton sequence containing that item, i.e., an item is 
  equivalent to a singleton sequence containing that item and vice 
  versa.</p>
  
  <note>
    <p>Sequences replace node-sets from XPath 1.0.  In XPath 1.0, 
    node-sets do not contain duplicates.  In generalizing node-sets to 
    sequences in XPath 2.0, duplicate removal is provided by functions 
    on node sequences.</p>
  </note>
  
  <note><p>See <specref ref="Issue-0025"/>.</p></note>
  
  <p>A collection of documents is represented in the data model as a 
  sequence of document nodes (see <specref ref="Issue-0023"/>).</p>

  <p>A sequence has no identity.  Equality comparison of sequences is 
  performed only by comparing the items of the sequences.</p>

<!-- This is a new reformulation of the string value of a sequence...
  <p>The <emph>dm:string-value</emph> of a sequence is obtained by
  concatenating the <emph>dm:string-value</emph>s of the individual
  members of the sequence with appropriate separators in between:
  a <code>#x20</code> (space) separator is to be inserted between
  consecutive atomic values; no separators are to be inserted between
  consecutive nodes or nodes and atomic values</p>
-->

<!-- We may need to reinstate these (or better yet use the reformulation
     above) if we want to refer to the string value of a sequence.

  <p>The <emph>dm:string-value</emph> of a sequence containing atomic
  values only is obtained by inserting a <code>#x20</code> (space)
  separator between the <emph>dm:string-value</emph>s of the individual
  members of the sequence and concatenating the result.</p>
  
  <p>The <emph>dm:string-value</emph> of a sequence containing any item
  other than an atomic value is the concatenation of the
  <emph>dm:string-value</emph>s of the individual members of the sequence.
  In particular the string value of an empty sequence is an empty string.
  </p>
-->
  
  <p>The constructor <emph>empty-sequence</emph> constructs the empty 
  sequence.  The n-ary <emph>op:concatenate</emph> constructor creates a
  new sequence containing the values in its first argument followed by 
  the concatenated values of its second through final arguments.
  In the function signatures below <emph>Item</emph> refers to a
  nodes or an atomic value.
  Since an item is equivalent to a singleton sequence containing the
  item, <emph>op:concatenate</emph> may be applied to items.</p>
  
  <p role="definition" id="empty-sequence">
function empty-sequence()                  returns <emph>Item</emph>*
function op:concatenate(<emph>Item</emph>*, ..., <emph>Item</emph>*) returns <emph>Item</emph>*</p>  

  <p>A sequence has several accessors. They are defined in <bibref ref="XFO"/>.
  In this document the following four accessors are used.
  The <emph>empty</emph> accessor returns a boolean indicating whether or
  not the specified sequence is empty.
  The <emph>item-at</emph> accessor returns the item in the sequence that
  is located at the specified index.
  The <emph>subsequence</emph> accessor returns the contiguous sequence of items
  beginning at the specified position and continuing to the end of the
  sequence. 
  The <emph>count</emph> function returns the number of items in the sequence. 
  </p>

  <p role="definition">
function empty(<emph>Item</emph>*)                  returns xs:boolean
function item-at(<emph>Item</emph>*,xs:decimal)     returns <emph>Item</emph>
function subsequence(<emph>Item</emph>*,xs:decimal) returns <emph>Item</emph>*
function count(<emph>Item</emph>*)                  returns xs:unsignedInt</p>

</div1>

</body>


<back>
<div1>
  <head>XML Information Set Conformance</head>

  <p>This specification conforms to the XML Information Set <bibref ref="xml-infoset"/>.
  The following information items must be exposed by the infoset producer 
  to construct a data model fragment:</p>
    
  <ulist>
    <item><p>The <emph role="info-item">Document Information Item</emph> with
             <emph role="infoset-property">base URI</emph> and
             <emph role="infoset-property">children</emph> properties.</p></item>
             
    <item><p><emph role="info-item">Element Information Items</emph> with
             <emph role="infoset-property">children</emph>,
             <emph role="infoset-property">attributes</emph>,
             <emph role="infoset-property">in-scope namespaces</emph>,
             <emph role="infoset-property">local name</emph>,
             <emph role="infoset-property">namespace name</emph>,
             <emph role="infoset-property">parent</emph> properties.</p></item>

    <item><p><emph role="info-item">Attribute Information Items</emph> with
             <emph role="infoset-property">namespace name</emph>,
             <emph role="infoset-property">local name</emph>,
             <emph role="infoset-property">normalized value</emph>,
             <emph role="infoset-property">owner element</emph> properties.</p></item>

    <item><p><emph role="info-item">Character Information Items</emph> with
             <emph role="infoset-property">character code</emph> and
             <emph role="infoset-property">parent</emph> properties.</p></item>

    <item><p><emph role="info-item">Processing Instruction Information Items</emph> with
             <emph role="infoset-property">target</emph>,
             <emph role="infoset-property">content</emph> and
             <emph role="infoset-property">parent</emph> properties.</p></item>

    <item><p><emph role="info-item">Comment Information Items</emph> with
             <emph role="infoset-property">content</emph> and
             <emph role="infoset-property">parent</emph> properties.</p></item>

    <item><p><emph role="info-item">Namespace Information Items</emph> with
             <emph role="infoset-property">prefix</emph> and
             <emph role="infoset-property">namespace name</emph> properties.</p></item>
  </ulist>
  
  <p>Other information items and properties made available by the
  Infoset processor are ignored.  In addition to the properties above, 
  the following properties from the PSV Infoset are required:</p>
  
  
  <ulist>
    <item><p><emph role="infoset-property">validity</emph>, 
    <emph role="infoset-property">type definition</emph>,
    <emph role="infoset-property">type definition namespace</emph>,
    <emph role="infoset-property">type definition name</emph>,
    <emph role="infoset-property">type definition anonymous</emph>,
    <emph role="infoset-property">member type definition</emph>,
    <emph role="infoset-property">member type definition namespace</emph>,
    <emph role="infoset-property">member type definition name</emph>,
    <emph role="infoset-property">member type definition anonymous</emph> and
    <emph role="infoset-property">schema normalized value</emph> properties on
    <emph role="info-item">Element Information Items</emph>.</p></item>

    <item><p><emph role="infoset-property">validity</emph>, 
    <emph role="infoset-property">type definition</emph>,
    <emph role="infoset-property">type definition namespace</emph>,
    <emph role="infoset-property">type definition name</emph>,
    <emph role="infoset-property">type definition anonymous</emph>,
    <emph role="infoset-property">member type definition</emph>,
    <emph role="infoset-property">member type definition namespace</emph>,
    <emph role="infoset-property">member type definition name</emph>,
    <emph role="infoset-property">member type definition anonymous</emph> and
    <emph role="infoset-property">schema normalized value</emph> properties on
    <emph role="info-item">Attribute Information Items</emph>.</p></item>
  </ulist>

</div1>

<div1>
<head>References</head>
<blist>

<bibl id="xml-infoset" key="XML Information Set">
  World Wide Web Consortium, 
  <emph>XML Information Set (Infoset)</emph>.
  See <loc href="http://www.w3.org/TR/xml-infoset/">http://www.w3.org/TR/xml-infoset/</loc>.
</bibl>

<bibl id="xml-rec" key="XML Recommendation">
  World Wide Web Consortium, 
  <emph>Extensible Markup Language (XML) 1.0 (Second Edition)</emph>
  See <loc href="http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</loc>.
</bibl>

<bibl id="XFO" key="XQuery 1.0 and XPath 2.0 Functions and Operators">
  World Wide Web Consortium, 
  <emph>XQuery 1.0 and XPath 2.0 Functions and Operators</emph>.
  See <loc href="http://www.w3.org/TR/xquery-operators/">http://www.w3.org/TR/xquery-operators/</loc>.
</bibl>

<bibl id="XSFD" key="XML Schema: Formal Description">
  World-Wide Web Consortium
  <emph>XML Schema: Formal Description</emph>, Working Draft, 
  March 2001. 
  See <loc href="http://www.w3.org/TR/xmlschema-formal/">http://www.w3.org/TR/xmlschema-formal/</loc>.
</bibl>

<bibl id="xmlschema-1" key="XMLSchema Part 1">
  World Wide Web Consortium, 
  <emph>XML Schema Part 1: Structures</emph>.
  See <loc href="http://www.w3.org/TR/xmlschema-1/">http://www.w3.org/TR/xmlschema-1</loc>.
</bibl>

<bibl id="xmlschema-2" key="XMLSchema Part 2">
  World Wide Web Consortium, 
  <emph>XML Schema Part 2: Datatypes</emph>.
  See <loc href="http://www.w3.org/TR/xmlschema-2/">http://www.w3.org/TR/xmlschema-2</loc>.
</bibl>

</blist>
</div1>

<inform-div1>
<head>References</head>
<blist>

<bibl id="w3c-style-activity" key="W3C Style Activity">
  World Wide Web Consortium, 
  <emph>Style Activity</emph>. 
  See <loc href="http://www.w3.org/Style/Activity">http://www.w3.org/Style/Activity</loc>.
</bibl>

<bibl id="w3c-xml-activity" key="W3C XML Activity">
  World Wide Web Consortium, 
  <emph>XML Activity</emph>. 
  See <loc href="http://www.w3.org/XML/Activity">http://www.w3.org/XML/Activity</loc>.
</bibl>

<bibl key="XML Query Data Model" id="XQDM00">
  World-Wide Web Consortium
  <emph>XML Query Data Model</emph>, Working Draft, Feb 2001.
  See <loc href="http://www.w3.org/TR/2001/WD-query-datamodel-20010215/">http://www.w3.org/TR/2001/WD-query-datamodel-20010215/</loc>.
</bibl>

<bibl key="XPath" id="XPath">
  World-Wide Web Consortium
  <emph>XML Path Language (XPath)</emph>: Version 1.0. 
  November, 1999. 
  See <loc href="http://www.w3.org/TR/xpath.html">http://www.w3.org/TR/xpath.html</loc>.
</bibl>

<bibl id="XPathReq" key="XPath Requirements Version 2.0">
  World Wide Web Consortium, 
  <emph>XPath Requirements Version 2.0</emph>.
  See <loc href="http://www.w3.org/TR/xpath20req">http://www.w3.org/TR/xpath20req</loc>.
</bibl>

<bibl key="XPath 2.0" id="XPath2">
  World-Wide Web Consortium
  <emph>XML Path Language (XPath)</emph>: Version 2.0. 
  See <loc href="http://www.w3.org/TR/xpath20/">http://www.w3.org/TR/xpath20/</loc>.
</bibl>

<bibl id="xpointer" key="XML Pointer Language (XPointer)">
  World Wide Web Consortium, 
  <emph>XML Pointer Language (XPointer)</emph>.
  See <loc href="http://www.w3.org/TR/xptr/">http://www.w3.org/TR/xptr/</loc>.
</bibl>

<bibl id="XSLT2" key="XSLT 2.0">
  World Wide Web Consortium, 
  <emph>XSL Transformations Language (XSLT)</emph>: Version 2.0. 
  See <loc href="http://www.w3.org/TR/xslt20/">http://www.w3.org/TR/xslt20/</loc>.
</bibl>

<bibl id="XSLT" key="XSLT 1.0">
  World Wide Web Consortium, 
  <emph>XSL Transformations Language (XSLT)</emph>: Version 1.0. 
  See <loc href="http://www.w3.org/TR/xslt">http://www.w3.org/TR/xslt</loc>.
</bibl>

<bibl id="XQFS" key="XQuery 1.0 Formal Semantics">
  World Wide Web Consortium, 
  <emph>XQuery 1.0 Formal Semantics</emph>.
  See <loc href="http://www.w3.org/TR/query-semantics/">http://www.w3.org/TR/query-semantics/</loc>
</bibl>

<bibl id="XQWG" key="XML Query Working Group">
  World Wide Web Consortium, 
  <emph>XML Query Working Group</emph>.
  Home page: <loc href="http://www.w3.org/XML/Activity#query-wg">http://www.w3.org/XML/Activity#query-wg</loc>.
</bibl>

<bibl id="XSLWG" key="XSL Working Group">
  World Wide Web Consortium, 
  <emph>XSL Working Group</emph>.
  Home page: <loc href="http://www.w3.org/Style/XSL/">http://www.w3.org/Style/XSL/</loc>.
</bibl>

<bibl id="XQuery" key="XQuery 1.0: A Query Language for XML">
  World Wide Web Consortium, 
  <emph>XQuery 1.0: A Query Language for XML</emph>.
  See <loc href="http://www.w3.org/TR/xquery/">http://www.w3.org/TR/xquery/</loc>.
</bibl>

<bibl id="XQueryReq" key="XML Query Requirements">
  World Wide Web Consortium, 
  <emph>XML Query Requirements</emph>.
  See <loc href="http://www.w3.org/TR/2001/WD-xmlquery-req-20010215">http://www.w3.org/TR/2001/WD-xmlquery-req-20010215</loc>.
</bibl>
</blist>
</inform-div1>

<inform-div1>
  <head>Example</head>
  
  <p>We use the following XML document to illustrate the information 
  contained in a data model fragment:</p>

<eg><![CDATA[<?xml version="1.0"?>
<p:part xmlns:p="http://www.example.com/PartSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation = "http://www.example.com/PartSchema
                              http://www.example.com/PartSchema"
        name="NB-401-nutbolt">
  <p:mfg>Acme</p:mfg>
  <p:price>10.50</p:price>
</p:part>]]></eg>

<p>The document is associated with the URI "http://www.example.com/partlist/part0001.xml",
and is valid with respect to the following XML schema:</p>

<eg><![CDATA[<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://www.example.com/PartSchema"
           xmlns="http://www.example.com/PartSchema"
           elementFormDefault="qualified">
  <xs:element name="part" type="part-type"/>
  <xs:complexType name="part-type">
    <xs:sequence>
      <xs:element name="mfg" type="xs:string"/>
      <xs:element name="price" type="xs:decimal"/>
    </xs:sequence>
    <xs:attribute name="name" type="part-name"/>
  </xs:complexType>
  <xs:simpleType name="part-name">
    <xs:restriction base="xsd:string">
      <xs:pattern value="[A-Z]{2}-\d{3}-[A-Z]*"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>]]></eg>

<p>For this example, we chose an XML document and an XML Schema 
that illustrates the relationship between 
document content and its associated schema type information. 
In general, an XML Schema is not required,
that is, the data model can represent a schemaless, well-formed XML
document with the rules described in <specref ref="types"/>.</p>

<p>The XML document is represented by the data-model constructors below.
The value <emph>D1</emph> represents a document node; 
the values <emph>E1, E2, etc.</emph> represent element nodes; 
the values <emph>A1, ...</emph> represent attribute nodes;
the values <emph>N1, ...</emph> represent namespace nodes;
the values <emph>T1, ...</emph> represent text nodes.
Accessors that return a constant value for that node type are omitted.</p>

<p role="definition">
// Document node D1
dm:base-uri(D1)     =
  <loc href="#xf_anyURI">xf:anyURI</loc>("http://www.example.com/partlist/part0001.xml")
dm:string-value(D1) = <loc href="#xf_string">xf:string</loc>("\n  Acme\n  10.50\n")
dm:typed-value(D1)    [this function invocation raises an error]
dm:children(D1)     = E1

// Element node E1
dm:name(E1)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.example.com/PartSchema","part")
dm:base-uri(E1)     =
  <loc href="#xf_anyURI">xf:anyURI</loc>("http://www.example.com/partlist/part0001.xml")
dm:string-value(E1) = <loc href="#xf_string">xf:string</loc>("\n  Acme\n  10.50\n")
dm:typed-value(E1)    [this function invocation raises an error]
dm:parent(E1)       = D1
dm:children(E1)     = (T1, E2, T3, E3, T5)
dm:attributes(E1)   = A1
dm:namespaces(E1)   = (N1, N2)
dm:type(E1)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.example.com/PartSchema",
                    "part-type")
dm:unique-ID(E1)    = ()

// Attribute node A1
dm:name(A1)         = <loc href="#xf_QName">xf:QName</loc>("name")
dm:string-value(A1) = <loc href="#xf_string">xf:string</loc>("NB-401-nutbolt")
dm:typed-value(A1)  =
  <loc href="#ctor_atomic-value">dm:atomic-value</loc>("NB-401-nutbolt",
    <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.example.com/PartSchema",
                 "part-name"))
dm:parent(A1)       = E1
dm:type(A1)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema","string")

// Attribute node A2
dm:name(A2)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema-instance",
                    "schemaLocation")
dm:string-value(A2) =
  <loc href="#xf_string">xf:string</loc>("http://www.example.com/PartSchema \
             http://www.example.com/PartSchema")
dm:typed-value(A2)  = ()
dm:parent(A2)       = E1
dm:type(A2)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema",
                    "anySimpleType")

// Namespace node N1
dm:name(N1)         = <loc href="#xf_QName">xf:QName</loc>("xsi")
dm:string-value(N1) =
  <loc href="#xf_string">xf:string</loc>("http://www.w3.org/2001/XMLSchema-instance")

// Namespace node N2
dm:name(N2)         = <loc href="#xf_QName">xf:QName</loc>("p")
dm:string-value(N2) =
  <loc href="#xf_string">xf:string</loc>("http://www.example.com/PartSchema")

// Element node E2
dm:name(E2)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.example.com/PartSchema","mfg")
dm:base-uri(E2)     =
  <loc href="#xf_anyURI">xf:anyURI</loc>("http://www.example.com/partlist/part0001.xml")
dm:string-value(E2) = <loc href="#xf_string">xf:string</loc>("Acme")
dm:typed-value(E2)  =
  <loc href="#ctor_atomic-value">dm:atomic-value</loc>("Acme",
    <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema",
                      "string"))
                    = <loc href="#xf_string">xf:string</loc>("Acme")
dm:parent(E2)       = E1
dm:children(E2)     = T2
dm:attributes(E2)   = ()
dm:namespaces(E2)   = (N1, N2)
dm:type(E2)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema","string")
dm:unique-ID(E2)    = ()

// Element node E3
dm:name(E3)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.example.com/PartSchema","price")
dm:base-uri(E3)     =
  <loc href="#xf_anyURI">xf:anyURI</loc>("http://www.example.com/partlist/part0001.xml")
dm:string-value(E3) = <loc href="#xf_string">xf:string</loc>("10.50")
dm:typed-value(E3)  =
  <loc href="#ctor_atomic-value">dm:atomic-value</loc>("10.50",
    <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema",
                      "decimal"))
                    = <loc href="#xf_decimal">xf:decimal</loc>("10.50")
dm:parent(E3)       = E1
dm:children(E3)     = T4
dm:attributes(E3)   = ()
dm:namespaces(E3)   = (N1, N2)
dm:type(E3)         =
  <loc href="#xf_QName-from-uri">xf:QName-from-uri</loc>("http://www.w3.org/2001/XMLSchema",
                    "decimal")
dm:unique-ID(E3)    = ()

// Text node T1
dm:string-value(T1) = <loc href="#xf_string">xf:string</loc>("\n  ")
dm:parent(T1)       = E1

// Text node T2
dm:string-value(T2) = <loc href="#xf_string">xf:string</loc>("Acme")
dm:parent(T2)       = E2

// Text node T3
dm:string-value(T3) = <loc href="#xf_string">xf:string</loc>("\n  ")
dm:parent(T3)       = E1

// Text node T4
dm:string-value(T4) = <loc href="#xf_string">xf:string</loc>("10.50")
dm:parent(T4)       = E3

// Text node T5
dm:string-value(T5) = <loc href="#xf_string">xf:string</loc>("\n")
dm:parent(T5)       = E1
</p>

<p>
A graphical depiction of the data model fragment, containing the
information described in the text above (with the exception of
the namespace nodes), is also included.
</p>
<note><p>
MN: The issue of handling whitespace-only nodes is currently under
discussion. See <specref ref="Issue-0028"/>. Depending on the decisions,
the picture below may change. In particular the whitespace-only nodes
T1, T3, T5 may be omitted from a data model representation.
</p></note>
<p>
<graphic source="DM-example.gif" alt="Graphical depiction of the data
model fragment."/> 
</p>
</inform-div1>

<inform-div1 id="appendix-issues-list">
  <head>Issues</head>
  
  <p>The issues in this section serve as a 
  design history for this document. The ordering of issues is irrelevant. 
  Each issue has a unique id of the form Issue-&lt;dddd&gt; (where d is 
  a digit). This can be used for referring to the issue by 
  &lt;url-of-this-document&gt;#Issue-&lt;dddd&gt;.  Furthermore, each 
  issue has a mnemonic header, a date, an optional description, and an 
  optional resolution. For convenience, resolved issues are displayed 
  in green.  Some of the issues contain references to W3C internal 
  archives. These are marked with "members only". Some of the 
  descriptions of the resolved issues are obsolete w.r.t. to the 
  current version of the document.</p>

<issue id="Issue-0001" date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>PSV Infoset identity constraints</head>
  <description>
    <p>What should be data-model representation, if any, of PSV Infoset
    identity-constraint tables?</p>
  </description>
  <resolution date="17-August-2001">
    <p>JM: Duplicate of <specref ref="Issue-0032"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0002"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Representation of atomic values</head>
  <description>
    <p>This function assumes that the character information items for an
    atomic value (e.g., string, integer, floating-point number) are
    not interleaved with other information items (e.g., PIs or comments).
    The treatment of such interleaved values is not handled in this
    definition.  This issue is addressed in threads beginning at: 
    <loc href="http://lists.w3.org/Archives/Member/w3c-archive/2000Jun/0090.html">
    http://lists.w3.org/Archives/Member/w3c-archive/2000Jun/0090.html (members only)</loc>
    and 
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Sep/0079.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Sep/0079.html (members only)</loc>.</p>
  </description>
  <resolution date="15-Jan-2001"><p>MF: The data model does not
    preserve information items interleaved with the character info items
    of an atomic value.</p>
  </resolution>
</issue>

<issue id="Issue-0003"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Example parent</head>
  <description>
    <p><emph>Remark Michael:</emph> An IDREF cannot point to an empty 
    string.</p>
  </description>
  <resolution date="17-August-2001">
    <p>JM: Issue is obsolete, probably had something to do with Reference
    Nodes, which have been removed.</p>
  </resolution>
</issue>

<issue id="Issue-0004"  date="Oct-2000" raisedby="Datamodel Editors">
  <head>Schema/DTD</head>
  <description>
    <p>A document may refer to a DTD and have an associated schema.
    Currently, content model from the DTD is ignored, as are unique
    IDs from the schema.  A coherent priority or merging strategy
    is needed.</p>
  </description>
</issue>

<issue id="Issue-0005"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Lists of Simple Values</head>
  <description>
    <p>The current data model draft takes only into account
    singleton value-nodes.  It must represent lists of simple-type 
    values as well.  See <loc
    href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000May/0060.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000May/0060.html</loc> (members only).</p>
    <p>Peter suggests having a special-purpose kind of a TextNode that
    represents lists of simple types.
    An advantage of this approach is that the constraint that lists of
    simple types be homogeneous/monomorphic can be enforced. 
    However, lists/forests already can be modeled in current data model, without
    adding more complexity. 
    For example, an attribute's value could be modeled as a list of TextNodes:</p>
    <p role="definition">
    value    : (<loc href="#AttributeNode">AttributeNode</loc>)  -> Sequence&lt;<loc href="#TextNode">TextNode</loc>&gt;
    </p>
    <p>A disadvantage of this approach is that the 
    monomorphism constraint on lists derived from simple types is not
    enforced.
    However, given a type system for Query, such a constraint could
    be enforced.  So Mary is in favor of not having a special-purpose
    kind of TextNode to represent lists, but instead model them by 
    forests directly in the data model.</p>
    <p>JM: note that the pseudo-code doesn't appear to handle schema list
    values.</p>
  </description>
  <resolution date="30-Oct-2001">
    <p><loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0358.html">decision record</loc> (members only).</p>
  </resolution>
</issue>

<issue id="Issue-0006"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Collections</head>
  <description>
    <p>We need a more thorough definition of collections, perhaps 
    in a separate section, which includes bags and defines collections 
    formally.</p>
    <p>In particular, the algebra (probably) will not support arbitrarily
    nested collections (i.e., lists of lists, sets of sets, etc.).  We
    need to specify how collections are constructed.  For example, 
    in the data model, the basic collection is a forest, i.e., a list of
    Nodes.  The forest constructor creates a singleton forest from one
    Node; or it creates a forest from two forests by concatenating
    the two forests:</p>
    <eg>
    Forest = Node | Sequence&lt;Node&gt;

    forest : (Node) -> Forest
    function forest(Node n) =  Sequence&lt;n&gt;

    union : (Forest, Forest) -> Forest
    function union(f1, f2) = list-append f1 f2

    bagunion : (NodeBag, NodeBag) -> NodeBag
    setunion : (NodeSet, NodeSet) -> NodeSet
    </eg>
    <p>Similar constructors would exist for bags with and
    without duplicates.</p>
    <p role="definition">
    unordered : (Forest) -> NodeBag
    unique    : (NodeBag) -> NodeSet
    set = unique o unordered : (Forest) -> NodeSet
    </p>
  </description>
  <resolution date="15-Jan-2001"><p>Added section on Collections
    <specref ref="sequences"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0007"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Text Nodes</head>
  <description>
    <p>An alternative representation is to have a single TextNode 
    whose base type is string:</p>
    <p role="definition">
      text-node  : (xs:string, S, Sequence&lt;Node&gt;) -> <loc href="#TextNode">TextNode</loc>
    </p>
    <p>This representation is more closely aligned with other node types
    in the data model, but it makes the simple type of leaf-node values 
    opaque.</p>
    <p>Peter Fankhauser compares and constrasts these options in : 
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Apr/0174.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2000Apr/0174.html</loc>
    (members only).</p>
  </description>
  <resolution date="30-Oct-2001">
    <p><loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0358.html">decision record</loc> (members only).</p>
  </resolution>
</issue>

<issue id="Issue-0008"  date="Oct-2000" raisedby="Michael Rys" status="closed">
  <head>Node vs edge centric data model</head>
  <description>
    <p><emph>Cite:</emph></p>
    <p>Let me summarize my issues with a node-centric datamodel right 
    at the beginning. The first two are mentioned in the doc
    later on:</p>
    <p>As long as (1) the data represents a tree, (2) easy bi-directional 
    is not required, (3) projection/extension operations with object-preserving
    semantics are not required, a node-centric datamodel is isomorphic to an
    edge-centric datamodel and is easier to represent and understand.</p>
    <p>As soon as anyone of the above requirements change, an edge model 
    has several advantages:</p>
    <olist>
      <item>
        <p>data represents a graph: naming the edges (relationships) 
        becomes a must, since the names are now on the relationships and not 
        on the objects.  Uniform treatment of all edges (even the so far 
        anonymous containment edges) makes defining operations easier since 
        they are more orthogonal. With the possibility of distinguishing 
        "type" from "name", even subelement names now semantically represent 
        relationship names. For example, ShipAddr and BillAddr in</p>
        <p>
          &lt;Order&gt;
            &lt;ShipAddr dt:dt="Address"&gt;...&lt;/ShipAddr&gt;
            &lt;BillAddr dt:dt="Address"&gt;...&lt;/BillAddr&gt;
          &lt;/Order&gt;
        </p>
        <p>are denoting relationships (ownership to be exact) from the 
        order element to the Address elements.</p>
      </item>
      <item>
        <p>As soon as backwards pointers are introduced into a 
        node-centric model, the representation becomes more complex and 
        less elegant. Transforming data becomes more complex since the 
        backwards pointer becomes part of the object state. Thus, if I 
        define views where an element changes the parent, in the
        edge-centric case, this just adds a new relationship, the object 
        state is unchanged, in the node-centric approach, I need to 
        express now two parents in the object state.</p>
      </item>
      <item>
        <p>Projection/extension operations. Assume that I pose a query 
        that projects name and address but hides the age of a person 
        element. In the edge-centric approach, this means that the 
        query logically transforms the graph context on which the query 
        operates by removing the age edge from the context without 
        touching the object state (the objects keeps its basetype),
        in the node-centric approach, the object state needs to change 
        since the context transformation will remove the attribute 
        property age. While both operations transform the context, 
        I find the former to be more elegant than the later.</p>
      </item>
    </olist>
  </description>
  <resolution date="15-Jan-2001">
    <p>MF: To align with XPath 1.0 and the Algebra,
    the data model is node centric.</p>
  </resolution>
</issue>

<issue id="Issue-0009"  date="Oct-2000" raisedby="Michael Rys" status="closed">
  <head>Schema info</head>
  <description>
    <p><emph>Cite:</emph>Sometimes one wants to use different schemata 
    over the same basic XML fragment. So I would rather start with that 
    in principle, the data model is schemaless and can provide the data 
    model of any XML fragment given a schema.  Thus, the schema 
    postprocessing becomes a datamodel transformation that we make 
    explicit (and that could be optimized with other operations that
    transform the datamodel graph).</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: This was an alternate design to the named typing proposal.
    With the acceptance of the named typing this isssue is closed.
    When using a different schemata over the same XML fragment (by
    invoking validate, see <bibref ref="XQFS"/>) a new instance is
    constructed and there is no need for postprocessing.</p>
  </resolution>
</issue>

<issue id="Issue-0010"  date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Node identity</head>
  <description>
    <p>Should the data model require that an implementation guarantee 
    that the identity of a node is always preserved?</p>
  </description>
  <resolution date="15-Jan-2001">
    <p>MF: The data model always preserves node identity; the only 
    operator that does not preserve node identity is <code>copy</code>.</p>
  </resolution>
</issue>

<issue id="Issue-0011" date="Oct-2000" raisedby="Datamodel Editors" status="closed">
  <head>Access to facets</head>
  <description>
    <p>In XML Schema, facets such as "nullable" is associated with 
    an <emph>element declaration</emph>, which is an element name, 
    complex type pair.   If the query language needs access to such 
    facets, we may need to replace <emph>ReferenceNode</emph> by a 
    reference to the element declaration.</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model represents named types as expanded-QNames.
    This way it supports type-related operations, but the semantics of such
    operations and the information that must be available to support them
    (e.g. facets) is described in the <bibref ref="XQFS"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0012"  date="Oct-2000" raisedby="Michael Rys" status="closed">
  <head>Representation of reference values</head>
  <description>
    <p><emph>Cite:</emph>  The current representation of reference 
    values is too much IDREF(S) centric. I would prefer a more general 
    representation for XLink and the schema (and potentially graph 
    operation) introduced reference mechanisms.</p>
  </description>
  <resolution date="13-August-2001">
    <p>JM: Removed reference nodes.</p>
  </resolution>
</issue>

<issue id="Issue-0013" date="17-Jan-2001" raisedby="Mary Fernandez" status="closed">
  <head>Equality operators on collections</head>
  <description>
    <p>Equality operators '=' on collections are not defined.</p>
  </description>
  <resolution date="27-March-2001">
    <p>MF: Added Functions (subsequently removed to Functions and Operators spec).</p>
  </resolution>
</issue>

<issue id="Issue-0014" date="17-Jan-2001" raisedby="Mary Fernandez" status="closed">
  <head>Elements with unordered children</head>
  <description>
    <p>Should the element constructor 
    <loc href="#element-node">element-node</loc> also permit bags of 
    children?</p>
  </description>
  <resolution  date="13-April-2001">
    <p>MF: decision to use sequences everywhere in data model.</p>
  </resolution>
</issue>

<issue id="Issue-0015" date="02-Feb-2001" raisedby="Mary Fernandez" status="closed">
  <head>Semantics of value equality operator '='</head>
  <description>
    <p>The semantics of the value equality operator '=' are undefined.</p>
  </description>
  <resolution  date="17-August-2001">
    <p>JM: Defined in the Functions and Operators document.</p>
  </resolution>
</issue>

<issue id="Issue-0016" date="21-Feb-2001" raisedby="Michael Rys" status="closed">
  <head>PSV Infoset Mapping - undefined terms</head>
  <description>
    <p><code>Code</code> is undefined. </p>
  </description>
  <resolution date="25-Apr-2001">
    <p>Defined in <specref ref="TextNode"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0017" date="03-Mar-2001" raisedby="Mary Fernandez" status="closed">
  <head>Relationship between Ordered and Unordered collections</head>
  <description>
    <p>The relationship between ordered and unordered collections is 
    not specified.  Any ordered collection can be treated as an 
    unordered collection.</p>
  </description>
  <resolution date="25-Apr-2001">
    <p>Unordered collections removed.</p>
  </resolution>
</issue>

<issue id="Issue-0018" date="12-Mar-2001" raisedby="Michael Rys" status="closed">
  <head>Representation of lists of IDREFS and NMTOKENS</head>
  <description>
    <p>How are IDREF lists and NMTOKEN lists represented in
    data model.</p>
  </description>
  <resolution date="17-August-2001">
    <p>JM: Duplicate of <specref ref="Issue-0005"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0019" date="15-Mar-2001" raisedby="James Clark" status="closed">
<head>Element constructor that performs schema processing</head>
<description>
  <p>An alternate is to separate element construction from schema 
  validity assessment.  The element constructor would construct an 
  element corresponding to the an element information item in the Infoset 
  before schema validity assessment. 
  To produce elements with types, the <code>schema-process</code> function 
  would schema process an element with respect to a schema type to yield a 
  new element with the full PSV infoset. The <code>schema-process</code> 
  function would ignore any type information on attributes and elements and 
  would assess the untyped value with respect to the given type.</p>
  
  <p role="definition">
element-node  : (<loc href="#dt-atomic-value">xs:QName</loc>, 
                 Sequence&lt;<loc href="#NamespaceNode">NamespaceNode</loc>&gt;,
                 Sequence&lt;<loc href="#AttributeNode">AttributeNode</loc>&gt;, 
                 Sequence&lt;<loc href="#ElementNode">ElementNode</loc> | <loc href="#ProcessingInstructionNode">ProcessingInstructionNode</loc> 
                         | <loc href="#TextNode">TextNode</loc> | <loc href="#CommentNode">CommentNode</loc>&gt;)
              -> <loc href="#ElementNode">ElementNode</loc>
schema-process : (<loc href="#ElementNode">ElementNode</loc> | <loc href="#AttributeNode">AttributeNode</loc>, <loc href="#dt-atomic-value">SchemaComponent</loc>) 
               -> <loc href="#ElementNode">ElementNode</loc> | <loc href="#AttributeNode">AttributeNode</loc>
  </p>
</description>
  <resolution date="19-July-2002">
    <p>MN: The working groups decided not to pursue this alternate design.
    It is noted though that using the current constructors with the type
    set to either xs:anyType or to a more specific type makes them similar
    to either the first or the second function proposed here.</p>
  </resolution>
</issue>

<issue id="Issue-0020" date="27-Mar-2001" raisedby="Michael Kay" status="closed">
  <head>Semantics of <code>copy</code></head>
  <description>
    <p>Deep copy on a node is defined only informally. For example, 
    does deep copy preserve base URI?</p>
  </description>
  <resolution  date="17-August-2001">
    <p>JM: Obsolete - copy function removed (not used).</p>
  </resolution>
</issue>

<issue id="Issue-0021" date="27-Mar-2001" raisedby="XPath 2.0 Task Force" status="closed">
  <head>Declared vs. In-scope namespaces</head>
  <description>
    <p>Currently, an element node preserved its declared namespace 
    nodes, not its in-scope namespaces.  Members of the XSLT WG 
    point out this may make impossible to determine the meaning of 
    data-model values that refer to the default namespace.  This is 
    a big, nasty problem.</p>
  </description>
  <resolution  date="17-August-2001">
    <p>JM: Element constructor uses in-scope namespaces.</p>
  </resolution>
</issue>

<issue id="Issue-0022" date="27-Mar-2001" raisedby="XPath 2.0 Task Force
(Steve Zilles)" status="closed">
  <head>Abstraction of Run-time type information</head>
  <description>
    <p>The representation of run-time type information is very 
    concrete -- it's the data model representation of a Schema type.  
    The XPath task force would like a more abstract representation of 
    runtime type that is not bound so tightly to XML Schema.   This 
    is an open design problem.</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model currently represents named types in a more
    abstract manner, as expanded-QNames.</p>
  </resolution>
</issue>

<issue id="Issue-0023" date="27-Mar-2001" raisedby="XPath 2.0 Task Force">
  <head>Support for document repositories</head>
  <description>
    <p>Many people would like to see support for document repositories 
    in XPath 2.0 with a corresponding notion in the data model.
    A document repository is easy to model as a sequence or bag of
    document nodes.  It may have some additional properties, like for 
    an ordered repository, order among all the nodes in the repository.</p>
  </description>
</issue>

<issue id="Issue-0024" date="27-Mar-2001" raisedby="Michael Sperberg-McQueen">
  <head>Support for Schema-invalid documents</head>
  <description>
    <p>In its current state, the data model clearly does not cover 
    schema-invalid documents:  section 3.3 says "We assume that the 
    element is an instance of the type represented by Def-Type, i.e., 
    the document 'type checks' or is valid with respect to the
    given schema."</p>

    <p>I believe we may wish to extend / modify the data model
    to specify that:</p>

    <olist>
      <item>
        <p>if the element is marked valid (i.e. if the [validity]
        property for the element information item has the value
        "valid"), then we assume that the element is an instance
        of the type represented by Def-Type</p>
      </item>
      <item>
        <p>otherwise, if the element is marked invalid (i.e. the
        [validity] property has the value "invalid" or "notKnown"),
        and if the element has neither attributes nor child elements,
        then we assume [observe] that the element is an instance
        of the type anySimpleType</p>
      </item>
      <item>
        <p>otherwise, we assume that the element is an instance of 
        the type anyType</p>
      </item>
    </olist>

    <p>This would allow / require schema systems to be robust in the
    face of invalid documents.  At first glance, that seems like a
    win.</p>
  </description>
  <resolution date="05-March-2001">
    <p>The data model answers the above issue in the following way:
    Section 3.3 specifically states that the data model supports
    incompletely validated documents.
    Section 3.4 (formerly 8.1) describes a function used in the
    pseudo-code segments that maps the elements with the different
    [validity] properties to the appropriate types.
    The mapping is inline with the solution suggested by the issue
    above.
    For further details see the
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Mar/0029.html">discussion thread</loc>
    and 
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Mar/0011.html">decision record</loc>
    (members only).
    </p>
  </resolution>
</issue>

<issue id="Issue-0025" date="27-Apr-2001" raisedby="Mike Kay">
  <head>Types of Sequences</head>
  <description>
    <p>Should sequence values carry their type as do 
    simple typed values and element and attribute nodes?</p>
  </description>
</issue>

<issue id="Issue-0026" date="27-Apr-2001" raisedby="Mary Fernandez" status="closed">
  <head>Schema Component Values vs. Nodes</head>
  <description>
    <p>If schema component values becomes nodes, then 
    does that mean they can occur any where in a document tree?
    I.e., can they be children of other nodes?  What does this mean
    when a data model is serialized as a document?</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model represents named types as expanded-QNames.
    They can be associated with element nodes, attribute nodes and
    atomic values. Consequently the question raised by the issue no
    longer applies.</p>
  </resolution>
</issue>

<issue id="Issue-0027" date="01-May-2001" raisedby="Mary Fernandez" status="closed">
  <head>Lexical representation of simple-typed values</head>
  <description>
    <p>Given a simple-typed value, it may be necessary to recover
    its lexical representation, for example, when creating a text node 
    that contains the value.  It is not always possible to compute a
    unique lexical representation of a simple typed value.</p>
  </description>
  <resolution date="05-December-2001">
    <p>Changed the definition of the string-value accessor to return
    the canonical lexical representation of the simple typed value (as
    defined by XML Schema Part 2: Datatypes).
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0046.html">decision record</loc> (members only)</p>
  </resolution>
</issue>

<issue id="Issue-0028" date="04-May-2001" raisedby="Jonathan Marsh">
  <head>Whitespace handling</head>
  <description>
    <p>Whitespace handling needs to be more explicit.  In the 
    presence of a schema we have full knowledge of which whitespace is 
    significant and which isn't, and can either mark whitespace as 
    insignificant (and thus exclude it from text() and string-range() 
    for instance), or automatically suppress whitespace in the data model.  
    The former is appropriate given the dual representation of text nodes 
    and values, the latter is appropriate if we only expose values.</p>
  </description>
</issue>

<issue id="Issue-0029" date="04-May-2001" raisedby="Jonathan Marsh" status="closed">
  <head>Use of Reference Nodes</head>
  <description>
    <p>Reference nodes may be part of the data model, but will never 
    appear from a mapping from the infoset.  In addition they cannot be
    serialized.  Without these two features there doesn't seem to be
    much point in having them.  Should we leverage an existing syntax
    (e.g. IDREFS) or design a new syntax to represent them?</p>
  </description>
  <resolution date="13-August-2001">
    <p>Removed Reference Nodes.</p>
  </resolution>
</issue>

<issue id="Issue-0030" date="04-May-2001" raisedby="Jonathan Marsh">
  <head>Base URI is a property of element nodes</head>
  <description>
    <p>With external entities, and now with XML Base, the base URI can
    be scoped to various parts of the document.  A base URI property should
    be added to Element Nodes, and the constructor and infoset mapping
    updated.  Otherwise relative URIs in content cannot be correctly
    resolved.</p>
    <p>Processing instructions also require an infoset-derived base URI.
    The base URI of attributes, for instance, should probably not be the
    empty sequence, if that does not adequately imply that the base URI
    of the element should be used instead.</p>
  </description>
</issue>

<issue id="Issue-0031" date="17-May-2001" raisedby="Ashok Malhotra" status="closed">
  <head>Schema component does not reveal [content] property</head>
  <description>
    <p>Schema component does not reveal [content] property of <bibref
    ref="XSFD"/> schema component.  MF: Problem with revealing
    [content] property is that we/Schema/Query have to agree on syntax
    for component content (Sec 2.2.1 in <bibref ref="XSFD"/>).  </p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model represents named types as expanded-QNames.
    This way it supports type-related operations, but the semantics of such
    operations and the information that must be available to support them
    (e.g. [content] property) is described in the <bibref ref="XQFS"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0032" date="17-May-2001" raisedby="Query">
  <head>Keys and key references not represented</head>
  <description>
    <p>Note that the data model does not currently represent
    key values and key reference values as described in XML Schema Part 1 : 
    Structures  <bibref ref="xmlschema-1"/>. In a future draft of this 
    document, keys and key references will be represented in the data 
    model.</p>
  </description>
</issue>

<issue id="Issue-0033" date="28-April-2001" raisedby="James Clark">
  <head>Unclear relationship between values passed to the constructor, 
  and those returned by the accessor</head>
  <description>
    <p><loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0312.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Apr/0312.html</loc> (members only).
    Asks for inference rules, especially for the constuctor, describing
    when values returned by an accessor are the same as those set by the
    corresponding constructor.  Especially unclear are when adjacent
    text nodes are collapsed, base URI and namespace declarations.</p>
  </description>
</issue>

<issue id="Issue-0034" date="8-May-2001" raisedby="Michael Kay">
  <head>Interaction of insignificant whitespace with comments</head>
  <description>
    <p><loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0053.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0053.html</loc> (members only).
    Clarify whether whitespace is classified as insignificant before 
    or after PI and comment removal.</p>
  </description>
</issue>

<issue id="Issue-0035" date="8-May-2001" raisedby="XSL WG (Michael Kay)">
  <head>Eliminate heterogeneous sequences</head>
  <description>
    <p><loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0054.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0054.html</loc> (members only),
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0048.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001May/0048.html</loc> (members only).
    Simplify operations such as distinct() by disallowing sequences mixing
    nodes and simple typed values. Suggests converting nodes in such a 
    heterogeneous sequence to their typed values.</p>
  </description>
</issue>

<issue id="Issue-0036" date="19-July-2001" raisedby="XSL WG" status="closed">
  <head>Support for abstract types</head>
  <description>
    <p>xsd:anySimpleType (and other abstract types) are not supported
    in the data model.  The string-value of an xsd:anySimpleTyped is
    apparently the empty sequence - indicating that you can't really
    do useful operations on anySimpleType'd values.  However, we
    apply a default schema which assigns xsd:anySimpleType, resulting
    in a proliferation of these types.  How can we operate on these
    documents?  Should we at least return a non-empty string-value() 
    for an anySimpleType? Should we define additional operations such
    as +, *, for compatibility with XPath 1.0?</p>
  </description>
  <resolution date="25-July-2002">
    <p>MN: The data model now supports xs:anySimpleType and xs:anyType.
    The typed-value() of elements or attributes of this type is the
    string-value() as xs:anySimpleType.
    The semantics of the operations on atomic values of type xs:anySimpleType
    is defined in <bibref ref="XQuery"/> and  <bibref ref="XPath2"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0037" date="19-July-2001" raisedby="XSL WG">
  <head>Axis functions</head>
  <description>
    <p>Define (somewhere other than the data model document?) 
    axis functions for non-primitive axes like descendants-or-self.</p>
  </description>
</issue>

<issue id="Issue-0038" date="13-August-2001" raisedby="Datamodel Editors">
  <head>XPath 1.0 treatment of non-unique IDs</head>
  <description>
    <p>From XPath 1.0: "If an XML processor reports two elements in 
    a document as having the same unique ID (which is possible only 
    if the document is invalid) then the second element in document 
    order must be treated as not having a unique ID."  This has not
    been incorporated into this document.</p>
  </description>
</issue>

<issue id="Issue-0039" date="13-August-2001" raisedby="Datamodel Editors">
  <head>Parent of namespace nodes</head>
  <description>
    <p>In XPath 1.0 namespace nodes have a parent.  Should we adopt the
    XPath 1.0 behavior, the current behavior (no parent), or some other
    parent (e.g. the document)?</p>
  </description>
</issue>

<issue id="Issue-0040" date="15-August-2001" raisedby="Jim Melton">
  <head>Setting and examining construction flags</head>
  <description>
    <p>[Jim] found [him]self wondering how those flags (parameters) get 
    set/passed.  More importantly, can a process ask whether 
    "this instance" of the data model has those flags set or not? 
    If so, how?  If not, why not?</p>
  </description>
</issue>

<issue id="Issue-0041" date="15-August-2001" raisedby="Jonathan Marsh" status="closed">
  <head>Document node permissiveness unnecessary</head>
  <description>
    <p>What are the use cases for being permissive about children of the
    document node?  According to the note above, sequences of elements
    do not need a container node.  Suggest removing this permissiveness.</p>
  </description>
  <resolution date="04-Apr-2002">
    <p>MN: The working groups decided to keep the document node permissiveness
    to support "well-balanced" trees.
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0021.html">decision record</loc> (members only).</p>
  </resolution>
</issue>

<issue id="Issue-0042" date="15-August-2001" raisedby="Jim Melton">
  <head>System Id and Public Id are not exposed</head>
  <description>
    <p>In our model, there is no way for a query to determine what DTD is 
    relevant for the data model instance.  That seems like a piece of 
    information that might be wanted occasionally (though probably not 
    often).</p>
  </description>
</issue>

<issue id="Issue-0043" date="15-August-2001" raisedby="Jonathan Marsh" status="closed">
  <head>Treatment of common accessors inconsistent</head>
  <description>
    <p>In some cases, when an accessor is inappropriate for a node, we
    omit that accessor.  In other cases, we define it to always return
    the empty sequence.  We need to rationalize these two design patterns.</p>
  </description>
  <resolution date="30-Oct-2001">
    <p>Use empty sequence throughout. <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0358.html">decision record</loc> (members only).</p>
  </resolution>
</issue>

<issue id="Issue-0044" date="15-August-2001" raisedby="Jonathan Marsh">
  <head>Unable to construct an element with unique ID</head>
  <description>
    <p>The unique ID property is defined on an element node, but is a function
    of an attribute information item.  When an element node is constructed
    it is given an attribute node - not an info item.  An attribute node
    is insufficient to remember the appropriate properties from the
    infoset in order for the element constructor to detect when an
    attribute is an ID declared in the DTD.</p>
  </description>
</issue>

<issue id="Issue-0045" date="17-August-2001" raisedby="Jim Melton">
  <head>Text nodes are not W3C-normalized text</head>
  <description>
    <p>The <loc href="http://www.w3.org/TR/charmod/">Character
    Model for the World Wide Web version 1.0</loc> working draft defines
    W3C-normalized text.  The algorithm for constructing text nodes
    from character information items does not perform normalization to
    this form.  Should it?</p>
  </description>
</issue>


<issue id="Issue-0046" date="17-August-2001" raisedby="Jim Melton" status="closed">
  <head>Value of derived types?</head>
  <description>
    <p>In XML Schema, the type unsignedInt is a simple type, but 
    it's a derived type (not a primitive type); the nearest 
    corresponding primitive type is decimal.  If I were to invoke 
    the value accessor with something analogous to "value(cast as 
    unsignedInt('10'))", does it return a decimal value, and is 
    the SchemaComponent returned by type a component that 
    describes decimal?  I do not believe that this a non-issue 
    because the only types supported in the data model are XPath 
    1.0's types (string, number, boolean, and node-set), since 
    this document makes a strong point about using all of 
    Schema's simple types.  Thus, does value return the primitive 
    value, or does it return something like the schema-normalized 
    value of the specified simple type?</p>
  </description>
  <resolution date="05-December-2001">
    <p>Simple typed values encapsulate both the value and the type.
    The type of an unsignedInt is the SchemaComponent corresponding to
    the unsignedInt. The string representation on the other hand is the
    value's canonical lexical representation for the base type (which is a
    primitive type) as specified by XML Schema.
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0046.html">Decision record</loc> (members only).</p>
  </resolution>
</issue>

<issue id="Issue-0047" date="17-August-2001" raisedby="Jim Melton" status="closed">
  <head>Should errors be allowed in sequences?</head>
  <description>
    <p>The possibility that generating sequences in which one or more 
    members are Error may sometimes be a useful way to produce partial 
    results that can satisfy some sorts of queries.</p>
  </description>
  <resolution date="22-July-2002">
    <p>MN: The error value has been removed from the data model.
    This issue is now mute.</p>
  </resolution>
</issue>

<issue id="Issue-0048" date="17-August-2001" raisedby="Jim Melton" status="closed">
  <head>Imprecise behavior of errors</head>
  <description>
    <p>I am very concerned that "How the error value is handled in a 
    query processor is implementation-defined."  I think we have to 
    do a bit better than this, although leaving flexibility for 
    implementations to do more for their users is a Good Thing.</p>
  </description>
  <resolution date="22-July-2002">
    <p>MN: The error value has been removed from the data model.
    The error behavior is described in <bibref ref="XPath2"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0049" date="17-August-2001" raisedby="James Clark" status="closed">
  <head>Alternative design of schema components</head>
  <description>
    <p>MF cite James: 
    An alternative would be to have an extends accessor
    that returns deref([base]) if [derivation] is extension and empty
    sequence otherwise, and a restricts accessor that returns deref([base])
    if [derivation] is restriction and empty sequence otherwise.</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: This proposal is not in the scope of the data model:
    The data model represents named types as expanded-QNames.
    The semantics of the type operations and the information that must be
    available to support them is described in the <bibref ref="XQFS"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0050" date="17-August-2001" raisedby="Jim Melton">
  <head>Relative order of free-floating nodes</head>
  <description>
    <p>Are newly-constructed nodes in any particular order, such 
    as some kind of document order?  Does the order of these 
    nodes have any relationship to the document order of the 
    "input" data model instance?  In fact, is the process being 
    described properly characterized as "create a new data model 
    instance from information derived from an existing data model 
    instance", or something similar?  Can more than one "new" 
    document instance be created by a single query?  In the 
    fourth paragraph [Section 4], we see the phrase "the document node" --- 
    is this the "existing document"'s document node, the "new 
    document"'s document node, both, neither?  Can more than one 
    "existing" document instance be the source of information for 
    a query?</p>
  </description>
</issue>

<issue id="Issue-0051" date="28-August-2001" raisedby="Michael Kay">
  <head>Document order of shared namespace nodes</head>
  <description>
    <p>Section 3.2 states that in the document ordering, the namespace 
    nodes of an element follow the element but precede its attributes. 
    This is inconsistent with the idea, suggested but not spelled out in 
    4.4, that a namespace node can be shared by several elements. In fact, 
    the question of namespace node identity is not really tackled. My view 
    is that namespace node identity should be determined by the 
    combination of (document identity, namespace prefix, namespace URI), 
    that the parent of a namespace node should be the document node, and 
    that namespace nodes should be ordered after every other node in the 
    document. (This is easier for implementations than placing them at the 
    start of the document, because the number of namespace nodes is not 
    known until parsing is complete).</p>
  </description>
</issue>

<issue id="Issue-0052" date="28-August-2001" raisedby="Michael Kay">
  <head>Element constructor copies nodes?</head>
  <description>
    <p>In section 4.2 Elements, the notion that the constructor makes a 
    copy of the supplied child nodes seems strange. It's hard to square 
    this with the definition of node identity. Also, I don't see why the 
    provision is needed here, but not for the document node constructor. 
    Wouldn't it be cleaner to define a precondition that all the child 
    nodes supplied to the constructor must be parentless?</p>
  </description>
</issue>

<issue id="Issue-0053" date="28-August-2001" raisedby="Michael Kay" status="closed">
  <head>Semantics of head and tail on empty sequences</head>
  <description>
    <p>Head would appear to be a partial function, it does 
    not apply to empty sequences. If we follow the same conventions as 
    elsewhere, that means head returns a Sequence(0,1)&lt;item&gt;, which 
    perhaps begs the question as to how you extract the first member of 
    this sequence...</p>
  </description>
  <resolution date="18-November-2001">
    <p>Replaced the accessors head and tail by the some of the sequence
    accessors defined in the Functions and Operators document. </p>
  </resolution>
</issue>

<issue id="Issue-0054" date="6-September-2001" raisedby="Evan Lenz" status="closed">
  <head>Complex types with simple content</head>
  <description>
    <p>Currently, the typed-value of a complex type is the empty sequence.
    Should complex types with simple content (i.e. an element that contains
    only text but that also has an attribute) be treated differently than
    complex types with complex content?</p>
  </description>
  <resolution date="19-February-2001">
    <p>Now typed-value corresponds to the
    <emph role="infoset-property">schema normalized value</emph>
    PSVI property if that exists, or the empty sequence otherwise.
    This way if an element has a complex type with simple content
    its typed-value may be something other than the empty sequence.
    For further details see the
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0100.html">discussion thread</loc>
    and 
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0191.html">decision record</loc>
    (members only).
    </p>
  </resolution>
</issue>

<issue id="Issue-0055" date="6-September-2001" raisedby="XSL WG" status="closed">
  <head>Effect of xsi:nil</head>
  <description>
    <p>The XSL WG wishes xsi:nil="true" to result in a typed-value
    of the empty sequence.  This allows the differentiation of a null
    string value and an empty string.</p>
  </description>
  <resolution date="07-December-2001">
    <p>This is a duplicate of the resolved XPath Issue 0021: Handling of
    xsi:nil on Input. See the <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html">review of the XPath issues</loc> (members only).
    Accordingly closed this issue, updated the document to reflect the
    decision and added the related data model Issue-0071.
    </p>
  </resolution>
</issue>

<issue id="Issue-0056" date="20-September-2001" raisedby="XPath TF" status="closed">
  <head>Lightweight Schema Components</head>
  <description>
    <p>Summary:  The only necessary operation on Schema Components is
    instance-of(schema-component1, schema-component2).  There is no need to
    expose the internal structure of Schema Components to enable this
    functionality.  Instead we could provide an abstract Type object whose
    internal structure can be treated as a black box.  See
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Jul/0042.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Jul/0042.html</loc> (members only).</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model represents named types as expanded-QNames,
    which is inline with the suggestion of the issue.</p>
  </resolution>
</issue>

<issue id="Issue-0057" date="25-September-2001" raisedby="Michael Kay">
  <head>Support for XSLT whitespace stripping</head>
  <description>
    <p>XSLT allows a stylesheet to designate elements whose whitespace
    is to be stripped.  We need to support this in the data model, or
    possibly elsewhere.</p>
    <p>Similarly, a data model instance for a stylesheet has provisions
    for stripping comments and processing instructions.</p>
  </description>
</issue>

<issue id="Issue-0058" date="25-September-2001" raisedby="Michael Kay">
  <head>Node constructors formalism of questionable value</head>
  <description>
    <p>Node constructors. I'm a bit concerned that this is lacking in rigor.
    Some of this is exposed in <specref ref="Issue-0050"/>. The idea that 
    the constructor for a parent node (Element or Document) takes a copy 
    of the supplied children node doesn't seem to be fully worked out. 
    What does "taking a copy" mean, where is it defined? It has to be a 
    deep copy to make sense; it has to preserve its name, its type, and 
    its children, but not its base URI or its node identity, and it 
    acquires a new position in document order. What happens about
    the namespace nodes when an element or attribute is copied? Altogether,
    I'm worried that this idea of node constructors looks formal, but 
    is actually just as informal as the 1.0 specification. It's actually 
    a very procedural description, and I can't really see why it's needed: 
    if it's intended as a target vocabulary for the formal semantics of 
    the language, then it's a pretty shaky foundation. I'd be much happier 
    with a model that only defines the valid states in the system; if we 
    are going to define the permitted state transitions, we need to be 
    much more rigorous about it.</p>
  </description>
</issue>

<issue id="Issue-0059" date="25-September-2001" raisedby="Michael Kay">
  <head>Pseudo-formalism provides no value</head>
  <description>
    <p>"The sequence-map function applies its first function argument to each
    member of its second sequence argument and returns a new sequence
    containing
    the result of applying the function to each member of the sequence." I
    really wonder whether it is a good idea to define the data model using a
    pseudo-formal language that we make up and half-explain as we go along? If
    we can't use an existing formal notation like Z or VDM that has a good
    specification we can reference, we should do the whole thing in English.</p>
  </description>
</issue>

<issue id="Issue-0060" date="25-September-2001" raisedby="Michael Kay">
  <head>Sharing namespace nodes</head>
  <description>
    <p>We need to say something about the identity of namespace
    nodes, and about the fact that two namespace nodes for the same prefix 
    and uri may need to be combined when an element is added to a document. 
    Also "the element constructor logically creates a copy of all of its
    namespace..." - namespace nodes do not need to be copied(?)</p>
  </description>
</issue>

<issue id="Issue-0061" date="25-September-2001" raisedby="Michael Kay">
  <head>No access to prefix on free-floating attributes</head>
  <description>
    <p>An observation: if an attribute node has no parent element (a 
    floating attribute), then there is also no access to any namespace 
    nodes. This makes it impossible to support the XPath 1.0 name() 
    function, which returns a lexical QName for the node by finding a 
    prefix that maps to the node's namespace URI.</p>
    <p>[JM: Sounds like we need a QName object that is a triple, local-name,
    namesapce-uri, and prefix, to support XSLT.]</p>
  </description>
</issue>

<issue id="Issue-0062" date="16-October-2001" raisedby="Michael Kay">
  <head>Namespace fixups required</head>
  <description>
    <p>The current XSLT draft includes a substantial piece of text on
    namespace fixup. This was introduced in the XSLT 1.1 working draft, 
    and is basically designed to ensure that when an element or attribute 
    is added to a result tree, namespace nodes are also added to declare 
    any namespace URI used by the element or attribute. (At XSLT 1.0, 
    this was handled at serialization time, but this had to change when 
    temporary trees became accessible to the stylesheet). The description 
    of namespace fixup logically belongs with the description of the node 
    construction process in the data model document.
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html</loc> (members only).</p>
  </description>
</issue>

<issue id="Issue-0063" date="16-October-2001" raisedby="Michael Kay">
  <head>Is prefix preserved?</head>
  <description>
    <p>Although XSLT and the XPath 2.0 data model agree that element and 
    attribute nodes do not hold a namespace prefix, XSLT has always hinted 
    that prefixes might be preserved through a transformation where possible. 
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0036.html</loc> (members only).</p>
    <p>[JM: the ability to recover the lexical value of an xs:QName simple
    type seems useful, perhaps even necessary.  It is at least needed to
    support the name() function.  A better description of the xs:QName 
    accessors is required, perhaps unifying xs:QName and expanded-QName.]</p>
  </description>
</issue>

<issue id="Issue-0064" date="16-October-2001" raisedby="Jeni Tennison" status="closed">
  <head>Including type definition in element constructors</head>
  <description>
    <p>The constructor for the element node probably should include the type
    definition in the constructor as well, for cases where the [type
    definition] of the element information item is not the same as the
    [type definition] of the [element declaration], which can occur if
    xsi:type is used in the document.
    Should the same be done for attribute node constructors for
    consistency, (even though attributes cannot have xsi:type attributes)?
    <loc href="http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Sep/0012.html">http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Sep/0012.html</loc>.</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The definition of the element an attribute constructors have
    been changed to take an xs:QName that represents the type definition
    and not the element or attribute declaration.
    The type definition can be either the [type definition] of the
    element information item or the more specific [type definition] of
    the [element declaration] when xsi:type is used.</p>
  </resolution>
</issue>

<issue id="Issue-0065" date="19-November-2001" raisedby="Mary Fernandez" status="closed">
  <head>Proposal for alternative constructor</head>
  <description>
    <p>The element and attribute constructors are not convenient when 
    constructing elements or attributes with simple-type content.  An
    alternative constructor that takes a typed value directly (instead of
    only text nodes or normalized string values) would simplify
    dependent specifications.
    <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0068.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0068.html</loc> (members only).</p>
  </description>
  <resolution date="05-December-2001">
    <p>Add the two new constructors proposed by Mary with the change that
    the element/attribute declarations are not optional and they are named
    differently (so we won't overload the constructors).
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0046.html">decision record</loc> (members only)</p>
  </resolution>
</issue>

<issue id="Issue-0066" date="29-November-2001" raisedby="Ashok Malhotra" status="closed">
  <head>SchemaComponent support for substitutions groups</head>
  <description>
    <p>SchemaComponents currently don't expose any substitution group 
    information.
    <loc href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Nov/0358.html">http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Nov/0358.html</loc> (members only).</p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The data model represents named types as expanded-QNames.
    This way it supports type-related operations, but the semantics of such
    operations and the information that must be available to support them
    (e.g. substitution groups) is described in the <bibref ref="XQFS"/>.</p>
  </resolution>
</issue>

<issue id="Issue-0067" date="5-December-2001" raisedby="Marton Nagy" status="closed">
  <head>Align function call syntax</head>
  <description>
    <p>The syntax of the function calls need to be aligned with the other
    working documents, in particular the Functions and Operators and the
    XQuery documents. Possible candidates are f:(T1,T2)-&gt;T or
    f(T1 $v1, T2 $v2)=&gt;T. </p>
  </description>
  <resolution date="26-March-2002">
    <p>MN: The pseudo-calls and examples now use the XQuery syntax.</p>
  </resolution>
</issue>

<issue id="Issue-0068" date="4-December-2001" raisedby="XPath Task Force" status="closed">
  <head>Retaining the type of a sequence of heterogeneous simple typed values.</head>
  <description>
    <p>When a sequence of heterogeneous simple typed values is passed as
    the content of an element constructor, is the type information associated
    with the simple typed values preserved? e.g. when using a sequence
    containing a decimal, a string and a boolean are these types preserved
    (or possibly changed to anySimpleType* ?). Note that XML Schema cannot
    describe this former. Related to this, should we ever allow an element
    constructor to create an instance that can not be serialized as XML
    text without loss of type information?  
    </p>
  </description>
  <resolution date="22-July-2002">
    <p>MN: As a result of the adoption of Alternative 1 for element/attribute
    constructors, the data model no longer provides constructors accepting
    a sequence of atomic values as arguments. The current constructors
    can only create instances whose type can be described by XML Schema.
    </p>
  </resolution>
</issue>

<issue id="Issue-0069" date="4-December-2001" raisedby="XPath Task Force">
  <head>Canonical form for derived types.</head>
  <description>
    <p>Should derived types have a canonical form? Should we ask XML Schema
    to fix this?</p>
  </description>
</issue>

<issue id="Issue-0070" date="5-December-2001" raisedby="XPath Task Force">
  <head>Should the name accessor return "" or ()?</head>
  <description>
    <p>Should the name accessor return "" or () for nodes that have no name?</p>
  </description>
</issue>

<issue id="Issue-0071" date="7-December-2001" raisedby="Michael Rys">
  <head>Magic Attributes</head>
  <description>
    <p>Should the following attributes be represented in
       the data model? xmlns attributes, xml:lang, xml:space,
       xsi:nil (etc). If so, how?
    </p>
  </description>
</issue>

<issue id="Issue-0072" date="13-January-2002" raisedby="Jeni Tennison">
  <head>Lexical representation of Schema primitive types</head>
  <description>
    <p>Unfortunately the XML Schema Datatypes Rec doesn't detail the
       canonical lexical representation of all of the primitive types. In
       particular, no canonical lexical representation is specified for:</p>
       <olist>
       <item><p>
       xs:string, xs:base64Binary, xs:anyURI (but that's OK, I think we
       can guess)
       </p></item>
       <item><p>
       xs:duration - presumably the lexical representation contains all
       components of the duration (years, months, days, hours, minutes
       and seconds, even those that occur 0 times? Or are these omitted?
       In the latter case, what's the canonical lexical representation of
       PT0S? Since the number of seconds can be a decimal, is this
       decimal represented with a decimal point (i.e. using the canonical
       lexical representation for xs:decimal)?
       </p></item>
       <item><p>
       xs:date - what happens to the timezone component? Presumably,
       unlike xs:dateTime and xs:time, this isn't normalized to Z?
       (And similarly for xs:gYearMonth, xs:gYear, xs:gMonthDay,
       xs:Month, and xs:Day)
       </p></item>
       <item><p>
       xs:QName and xs:NOTATION - these are the trickiest (their value
       spaces are the same). The XML Schema Rec states that the lexical
       representation of a QName depends on the in-scope namespaces.
       Does this mean the ones in the query/stylesheet or the ones from the
       source document? What if there's more than one namespace
       declaration for the namespace URI? What if there aren't any?
       </p></item>
       </olist>
       <p><loc href="http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0268.html">http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0268.html</loc>
    </p>
  </description>
</issue>

<issue id="Issue-0073" date="13-January-2002" raisedby="Jeni Tennison" status="closed">
  <head>Whitespace normalization of the string-value of elements with simple content</head>
  <description>
    <p>Currently the data model says that the string value of an attribute node
       is normalized (according to the whitespace facet of its type); on
       the other hand, the string value of an element node is not normalized.
       The string value of elements with simple content should also
       be normalized in the same way as the string value of attributes.
       <loc href="http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0269.html">http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0269.html</loc>
    </p>
  </description>
  <resolution date="25-July-2002">
    <p>MN: The mapping from the PSVI to the data model has been updated
    to use the <emph role="infoset-property">schema normalized value</emph>
    PSVI property (if exists) in the case of both attributes or elements.
    </p>
  </resolution>
</issue>

<issue id="Issue-0074" date="12-February-2002" raisedby="Michael Rys">
  <head>Do we need Document fragments</head>
  <description>
    <p>Currently the Document node in the data model is permissive in the
       number of element nodes it can directly contain whereas the infoset
       only allows a single element node.
       Since preserving the single element node constraint is important to
       enforce queries to generate only well-formed documents when generating
       documents, the question is whether the data model needs to introduce a
       docfragment node that is permissive and keep the document node to be
       non-permissive. See
       <loc href="http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0111.html">http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0111.html</loc> (members only).
    </p>
  </description>
</issue>

<issue id="Issue-0075" date="26-June-2002" raisedby="Michael Kay">
  <head>Support for unparsed entities</head>
  <description>
    <p>
XSL WG has a requirement to access unparsed entities in a document. This is
needed to support the XSLT 1.0 unparsed-entity-uri() function, and the
unparsed-entity-public-id() function which we are adding for XSLT 2.0.

In XSLT 1.0, unparsed entities were not described in the XPath data model,
but in an XSLT addition to the data model. This solution is unsatisfactory:
the data model should describe all the information that is available. The
information is available in the InfoSet so there is no architectural problem
in providing it. There is room for debate about how it is best provided (we
don't really want another node type if we can help it), but the information
should be there.

We are not proposing, at this stage, that the functions
unparsed-entity-uri() and unparsed-entity-public-id() be moved from XSLT
into XPath, though that can easily be done if people want them. The
information about unparsed entities in the data model would therefore not be
available to XQuery users or to XPath users outside an XSLT environment.
    </p>
  </description>
</issue>

<issue id="Issue-0076" date="29-July-2002" raisedby="Marton Nagy">
  <head>PSVI to Type mapping supporting derived types</head>
  <description>
    <p>
    The last bullet in the definition of the PSVI to Type mapping does
    not handle derived types properly. In those cases we should not bottom
    out at xs:anyType, but attempt to use the rules all over again
    with the type from which the current type is derived.
    Also note that these rules need to be slightly different if we decide
    to use generated type identifiers when no type names are available.
    </p>
  </description>
</issue>

<issue id="Issue-0077" date="29-July-2002" raisedby="XPath Task Force">
  <head>PSVI to Type mapping dependence on conformance levels</head>
  <description>
    <p>
    The rules specifying the computation of the types from the PSVI
    do not yet reflect that this process depends on the conformance
    level of the processor.
    For Basic, are any type annotations preserved? The Query/XPath
    book says the data types are mapped to the nearest supertype,
    the Data Model needs to agree with this.
    </p>
  </description>
</issue>

<issue id="Issue-0078" date="31-July-2002" raisedby="Michael Kay">
  <head>Data model does not represent CDATA sections</head>
  <description>
    <p>
    It is not clear how the current data model can represent or
    accomodate CDATA sections. (This is also captured as Issue 0293 on
    the XPath issue list.)
    </p>
  </description>
</issue>

<issue id="Issue-0079" date="31-July-2002" raisedby="Marton Nagy">
  <head>String-value vs. string-value of the typed-value</head>
  <description>
    <p>
    Note that the current definition of dm:string-value($n) is such that
    it may differ from dm:string-value(dm:typed-value($n)) for some
    element or attribute nodes $n.  For instance given a node
    dm:element-node(my:a,(),(),dm:text-node("01"),xs:integer),
    its string-value gives "01", but the string-value of the typed-value is "1".
    </p>
    <p> The possible resolutions are that we (a) prohibit, (b) allow or (c)
    mandate dm:string-value($n) to be dm:string-value(dm:typed-value($n)).
    The current text reflects (a). Option (b) would result in non-interoperable
    implementations. Option (c) is promising. In that case the element
    constructor would need to be a little smart and change the textnode to
    contain the string value of dm:atomic-value-sequence applied to the
    string-value of the original text node and the type passed to the
    constructor. Similar change would need to be done to the attribute
    constructor.
    </p>
  </description>
</issue>

<issue id="Issue-0080" date="1-August-2002" raisedby="Mary Fernandez">
  <head>Typed value of Document, PI and Comment nodes</head>
  <description>
    <p>
    There is currently an asymmetry between the data model and the
    F&amp;O documents.
    In the data model, the typed-value accessor on document, 
    comment, PI nodes returns the empty sequence.
    In the F&amp;O document, the data() function applied to 
    a document, namespace, comment or processing instruction 
    node, raises an  error.
    </p>
    <p>
    My intuition is that data() should be defined on all 
    nodes, just as string-value() is defined.  Raising
    an error on document, comment, PI, seems draconian
    and has tripped me up in writing queries that iterate
    over a variety of nodes.  If data() returns error on
    such nodes, one ends up with a lot of code checking
    what kind of node is bound to a variable, etc.
    </p>
  </description>
</issue>

</inform-div1>

</back>
</spec>

  

