Subject: RE: why is select=".[true()]" bad? From: Kay Michael <Michael.Kay@xxxxxxx> Date: Tue, 5 Sep 2000 15:45:40 +0100 |
"." 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@xxxxxxxx] > Sent: 05 September 2000 00:01 > To: xsl-list@xxxxxxxxxxxxxxxx > 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: why is select=".[true()]" bad?, Mike Brown | Thread | XSL Transformations Requirements Ve, Francis Norton |
How to display page numbers using x, Krishnamurthy, Rama | Date | RE: XSL Transformations Requirement, Kay Michael |
Month |