Subject: [xsl] Editing XPath expressions (Was: Replacing = with == and ===) From: "Alain Couthures alain.couthures@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Sun, 3 Aug 2014 07:56:50 -0000 |
... 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Replacing = with == and =, BR Chrisman brchrism | Thread | Re: [xsl] Editing XPath expressions, Michael Kay mike@xxx |
Re: [xsl] Replacing = with == and =, BR Chrisman brchrism | Date | Re: [xsl] Editing XPath expressions, Michael Kay mike@xxx |
Month |