[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] better way to get the path to a node?


Subject: Re: [xsl] better way to get the path to a node?
From: Graydon <graydon@xxxxxxxxx>
Date: Sat, 1 Dec 2012 08:43:24 -0500

On Sat, Dec 01, 2012 at 12:05:47PM +0000, David Carlisle scripsit:
> On 01/12/2012 02:52, Graydon wrote:
> >[do better than, getting the path]
> ><xsl:sequence
> >select="string-join(ancestor-or-self::*/concat('/',name(),'[',for $x in . return count(preceding-sibling::*[name() eq $x/name()])+1,']'),'')"/>
> 
> As has been mentioned, saxon has an extension for this if you have
> saxon extensions.

Which I do, but didn't know; thank you!

(I've been trying to avoid processor-specific extensions, but speed
beats almost everything else in this particular case.)

> For XSLT implementations, the schematron sources have several
> versions depending on the use case.

Good to know, thank you!

> Using name() as you have it makes for a more human readable path but
> relies on the namespace prefixes in the current source being the
> same as in the context where the xpath will be evaluated, which
> isn't always the case.

All true.  This is a case where the namespace context is fixed (I'm
producing reports on a big pile of XML documentation, which stays in the
default namespace) and where human-readability is paramount -- people
may have to evaluate parts of the report -- so the human readable path
is desired.

> Simpler and avoiding namespace woes is to generate
> 
> /*[1]/*[2]/*[23]
> 
> ie just count elements without regard for name, This works of course
> but doesn't give a human reader of the xpath much of a clue what was
> being identified.

Yeah, and I very much need the human reader to be able to go find the
file in question and plug the XPath into a search bar and get the right
element.  So human-readable is required and saxon:path() is likely the
best choice.

Thanks!
Graydon


Current Thread
Keywords