[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] General rule for designing XPath expressions to return items in document order?


Subject: Re: [xsl] General rule for designing XPath expressions to return items in document order?
From: "Costello, Roger L." <costello@xxxxxxxxx>
Date: Wed, 8 Jan 2014 12:40:37 +0000

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@xxxxxxxxxxxx]
Sent: Wednesday, January 08, 2014 6:54 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx> 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


Current Thread
Keywords