W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2002

Re: Single Node XPath Evaluation Is Faulty

From: Ray Whitmer <rayw@netscape.com>
Date: Wed, 06 Nov 2002 12:20:19 -0800
Message-ID: <3DC97983.2020908@netscape.com>
To: WWW DOM <www-dom@w3.org>

I responded to this message on November 1, which is in the archives.

Ray Whitmer

Dominic Chambers wrote:

>This is a repost since the original mail apperars to have slipped through
>unoticed. But I think this issue could be serious, so I am reposting.
>>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 a consistent manner.
>>The node returned is always the first node in evaluation order.
>>For example (in msxml), 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 Wednesday, 6 November 2002 15:20:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC