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

Re: [xsl] Editing XPath expressions (Was: Replacing = with == and ===)


Subject: Re: [xsl] Editing XPath expressions (Was: Replacing = with == and ===)
From: "Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 3 Aug 2014 08:10:36 -0000

Yes, parsing XPath expressions into some XML representation is a fairly
specialized requirement but it arises often enough that it would be nice to
have a generic off-the-shelf solution to it. John Lumley, for example, is
doing it in the streamability analysis tool that he's presenting at Balisage
next week, and Phil Fearon does it in his Saxon-CE-based editor.

A good starting point for such things is the Rex parser from Gunther
Rademacher, which is a superb piece of technology that unfortunately suffers
from very poor documentation and packaging.

Michael Kay
Saxonica
mike@xxxxxxxxxxxx
+44 (0) 118 946 5893




On 3 Aug 2014, at 08:57, Alain Couthures alain.couthures@xxxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> There is an XQueryX notation for each XPath expression and, because I am
rewriting my own XPath 1.0 engine for XSLTForms, I have written my own XPath
2.0/3.0 parser, in Javascript, for generating XQueryX trees to be evaluated.
This parser will be ported back to XSLT 1.0 as the previous one was originally
directly written with it. It could also be ported to Java, C# or PHP.
>
> This is an XML restriction to limit attribute values to be just text nodes
but my product (Fleur: https://github.com/AlainCouthures/Fleur/tree/trunk) has
its own XDM, which I have already extended for storing CSV or JSON objects, so
it can manage sub-trees as attribute values as well. Transforming XPath
expressions into subtrees sounds like compiling an XSLT stylesheet. Having
this, it will then be possible to edit XPath expressions with XSLT/XPath!
>
> --Alain
>
> Le 03/08/2014 09:12, BR Chrisman brchrisman@xxxxxxxxx a icrit :
>> ... which brings up a point I've wondered about for quite a while.
>> XSLT allows me to transform XML, obviously including XSLT.
>> XPath is a big part of modifying/mutating XSLT because it allows me to
>> relatively easily address structures/constructs within my XSLT
>> program.
>> But when it comes down to it, I'd also like an XPath-like-language
>> that implicitly lets me parse/address XPath within XSLT attributes
>> (like select=) in order to gain further insight into what a particular
>> template/routine/etc is doing (and whether I need to modify it via my
>> XSLT-transforming-XSLT program.
>>
>> The immediate context here is that I wanted to respond to this poster
>> saying: "Just invent your own derivative of XSLT where you have your
>> own token preference..." and that would work except for some nastiness
>> which would come in when parsing the actual XPath expressions to
>> differentiate between something like: select="*[@foo='bar']" and:
>> select="'my string with equals = in it'" (or in this case, the wonky
>> derivative with '==' instead of '=', though I don't pretend to have a
>> valid case for it).
>>
>> Anyways, I've had this problem before, where I wanted to modify
>> existing XSLT programs in a particular way, but would need to have
>> insight into the XPath expression that would be a whole lot of parsing
>> work.  Previously, I've resorted to dangerous hacks with regex or
>> tokenizing, but having some sort of xpathpath would be better... even
>> if it didn't include xpathpathpath and further recursions.


Current Thread
Keywords