[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Editing XPath expressions (Was: Replacing = with == an

Subject: 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
 Editing XPath expressions (Was: Replacing = with == an
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.