This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Which engine? (RE: JavaScript and XSL)
- To: xsl-list at mulberrytech dot com
- Subject: Re: Which engine? (RE: JavaScript and XSL)
- From: Eric van der Vlist <vdv at dyomedea dot com>
- Date: Tue, 17 Oct 2000 22:40:43 +0200
- References: <200010171928.NAA29860@skew.org>
- Reply-To: xsl-list at mulberrytech dot com
Mike,
I have always made it clear that while I could participate and provide a
home to make it happen I couldn't afford maintaining XT alone (see for
example a message [1] from last June) and I still ready to start as soon
as I get the first real contributor ready to help me !
[1] http://4xt.org/list/0069.html
Other comments below:
Mike Brown wrote:
>
> http://4xt.org/ is home to a project to provide support and development
> for XT, but IMHO their priorities seem to be a bit backward. They seem to
> favor feature bloat and general discussion instead of aggressive
> development of bug fixes, conformance, and filling in the gaps, like all
> the silently ignored errors, lazy variable evaluation, and source
> code & API documentation.
1,$s/they/he/g
> Kudos and many thanks to James for making such an efficient, free XSLT
> processor that many of us have been able to build a business around, but I
> for one was rather disappointed when it took over 6 months from the last
> release to get an announcement that his official development had ceased.
>
> My company cannot afford the risks associated with a 3rd party product
> whose support is floundering. We moved to SAXON recently, in spite of the
> slight, but noticeable, performance hit, mainly because of the robustness
> of the product --in particular, its support for keys and proper HTML
> output when indent="yes", something not even the latest MSXML can
> achieve-- but also because Mike Kay did a pretty good job documenting the
> code and he is still very actively making improvements to the product. I
> would hate to have to argue with people about the need for xsl:key,
> namespace::, and where not to add whitespace in HTML output, when their
> priorities are creating Unix-like shell add-ons, XHTML output handlers,
> CSV-to-result-tree-fragment features, etc.
I don't want to argue either, but it's not a matter of priorities.
I reckon that for companies who cannot afford participating to the
support of the open source products they are relying on, XT is currently
a very bad choice.
The real work is yet to be started and in the meantime I have though
worth publishing some extensions developed for my own usage (running on
the unmodified release of XT) and providing some guidance to XT users
asking questions.
Or shouldn't I ?
> I don't think these things are bad ideas, but one person's requirement for
> productivity is another person's toy... if XT is good enough for you
> as-is, these things are great new features. If it's not good enough, these
> things are annoying deviances from more productive development.
Until now, XT has been good enough for me.
Eric
> </rant> :)
>
> - Mike
> ____________________________________________________________________
> Mike J. Brown, software engineer at My XML/XSL resources:
> webb.net in Denver, Colorado, USA http://www.skew.org/xml/
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
--
------------------------------------------------------------------------
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