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