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

Re: [xsl] Concensus on the most elegant XPath/etc implementation

Subject: Re: [xsl] Concensus on the most elegant XPath/etc implementation
From: "Justin Johansson procode@xxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 12 May 2015 03:57:47 -0000

Thanks to John Lumley & Tony Graham for replies to my question about the "most elegant" way that an XPath implementation could conceivably be realized.

I've waited a week or so to see if there would be any other responses, so in the absence of any others or dissenters to the contrary, John's answer is hereby deemed to be truly the "most elegant", albeit, as John suggests, likely not to be the fastest. :-)

Justin Johansson

On 03/05/15 07:23, John Lumley john@xxxxxxxxxxxx wrote:
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 productionsE7, 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@xxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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.

Current Thread