RE: xpath // query

I'm not quite sure I got you there....
Are you saying that select="A//B//C" and select="A//C" will produce the same
result?

check this xml out:
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<a>
   <c>a/c</c>
   <b>
      <c>a/b/c</c>
   </b>
</a>

add the xsl:
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
   <xsl:output method="html" encoding="ISO-8859-1" indent="yes" />

	<xsl:template match="/">
		1<p><xsl:value-of select="a//c" /></p>
		2<p><xsl:value-of select="a//b//c" /></p>
	</xsl:template>
</xsl:stylesheet>

And see the result:
		1<p>a/c</p>
		2<p>a/b/c</p>

Now how is that the same?

Regards,
Aleksander

-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Michael Kay
Sent: 24. april 2002 15:42
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE:  xpath // query


> select="A//C"
> This would make the processor to search for C that are
> children of A iin the
> whole document.. This is definitely not fast
> select="A//B//C"
> would make the processor to search for all Cs under all Bs under A.
> This is slightly better approach..

Fascinating. That's three respondents who were confident enough to reply,
but guessed wrong!

It feels as if "A//B//C" gives the processor more information to go on, and
therefore it should be able to reduce the search space. In fact, for a
clever processor, the search space will be the same, and the only difference
is that there is an extra (redundant) test to perform. But for a processor
that adopts a simplistic execution strategy, that is (A//B)//C, the search
space is definitely larger.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list