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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--