Subject: RE: [xsl] xpath // query From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 24 Apr 2002 14:41:37 +0100 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] xpath // query, Laura Jenkins | Thread | RE: [xsl] xpath // query, Aleksander Dye |
RE: [xsl] xpath // query, Michael Kay | Date | Re: [xsl] exslt str:tokenize, cutlass |
Month |