It's the struggle between harmony and invention..... The most elegant will
probably be the slowest, the fastest will be the 'dirtiest'.
I'd suggest that one of the most elegant would be written in XSLT in the
following manner:
1. XPath string expressions are parsed with Gunther Rademacher's
parser-generated parser, which of course has been projected to generate XSLT
2.0 code.
2. The resulting XPath parse tree (which is now an XML tree) is interpreted
against a context node by a series of XSLT push templates matching each of the
XPath EBNF productionsŷ, internal (local variable) state being held in a map
transmitted as a tunnelled variable. Calls to built-in functions are mapped to
calls to the built-in functions in the executing XSLT implementation.
3. The resulting sequence of the evaluation is produced by the result of the
topmost parse match.
Of course as this is executed in an XSLT environment, the evaluation of all
XPath expressions required to evaluate the XPath expression, including those
used in the parser, are executed by an XPath evaluator that is written entirely
in XSLT.
[Someone work out what the infinitely recursive T-diagram is for all this to
happen.. ]
I can't see anything else being as 'elegant' as that.....
John Lumley
On 2 May 2015, at 19:07, Justin Johansson
procode(_at_)adam(_dot_)com(_dot_)au
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
In this community's view, are there any specific XPath/XQuery/XSLT 2.0+
implementations that stand out source code wise as being (subjectively)
particularly elegant in terms of spec mapping to code? I know that Saxon is
more-or-less the (gold-standard) reference implementation circa Java 1.0
genealogy but the source code is trying (no disrespect intended). Then there
is XBase which arguably a little more modern and others like Sedna etc in
non-JVM languages which approach the implementation problem differently.
Is it fair to say that there exists no XPath 2.0+ implementation that can be
said to be really elegant and that the "accepted as good" products are simply
heroic works of megaSLOCs in less-that-desirable available programming
languages?
I don't know, but my feeling is that the implementation of XPath 2.0+ should
not have been as difficult as it seems to be and perhaps the available
language platforms just haven't helped to produce good orthogonal, DRY stuff.
You know what I mean; it shouldn't be difficult but it is.
Cynically asking, does anyone actually care if XPath/XQuery has a really cool
behind-the-scenes source code implementation?
Justin Johansson
XPath implementation aspirant.
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--