[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: "Tony Graham tgraham@xxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 May 2015 10:37:34 -0000

On 02/05/2015 22:53, John Lumley john@xxxxxxxxxxxx wrote:
I'd suggest that one of the most elegant would be written in XSLT in
the following manner:

The 'focheck' project from Antenna House for validating XSL-FO (https://github.com/AntennaHouse/focheck) does something not dissimilar.

I'm talking about 'focheck' at XML London in June.

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.

'focheck' uses a generated parser in XSLT 2.0 to parse expressions in the XSL-FO expression language.

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.

Tried that, but it didn't play well with using the result of the evaluation in Schematron rules in oXygen. oXygen uses xsl:message for Schematron messages and, for reasons I never fully delved into, using templates to process the parser result made oXygen report the error context as being in the parser XSLT document, not in the document being checked. My best theory is that it's because using xsl:apply-templates changed the context. The current code, therefore, uses only xsl:function to avoid changing the context.

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.

Almost. In FO expressions, you can multiply lengths and percentages as well as numbers.

The tension for 'focheck', where the parsing is meant to run as an
adjunct to Schematron checking in an editor, is over how many FO
functions to fully implement rather that just return an <Object/>, since
the more complete the parsing is, the slower it will be.  However,
thanks to memorising expression results, any expression is only slow once.

I can't see anything else being as 'elegant' as that.....

And, once you've scratched your itch for elegance, you can generate the REx parser as a Saxon extension function so you can do more to scratch your itch for speed. For 'focheck', that's due to happen this week.


Tony Graham. -- Senior Architect XML Division Antenna House, Inc. ---- Skerries, Ireland tgraham@xxxxxxxxxxxxx

Current Thread