The Future of XT

Maintaining XT

If you've had cause to look for an XSLT processor, you'll have certainly come across James Clark's XT. It was the first XSLT processor available, and for a long time has boasted better performance than other processors such as Xalan and SAXON. Not surprisingly, many developers have been using it exclusively, both as a tool and as a means of integrating an XSLT processor into their own code.

Seeing a need for continued support and development of XT, Eric van der Vlist announced on the XSL mailing list that 4XT would be organizing maintenance for the tool:

Considering that XT is part of the XML patrimony and should be maintained, 4xt has decided to organize its maintenance.

We will need the help from the XSL community to achieve this important task...

4XT is a web site that coordinates a user group for XT. The decision was prompted by a comment from James Clark indicating that he would no longer be actively developing the software:

I'll probably do a release that fixes a few bugs at some point, but I'm not planning to spend significant time on XT in the near future.

In a later message, Clark also questioned the utility of anyone maintaining XT, explaining that his goal to aid the development of the XSLT specification had been met. With other Java-based XSLT tools available, Clark believed that there was little point in continuing with the project:

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...

These statements were cause for concern for some developers. Senthil, while sympathetic, believed that appropriate warnings should have been given:

>From an independent developer standpoint, I understand James C. somewhat, but if the goal is to have this as a test bed for refining the specs then necessary disclaimers should have been communicated.

Simon St. Laurent observed that the success of XT is worth building on:

I'm deeply concerned that XT's creator doesn't have much interest in the installed base of his product, which has been immortalized in code and in print too deeply to switch out easily.

I've recommended XT as a 'preferred' processor as long as it's been out there, largely because it was ahead of the competition for so long. That success seems like a great thing to continue, not something to drop so easily.

In a response to James Clark, Eric van der Vlist was also quick to point out a list of reasons to continue support of the software:

• Because you've overachieved your goal and have created a high performance and very stable product.
• Because people have grown to like XT.
• Because many tools and applications are relying on XT.
• Because there are only 3 major implementations of XSLT and XT is the fastest of them.
• Because competition is good for open source projects.

Competing projects can also benefit by learning from each other's successes and failures. This free flow of ideas is a key part of the open source ideal. Despite misgivings about its future, James Clark is clearly convinced that there is room for further performance improvements in XT. Clark's renown as a developer in the SGML/XML community is not unfounded; there are likely to be many valuable lessons to be learned from the software. Clark's offer to document some of the basic techniques will hopefully be followed up.

As Ron Ten-Hove commented:

...perhaps its time to look at creating "XT mark II", architected and implemented in a way that reflects the lessons learned from XT's strengths and weaknesses?

Developers on the 4XT mailing list have accepted the challenge and have already compiled a "to do" list of enhancements. After a period of relative inactivity, it'll be interesting to see what the future holds for XT.

Open Source SOAP

This week has been a good one for developers of distributed data services. Firstly SOAP4J, the IBM Java implementation of SOAP (the Simple Object Access Protocol), was donated to the Apache XML Project. This continues a welcome trend which began with the donation of the XML4J parser and the LotusXSL XSLT engine. (The tools are now known as Xerces and Xalan, respectively.)

Microsoft then announced the availability of their SOAP tool-kit for Visual Studio 6.0, finally enabling Windows developers to get in on the act. The toolkit provides support for automating the conversion of existing COM components into web-based services, accessible using SOAP. Despite being one of the originators of the SOAP specification, Microsoft has been slow to release their toolkit, but it looks like the wait has been worthwhile.

Next week, XML-Deviant will be reporting from the XML Europe 2000 conference.