views:

134

answers:

2

I found only one attempt to create such compiler - http://sourceforge.net/projects/xsltc/. But this project is dead for decade already. Are there any other examples? Opensource or commercial?

Are there any fundamental technical difficulties with building such software? With the whole approach of compiling XSLT natively?

I suppose there are good use cases for using it - places where we don't need to change XSLT but still would like to get higher performance (and probably, lower memory requirements).

Are there any other reasons this software may be not so efficient as it looks? - Are interpreting XSLT processors as efficient as compiled would probably be?

+2  A: 

From my understanding, XSLT isn't very popular anymore. Generally, it's easier and more powerful to use your favorite XML library for your language of choice, parse your XML data, and write code to format the output the way you want it.

On the other hand, it seems like you have had some success with it already. There are cases when it's useful. Check this SO question out for more details on the pros and cons of XSLT.

Anyway, software developers in general aren't big fans of XSLT, which would explain why there hasn't been a big movement to write an optimized XSLT parser in C++.

thebretness
XSLT is definitely an acquired taste. Count me in the bunch that like it.
ChaosPandion
More powerful ? That's nonsense. XSLT is pure power. Not popular ? who cares. The important thing is that it's not a dead language, and won't be for a long time.
Max Toro
A: 

XSLT is a functional langauge with some pattern matching.

You could arguably compile it as a set of pattern-directed rules, with metamatching make sure that all patterns applicable at an instant were handled efficiently.

Compiling pattern-directed rules langauges is pretty well understood; see work on Charles Forty's Rete networks in the early 80s and derivatives over the past twenty years.

So if somebody wanted to do this, they could. Where's the economic incentive?

If you did want to do this, you want a tool that can process XSLT as a set of patterns rather than using an XML processor to treat it asdumb XML document at it otherwise appears to be. And you'd want to be able to manipulate/compose the patterns and generate target machine code. You'd need a tool that is designed to manipulate symbolic structures.

LISP would be good, but isn't particularly good are parsing XML (fixable with sweat), and isn't particularly good at manipulating generated C++ code (fixable only with a vast amount of sweat so unlikely).

Our DMS Software Reengineering Toolkit is a system designed to treat formal documents as parts in essentially the same way a compiler treats source code as a set of langauge structures. It has XML parsers, and can manipulate C++ code fragments in parts, in composition, and can optimize the result by applying C++ optimization source-to-source program transformation rules. (Vast amount of sweat already invested in the C++ manipulation).

We've done pattern-directed rule compilers using DMS, not for XSLT, but rather to compile those source-to-source program transformation rules, by meta-matching the patterns and tracking the state of induced changes. You get really big automata (sort of the same way LR parsing tables get big) that can implement the translation.

Haven't done this for XSLT, though.

Ira Baxter