Single Node XPath Evaluation Is Ambiguous

The DOM Level 3 XPath module allows single nodes to be selected,
where the returned node can be either the first node in document
order, or any node from the result set. The ability to select
the first node in document order is certainly useful, but the
second definition is definately not.

The reason for this is that when a single node is selected
from a node set, there is almost always a particular node in
mind. If the node returned varies depending on the particular
implementation used, then the method becomes worthless for
implementation agnostic code.

XPath itself does not specify how single nodes should be
returned, since it does not cater for single node selections.
XSLT and MSXML, however, both allow single node selections, and
both provide them in the same way.

The node returned is always the first node in evaluation order.
For example, if I wanted to find the owner table of an arbitrary
HTML element, I could query:

   ancestor::table

And this would give me the first ancestor element that was of
type table. Similarly, if I wanted to find the next table row
group in an HTML table, I could query:

   following-sibling::tbody

The XSLT spec defines this behaviour for it's xsl:value-of
element <http://www.w3.org/TR/xslt#value-of>, but does not
use the term 'evaluation order' specifically. It says:

   The following [example] precedes each procedure element with
   a paragraph containing the security level of the procedure.
   It assumes that the security level that applies to a
   procedure is determined by a security attribute on the
   procedure element or on an ancestor element of the procedure.
   It also assumes that if more than one such element has a
   security attribute then the security level is determined by
   the element that is closest to the procedure.

   <xsl:template match="procedure">
     <fo:block>
       <xsl:value-of
        select="ancestor-or-self::*[@security][1]/@security"/>
     </fo:block>
     <xsl:apply-templates/>
   </xsl:template>


Thanks, Dominic.

Received on Friday, 1 November 2002 02:57:58 UTC