This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: How to efficiently remove "a" nodes with no "b" descend ants


This presupposes that the XSLT processor you are using does no optimisation,
which may or may not be true. (And the answer to that may differ in the next
implementation.) Second guessing an optimising processor may well be
counterproductive, and it may do better with the simple form that it can
optimise rather than a more complex form that it has to follow through
stepwise.

Of course, it may be that there are no optimising processors around, yet.

mike

-----Original Message-----
From: Teppo Peltonen [mailto:teppo.peltonen@vtt.fi]
Sent: 08 March 2001 16:46
To: xsl-list@lists.mulberrytech.com
Subject: Re: [xsl] How to efficiently remove "a" nodes with no "b"
descend ants


"FINLEY, Mike" <Mike.FINLEY@sema.co.uk> writes:

Hello Mike,

> Why do you think your first offering is not "efficient"?  I doubt
> you'll find anything more concise (one interpretation of efficient)

If I say

> <xsl:template match="a[not(.//b)]"/>

then all the descendants of "a" are checked for "b" elements. Let's
have a closer look at the input structure.

> <a> 

<!-- match, all descendants of "a" are checked -->

>    <b/>
>    <c/>
>    <a>

<!-- match, all descendants of "a" are checked, again -->

>       <a>
<!-- match, all descendants of "a" are checked, again -->

>          <a>
<!-- match, all descendants of "a" are checked, again -->
>             <c>
>                <b/>
>             </c>
>          </a>
>          <a>

<!-- match, all descendants of "a" are checked, again -->

and so on...

Instead of this, I would like to go straight to the far-most child of
the first "a" element and flag the sub nodes that have "b"
descendants, moving upwards in the tree. (Sorry, my algorythms are a
bit rusty right now, but I think there is a name for this kind of tree
traversing...) This way I need to examine each node only once.

Or maybe I am misunderstanding how XLST implements this? (Anyway, it
doesn't seem very speedy to me ;-).

> mike

Thanks for your comments,

Teppo

-- 
Teppo Peltonen <mailto:teppo.peltonen@vtt.fi>     phone 09 4566080
VTT Information Technology                        mobile 040 5651878
Tekniikantie 4 B, P.O.Box 1201, Espoo 02044 VTT   telefax 09 4567052


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


___________________________________________________________________________
This email is confidential and intended solely for the use of the 
individual to whom it is addressed. Any views or opinions presented are 
solely those of the author and do not necessarily represent those of 
Sema. 
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or 
copying of this email is strictly prohibited.

If you have received this email in error please notify the Sema UK
Helpdesk by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]