[Home]  [List]  [News]  [Docs]  [FAQ]  [Downloads]  [Resources]  [About]
Search :
/Home /List

list4xt : Mailing list for the XT users community.

[list4xt] Re: Announce on xsl-list

Subject: [list4xt] Re: Announce on xsl-list

User: Website

From: Paul T (pault12345@yahoo.com)
Date: 02/06/2000 - 21:22

  
Ron Ten-Hove wrote:

In an ideal world, XSLT processors ought to be interchangeable.

# Yes, but this is impossible, because there is no standartization of extension binding. Period.

While the XSLT PR was changing, XT was more current than other available
processors. Now that the PR has been finalised for over half a year,
that "ideal world" situation ought to be materialising.

# Probably it will materialise, but who knows how long it will take it to materialise? Usualy it takes years ( if it will even happen, BTW). I *have* to use 'result tree fragment' to exchange the data between stylesheet and the outer space. 'result tree fragment' class is strongly implementation specific, for example.

# It will take a very long time to get 'real' interoperability, because XSL is not 'only XSL', but it is also 'XSL extensions'. Extensions are not 'exceptions'. They are unavoidable in the real life.

XT is no longer the leader when it comes to conformance to the PR.

# This is not a problem, because missing features are compensated by extensibility.

XT is likely to lose its position as performance leader in the Java-
based XSLT processor world soon, if it hasn't already.

# No, it has not. And XT could be changed to be even more faster. The 'basic' design of XT is correct, I think.

If there are conforming processors available elsewhere, why bother with
maintaining yet-another-XSLT-processor? Why bother keeping XT alive
when I can use Saxon (for example)?

# Try to use Saxon ( like I did. I also tried to use Xalan ) and you may understand that if you are interested in expandable framework, it is sometimes *much* easeir to hack around XT, when it comes to complex mixtures of XSL and java code.

In a nutshell, what is the case for keeping XT alive?

# Nothing better exists for some real-life projects. The shape of codebase is not important for many users, but is *extremely* important for *developers* who need not 'standalone executable' , but handy embeddable tool. The only concurrention for XT in this area is SAXON. SAXON is good for some cases, but XT is much better for some others.

It is up to us, the XT community, to articulate a case for keeping XT
alive, and, assuming the case can be made, find a practical way
accomplish this. We seem to currently be doing things in the wrong
order -- first we need to make the case, not set up CVS repositories!
Another necessary condition before we can proceed is to get Mr Clark's
blessing, otherwise we will not be taken seriously.

# I agree that there may be more effort spend on politics. I suggest Eric make a didgest out of this thread and publish it in XSL list.

Or 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?

# I don't think it will be reasonable, because XT mark II may be based not on XSLT, but not XSLT II

# I think XT is good enough for XSLT, just some tunings and support will allow it to live for a while.

Rgds.Paul.

---------------------------------
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints! 

--
Mailing list for the XT users community.     (http://bardcreditunion.com)
(mailto:list4xt-request@4xt.org?Subject=unsubscribe to unsubscribe)

Archive générée par hypermail 2b28 le 06/11/2001 - 11:46 CET

webmaster@4xt.org