[
Lists Home |
Date Index |
Thread Index
]
Oops.
A *unique* path seemed a stronger statement than I took from the original specification, though perhaps your inferrance is correct. I actually mangled the code from a stylesheet which generates id values as an alternative to generate-id() (which doesn't always generate the same ids for the same structures between stylesheet invocations) but it wasn't originally intended to generate valid XPath notation, just unique identifiers moderately stable under limited modifications.
In the case of text nodes, you'll probably also want to consider using preceding-sibling::text() in the count. Attributes need a name (no order there).
Mitch
Klotz, Leigh wrote:
> The suggested template fails if there is more than one occurrence of the
> path the the elements, not because of the match, but because the path
> produced leads to a nodeset containing more than one element.
>
>
> Here is a document that the original stylesheet below will fail on. It will
> produce /bookmarks/bookmark/item/findme, which does not uniquely identify
> either of the abc or def findme elements in this document:
> <?xml version="1.0" ?>
> <bookmarks>
> <bookmark>
> <item>
> <findme>abc</findme>
> </item>
> </bookmark>
> <bookmark>
> <item>
> <findme>def</findme>
> </item>
> </bookmark>
> </bookmarks>
>
> To fix this problem, you also need to introduce explicit [1], [2], etc at
> each step. If the document is stable, then all you need is the position of
> the elements, not the names.
> An XSLT wizard such as Michael Kay probably has a better way to do this, but
> try this version of the stylesheet, which instead of names uses a repeated
> "/*[n]" construct to address an element uniquely, and which leaves off the
> trailing slash.
>
> <xsl:template match="findme">
> <xsl:for-each select="ancestor-or-self::*">
> <xsl:text>/*[</xsl:text>
> <xsl:value-of select="1+count(preceding-sibling::*)"/>
> <xsl:text>]</xsl:text>
> </xsl:for-each>
> <xsl:text>
</xsl:text>
> </xsl:template>
>
> If you need to produce an XPath expression that finds the node even if the
> rest of the document has been modified, then you can stick in an ID
> addtibute using generate-id before the modifications. If you can't do that,
> you need more help.
>
> Leigh.
> -----Original Message-----
> From: Mitch Amiano [mailto:mamiano@nc.rr.com]
> Sent: Friday, September 05, 2003 5:21 AM
> To: Alejandro López
> Cc: 'xml-dev@lists.xml.org'
> Subject: Re: [xml-dev] XSLT & XPATH absolute path
>
>
> The ancestor-or-self:: axis pretty much gives you that information.
>
> Assuming your node is an element named "findme", you can do something like
> this:
>
> <xsl:template match="findme">
> <xsl:text>/</xsl:text>
> <xsl:for-each select="ancestor-or-self::*">
> <xsl:value-of select="name()"/><xsl:text>/</xsl:text>
> </xsl:for-each>
> <xsl:text>
</xsl:text>
> </xsl:template>
>
> An xsl:choose can help you figure out which nodes are elements versus text
> or attributes, in which case you can deal with the last path segment
> separately by using the "ancestor::" axis instead of "ancestor-or-self::".
>
> Alejandro López wrote:
>
>>Hello everybody.
>>
>>Does anybody know if there is a way in xpath to know the absolute path of
>
> a
>
>>node in order to use with transformation functions?
>>
>>Thanks
>>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
