Re: ANN: Maintenance 4xt
Eric van der Vlist wrote: > we must (IMHO) try to keep XT (under this name or any other one) > alive Why? My main goal in writing XT was to support the development of the XSLT spec, both to help me understand the language better and so do a better job as editor and to allow others to experiment with the language as it evolved and thus contribute timely feedback to the development of the language. With the publication of the Rec, this goal has been achieved, and consequently I haven't done significant work on it since then. There are plenty of other XSLT processors out there. I can't say I have looked at any of them in detail, but by all accounts at least some of them are pretty decent. Might it not be better to let XT quietly fade away in favour of other XSLT processors whose authors have an interest in continuing to maintain them? The only thing that seems to differentiate XT is performance and I don't know to what extent that is still the case with the latest version of Saxon. It shouldn't be too hard to make an XSLT processor that is faster than XT; I haven't spent much time optimizing it (and I know of plenty of things that could be done to make it a bit faster). If other XSLT processors are still lagging in performance, perhaps it's possible to apply experience from XT in improving their performance. If there's any interest from other implementors, maybe I can find time to write up a description of the basic techniques used in XT (many of which were inherited from Jade). There just doesn't seem a lot of point in continuing to maintain lots of very similar, independent XSLT implementations in Java. James XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format