The general rule is:
(a) if you're using a smart XPath processor, don't worry about it, the
processor will do the work for you
(b) if you're using a stupid XPath processor, then find out something about the
nature of its stupidity, because its stupidities are probably not the same as
those of other processors.
Michael Kay
Saxonica
On 8 Jan 2014, at 12:40, Costello, Roger L. <costello(_at_)mitre(_dot_)org>
wrote:
This is a fascinating and enlightening discussion. I am getting a glimpse of
the difference between what is returned from an XPath query versus what is
happening under the hood by the XPath-processor.
Let me recap:
1. This XPath expression //section/head always returns items in document
order.
2. Under the hood, a XPath-processor might proceed like so:
a. Fetch all the <head> elements
b. Sort them into document order
c. Return the sorted <head> elements
Is that accurate?
If so, please allow me to rephrase my initial question:
I am seeking a general rule for designing XPath
expressions so that under the hood the XPath-
processor never needs to sort the fetched items into
document order because the XPath expression
is designed to always select items in document
order. For example, instead of the above XPath
expression, use this one /descendant::head[parent::section]
Can you provide a general rule?
/Roger
-----Original Message-----
From: Michael Kay [mailto:mike(_at_)saxonica(_dot_)com]
Sent: Wednesday, January 08, 2014 6:54 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] General rule for designing XPath expressions to return
items in document order?
On 8 Jan 2014, at 11:41, Costello, Roger L. <costello(_at_)mitre(_dot_)org>
wrote:
David Carlisle wrote:
Path expressions constructed with / always
returns nodes in document order.
Section 19.1 of the XSLT 3.0 specification says:
... evaluation of the path expression //section/head will not always deliver
nodes in document order; this can be seen by examining the source document
below, where a child of the first section appears in document order after a
child of the second section:
You're quoting selectively. It actually says:
"The reason for this is that a naive nested loop evaluation of the path
expression //section/head will not always deliver nodes in document order"
and then:
"An implementation that literally followed the semantics of path expressions
as defined in [XPath 3.0] would therefore require to sort the nodes into
document order"
In other words, a nested loop evaluation will not deliver the correct results
(i.e. the sequence nodes in document order) unless it is followed by a sort,
and the sort would prevent streaming.
Michael Kay
Saxonica
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--