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.
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Concensus on the most ele, John Lumley john@xxx | Thread | [xsl] XML Summer School 2015, Debbie Lapeyre dalap |
Re: [xsl] Concensus on the most ele, John Lumley john@xxx | Date | [xsl] XML Summer School 2015, Debbie Lapeyre dalap |
Month |