[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: ANN: Maintenance 4xt


Subject: Re: ANN: Maintenance 4xt
From: Eric van der Vlist <vdv@xxxxxxxxxxxx>
Date: Fri, 02 Jun 2000 15:16:04 +0200

James Clark wrote:
> 
> Eric van der Vlist wrote:
> 
> > we must (IMHO) try to keep XT (under this name or any other one)
> > alive
> 
> Why?

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 that XT is
the fastest of them.

Because competition is good for Open Source projects (see for instance
the benefits for the users of the competition between sendmail, qmail
and postfix). It can be more loyal and friendly than competition between
commercial products, but we should fear monopolies even for Open Source
projects.
 
> 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.

You were right, it has been very helpful and everyone would like to see
this happen more often.

It should be the rule for any recommendation !

We understand why you have stopped doing done significant work on it and
our goal is to keep XT moving with minimal effort from your side.

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

Yes, please, it would be very useful.
 
> There just doesn't seem a lot of point in continuing to maintain lots of
> very similar, independent XSLT implementations in Java.

Xalan, Saxon, XT.

I haven't found any other Open Source implementation on
http://www.xmlsoftware.com/xsl/ .
 
Is this really that much for something as important as XSLT ? 

> James

Eric
-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords