[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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
Re: ANN: Maintenance 4xt
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.