Evaluate a string as an XPath

Looking at ways to process a suggested change in TEI P5, I wanted to test that there is a straightforward way to evaluate a string that exists in a document as if it was an XPath you had included in your document.

So say I have a made-up document where I store some xpaths relating to that very document in the document itself as bits of text.

Input

<?xml version="1.0" encoding="UTF-8"?>
<foo>
    <paths>
        <path>/foo/blort/wibble[1]</path>
        <path>/foo/blort/wibble[2]</path>
        <path>//*[@xml:id='wibNum2']/splat/@att</path>
    </paths>
    <blort>
        <wibble>test text 1</wibble>
        <wibble>Another wibble </wibble>
        <wibble xml:id="wibNum2">This is <splat att="value1">a
            test</splat></wibble>
    </blort>
</foo>

To grab these and evaluate them as XPaths, you need to use an extension in saxon, unfortunately, saxon:evaluate(). For example in this stylesheet:

XSLT

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="2.0" xmlns:saxon="http://saxon.sf.net/"
    exclude-result-prefixes="#all">
    <xsl:output indent="yes"/>

    </xsl><xsl:template match="/foo">
        <foo>
            <xsl:for-each select="paths/path">
                <out>
                    <xsl:value-of select="saxon:evaluate(.)"/>
                </out>
            </xsl>
        </foo>
    </xsl>



This should produce the output:

Output

< ?xml version="1.0" encoding="UTF-8"?>
<foo>
  <out>test text 1</out>
  <out>Another wibble </out>
  <out>value1</out>
</foo>

This does use the saxon:evaluate(.) extension. There are similar extensions in a variety of other implementations for XSLT1 as well.

-James

Posted in TEI | 6 Comments

6 Responses to “Evaluate a string as an XPath”

  1. pauafritter says:

    Is it suggested that TEI will include xpath? Or have I got the wrong end of the stick? Actually I guess since TEI uses URIs for reference everywhere, one could theoretically use xpointer fragment identifiers already. Hmmmm

  2. James Cummings says:

    Hiya,

    I thought it might be the kind of thing you’d pick up on. There is a proposal arising out of the possibility of the introduction of a ‘precision’ element (to mirror ‘certainty’) that the way in which you point to the location of these was horribly mungled when moving from P4 to P5 and that in reforming that we might answer a lot of the criticisms of it. See the various sourceForge feature requests on ‘precision’ especially the one asking for an element. Also see Lou’s recent proposal at http://lists.village.virginia.edu/pipermail/tei-council/2009/010901.html If you have any comments I’ll happily pass them back to Council. True, you can do this with XPointer (and evaluating that is just as difficult), as soon as you start dealing with actual element names and have to declare namespaces the xpointer method becomes a tad cumbersome. Of course, once you open up the door for just allowing an attribute with an XPath2 datatype then I’m sure you can think of other places it might be useful…

    -James

  3. pauafritter says:

    Actually it would be tedious but not too hard to implement an xpath interpreter in pure XSLT I reckon. A recursive template and a giant choose statement would to the trick.

  4. James Cummings says:

    Well, it depends if you mean it to be fully compliant with the XPath2 recommendation. I figure that is going to be quite hard really. Fine for known situations where you know all you’ve given is simple paths, but what about when you’ve started including functions?

    See the thread ‘Evaluate XPath from String’ where I asked this recently on the xsl-list.

    -James
    (who has just noticed that you can highlight sourcecode automagically in wordpress hosted blogs.)

  5. pauafritter says:

    Interesting. It struck me recently, too, that it might be useful to be able to point from a rendition element to a range of transcriptural elements, as well as back the other way. This would be more along the lines of the way CSS is used with HTML (i.e. with CSS selectors as well as the formatting rules)

    I take it from your comment about namespaces in XPath is that the point of XPath2 (rather than XPath1 I mean) is to simplify pointing to elements in the TEI namespace using a default namespace (rather than any other feature of XPath2)?

    In general it seems like a reasonable approach to me, though of course it’s all very “meta” and I don’t have a wet towel wrapped around my head to appreciate it properly :-)

  6. pauafritter says:

    I would need to think about that, but off the top of my head I wouldn’t think xpath functions would need a very different approach to other xpath operators, or much different to how you’d handle steps even. Hmmm.

    BTW I think that it doesn’t make sense to use a general xpath expression in this case anyway; it should be like an xslt “pattern” surely? http://www.w3.org/TR/xslt20/#patterns

Leave a Reply