contend with:

      <itemizedlist>
       <listitem>
        <para>
         The fundamental type of an XQuery/XPath expression, the
         <type>sequence</type>, which can contain XML nodes, atomic values,
         or both, does not exist in XPath 1.0. A 1.0 expression can only
         produce a node-set (containing zero or more XML nodes), or a single
         atomic value.
        </para>
       </listitem>

       <listitem>
        <para>
          Unlike an XQuery/XPath sequence, which can contain any desired
          items in any desired order, an XPath 1.0 node-set has no
          guaranteed order and, like any set, does not allow multiple
          appearances of the same item.
         <note>
          <para>
           The <application>libxml2</application> library does seem to
           always return node-sets to <productname>PostgreSQL</productname>
           with their members in the same relative order they had in the
           input document.  Its documentation does not commit to this
           behavior, and an XPath 1.0 expression cannot control it.
          </para>
         </note>
        </para>
       </listitem>

       <listitem>
        <para>
         While XQuery/XPath provides all of the types defined in XML Schema
         and many operators and functions over those types, XPath 1.0 has only
         node-sets and the three atomic types <type>boolean</type>,
         <type>double</type>, and <type>string</type>.
        </para>
       </listitem>

       <listitem>
        <para>
         XPath 1.0 has no conditional operator. An XQuery/XPath expression
         such as <literal>if ( hat ) then hat/@size else "no hat"</literal>
         has no XPath 1.0 equivalent.
        </para>
       </listitem>

       <listitem>
        <para>
         XPath 1.0 has no ordering comparison operator for strings. Both
         <literal>"cat" &lt; "dog"</literal> and
         <literal>"cat" &gt; "dog"</literal> are false, because each is a
         numeric comparison of two <literal>NaN</literal>s. In contrast,
         <literal>=</literal> and <literal>!=</literal> do compare the strings
         as strings.
        </para>
       </listitem>

       <listitem>
        <para>
         XPath 1.0 blurs the distinction between
         <firstterm>value comparisons</firstterm> and
         <firstterm>general comparisons</firstterm> as XQuery/XPath define
         them.  Both <literal>sale/@hatsize = 7</literal> and
         <literal>sale/@customer = "alice"</literal> are existentially
         quantified comparisons, true if there is
         any <literal>sale</literal> with the given value for the
         attribute, but <literal>sale/@taxable = false()</literal> is a
         value comparison to the
         <firstterm>effective boolean value</firstterm> of a whole node-set.
         It is true only if no <literal>sale</literal> has
         a <literal>taxable</literal> attribute at all.
        </para>
       </listitem>

       <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