This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: real time transformations
- To: xsl-list at mulberrytech dot com
- Subject: Re: real time transformations
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Sat, 02 Sep 2000 13:32:37 -0700
- Organization: The Qub Group
- References: <OF7EB24039.47ABF8B4-ON8525694D.0044DCCE@lotus.com><005b01c01508$f06311c0$dc1b6c3e@bluesorcerer>
- Reply-To: xsl-list at mulberrytech dot com
----- Original Message -----
From: Lawrence Pit
To: <xalan-dev@xml.apache.org>; <xsl-list@mulberrytech.com>
> Hi,
>
> Suppose you are responsible for writing a web application where every page
> is personalized. Target: 1.000.000 customers. Would you dare doing it in
> Java using an architecture where the component developers are outputting XML
> and visual designers writing only XSL?
I doubt 'visual designers' could write complex XSL stylesheets ( with
recursive call-template, for example ). For trivial XSL stylesheets, the
scenario you describe looks reasonable to me. What I don't understand
is what server-side framework are you planning to use. I guess you'l write
your own. ( If you think, say, Cocoon is the solution, I suggest trying it
before bulding on top of it ).
> The performance of the XSLT tranformations are scaring me to be honest.
I guess you are measuring performance of Xalan ? Xalan is not
the fastest XSLT engine ( I'l say Xalan is the slowest one ).
http://users.ox.ac.uk/~rahtz/xsltest/Report.html ( but my statement is
not based on this URL but on some other experience I've got
with Xalan. Long time ago. ).
To measure the 'real' performance of XSLT transformation, I suggest
trying 'real' XSLT engine, like SAXON or XT in 'precompiled stylesheet'
mode.
Also please take into account that if your XML components will generate
not the XML files but the stream of SAX events - you'l also get a performance
boost. By the way : stay away from DOM, if you care about speed.
Also please take into account that when you have caching, the speed of
particular transformation becomes less important.
There are actually many other tips and tricks to produce fast XSL-based
server-side solution. Consider hiring experienced contractor. No kidding.
> Using XML/XSL is the future, is what "they" say,
In fact what "they" really say is "XML/XSL on client side is the future".
They were not thinking about XML/XSL on server at all.
> but I wonder: is this /ever/ going to work in real-time applications?
Not only it can work, but it already works. Can not disclose some more info,
sorry.
Because cell-phones ( and other devices ) usually come without built-in
XSLT engine - I don't think server-side XSL rendering scenario is
temporary.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list