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: why is select=".[true()]" bad?


"." is an abbreviated step, not an abbreviated the-part-of-the-step-before
the-predicates. Why that should be, I don't know, but that's what XPath
says.

You can always write select="self::node()[@id=1]"

Mike Kay

> -----Original Message-----
> From: Mike Brown [mailto:mike@skew.org]
> Sent: 05 September 2000 00:01
> To: xsl-list@mulberrytech.com
> Subject: why is select=".[true()]" bad?
> 
> 
> Why is it that a predicate is not allowed when I do something like
> 
> <xsl:variable name="foo" select=".[@id=1]"/>
> 
> I mean if the current node has an 'id' attribute numerically 
> equal to the
> number 1, then $foo will be the current node; otherwise it will be an
> empty node-set, right? Both SAXON and XT gripe at me for having a
> predicate after . at all. I can't even say ".[true()]"! 
> What's the deal?
> I don't see anything in XPath prohibiting this.
> 
>    - Mike
> ____________________________________________________________________
> Mike J. Brown, software engineer at         My XML/XSL resources:
> webb.net in Denver, Colorado, USA           http://www.skew.org/xml/
> 
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


 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]