Subject: Re: [xsl] XSLT 2 processors|
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Thu, 09 Feb 2012 17:09:06 +0000
Liam,Given an open-source XQuery engine, I suspect an easier approach is to write a front-end that compiles XSLT into the abstract tree representation used by the XQuery processor, augmented with some custom functions to do pattern matching and template despatch, and a few internal code tweaks to handle the cases where XSLT and XQuery behave almost the same but not quite, e.g. handling of duplicate attributes (dynamic error in XQuery, use the last in XSLT). Generating XQuery code that handles that kind of difference is likely to impose a nasty performance penalty.
Evan Lenz's work on the "Carrot" syntax for XSLT, which you possibly saw presented at Balisage, might give an interesting starting point for work on a compiler to write XQuery from XSLT 2.0. (Evan does go the other way, from XQuery+Carrot into XSLT.)
Michael Kay Saxonica