Re: [xsl] XPath equivalence question

Subject: Re: [xsl] XPath equivalence question
From: Graydon <graydon@xxxxxxxxx>
Date: Wed, 30 Nov 2011 20:27:13 -0500
On Thu, Dec 01, 2011 at 12:28:47AM +0000, Michael Kay scripsit:
> On 30/11/2011 23:48, Graydon wrote:
> >Does
> >
> ><xsl:template match="/A//B">
> >
> >match exactly the same thing as
> >
> ><xsl:template match="B[/A]">?
> Yes, I think so.
> >
> >My presumption is that the second form is preferable on efficiency
> >grounds -- on simple table lookup versus whatever tree-structure the
> >descendant axis search produces -- but I don't actually know.
> You seem to be basing you reasoning on some kind of hypothetical
> implementation model which has no resemblance to the way it's
> implemented in Saxon and may have little resemblance to any other
> product.

That would be precisely correct.  (Since I don't know how anybody
implements their XSL processor.)

> In both cases, in Saxon, the test whether a node matches the pattern
> will start by asking whether it is an element named B, and then
> proceed by asking whether it has an ancestor named A that is a child
> of the root document node.

Since we're using Saxon, this is good to know.

> In both cases, if you do an apply-templates that selects a node named
> C, this rule won't even be considered and will have no impact on the
> performance.

Of course.

The use-case is having a content in a diverse bunch of similar DTDs
which are being converted to another, entirely new/different DTD.  It is
often the case where common elements -- list, item, para, sorts of thing
-- have different semantics based on which DTD they are in, and the
apparent best way to test for "what kind of list is this?" is to check
the child of the root element, since those have reliably different names.

Since we wind up qualifying element matches with the document element
like this a fair bit, I wound up curious about the alternative ways to
express the test.


Current Thread