This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: why is select=".[true()]" bad?
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: RE: why is select=".[true()]" bad?
- From: Kay Michael <Michael dot Kay at icl dot com>
- Date: Tue, 5 Sep 2000 15:45:40 +0100
- Reply-To: xsl-list at mulberrytech dot com
"." 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