Re: [xsl] The philosophical implications of an XSLT processor implemented in XSLT
On 22/05/2020 16:26, Dimitre Novatchev dnovatchev@xxxxxxxxx wrote:
Actually, it is the latest developments in XPath 3 (maps) that made it
possible to produce an XSLT processor written in XSLT, which is
claimed to have a practically feasible performance.
I agree - maps make it feasable - you can do it without of course (my
XSLT3 to 2 converter simulated maps with a pair of tunnelled key/value
stack frames), but it is slow by probably a couple of orders of
magnitude. And surprisingly we're finding accumulators an interesting
tool for some of the work.
And, if I read well Dr. Kay's message, it is exactly the XPath parsing
that **is not** implemented in XSLT, instead it is implemented in
but this is principally for performance. I can assure you it is much
much simpler to write the XPath code generator in XSLT
The earliest manifestations of this work derive from analysis of XSLT
streamability in 2014 performed /entirely/ in XSLT (see
which used an XPath parser generated by ReX into an XSLT executable.
The first work on adding XPath evaluation (i.e.support for xsl:evaluate)
used this same XSLT-coded parser, and an XSLT-coded code generator,
which attached to Saxon-JS in its beta phase. It worked effectively,
enough to pass a good series of tests, but was unsurprisingly very
slow,B certainly >O(10x) slower.
For the 1.0 release of Saxon-JS, which supported xsl:evaluate, the XPath
generator also recoded in JS. This was reported at XMLPrague in 2017:
(Well -- the history is something like that)
*John Lumley* MA PhD CEng FIEE
on behalf of Saxonica Ltd