This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: How to efficiently remove "a" nodes with no "b" descend ants
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] How to efficiently remove "a" nodes with no "b" descend ants
- From: "FINLEY, Mike" <Mike dot FINLEY at sema dot co dot uk>
- Date: Thu, 8 Mar 2001 17:13:46 -0000
- Reply-To: xsl-list at lists dot mulberrytech dot com
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