<listitem>
        <para>
         In the XQuery/XPath data model, a <firstterm>document
         node</firstterm> can have either document form (i.e., exactly one
         top-level element, with only comments and processing instructions
         outside of it) or content form (with those constraints
         relaxed). Its equivalent in XPath 1.0, the
         <firstterm>root node</firstterm>, can only be in document form.
         This is part of the reason an <type>xml</type> value passed as the
         context item to any <productname>PostgreSQL</productname>
         XPath-based function must be in document form.
        </para>
       </listitem>
      </itemizedlist>
     </para>

     <para>
      The differences highlighted here are not all of them. In XQuery and
      the 2.0 and later versions of XPath, there is an XPath 1.0 compatibility
      mode, and the W3C lists of
      <ulink url='https://www.w3.org/TR/2010/REC-xpath-functions-20101214/#xpath1-compatibility'>function library changes</ulink>
      and
      <ulink url='https://www.w3.org/TR/xpath20/#id-backwards-compatibility'>language changes</ulink>
      applied in that mode offer a more complete (but still not exhaustive)
      account of the differences.  The compatibility mode cannot make the
      later languages exactly equivalent to XPath 1.0.
     </para>
    </sect3>

    <sect3 id="functions-xml-limits-casts">
     <title>Mappings between SQL and XML Data Types and Values</title>

     <para>
      In SQL:2006 and later, both directions of conversion between standard SQL
      data types and the XML Schema types are specified precisely. However, the
      rules are expressed using the types and semantics of XQuery/XPath, and
      have no direct application to the different data model of XPath 1.0.
     </para>

     <para>
      When <productname>PostgreSQL</productname> maps SQL data values to XML
      (as in <function>xmlelement</function>), or XML to SQL (as in the output
      columns of <function>xmltable</function>), except for a few cases
      treated specially, <productname>PostgreSQL</productname> simply assumes
      that the XML data type's XPath 1.0 string form will be valid as the
      text-input form of the SQL datatype, and conversely. This rule has the
      virtue of simplicity while producing, for many data types, results similar
      to the mappings specified in the standard.
     </para>

     <para>
      Where interoperability with other systems is a concern, for some data
      types, it may be necessary to use data type formatting functions (such
      as those in <xref linkend="functions-formatting"/>) explicitly to
      produce the standard mappings.
     </para>
    </sect3>
   </sect2>

   <sect2 id="functions-xml-limits-postgresql">
    <title>Incidental Limits of the Implementation</title>

    <para>
     This section concerns limits that are not inherent in the
     <application>libxml2</application> library, but