This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: text() and not()
- From: David Carlisle <davidc at nag dot co dot uk>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Tue, 8 Jan 2002 14:10:25 GMT
- Subject: Re: [xsl] text() and not()
- References: <002901c1984a$4cef2f30$8ac809c0@ajw>
- Reply-to: xsl-list at lists dot mulberrytech dot com
> Actually the trailing bracket has a parent <xref>, so Im now using
yes I sent a correction straight after,
//text()[not(ancestor::title/ancestor::subpara1)]
a // at the start of a match expression never does anything useful.
Sometimes it changes the default priority but here, as you already have
a [] predicate, the // isn't doing anything at all.
anything that matches
//text()[not(ancestor::title/ancestor::subpara1)]
will also match
text()[not(ancestor::title/ancestor::subpara1)]
if you really want to match these text nodes, it's probably easier to
come down rather than up, the same nodes are matched by
subpara1//title//text()
but again, if you don't want titles it is far more common to have a
template matching title that does nothing rather than matching on title,
doing the default template which recurses on to the text nodes and then
having a template that does not copy those text nodes. Doing it this way
just makes things far more complicated than you need.
David
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list