[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Client-side XSLT. Re: Bad News on IE6 XML Support
- From: David Carlisle <email@example.com>
- To: firstname.lastname@example.org
- Date: Mon, 10 Sep 2001 00:44:06 +0100
> Could somebody please show me a *single*benchmark* illustrating
> that client-side XSLT load-balancing works and saves 'that much'.
speed/load depends on all sorts of issues and isn't particularly
interesting (well it is to some but...)
But client side XSLT makes things _possible_ that are otherwise not
possible. More exactly client side transformation, other languages would
be possible, but XSLT appears to be the transformation language of
choice at present.
It is naive to assume that all information can usefully or conveniently
be expressed in (X)HTML.
If I send (say) MathML to the client then that is rich information, they
may render it send it to a computer algebra system, send it to a speach
synthesis system, whatever.
The stylesheet to render it in a browser (if it's not using a plugin
absolute css positioning and any otehr tricks taht might make a
reasonable presentation in a version 5 browser (it would work in IE6 as
well, except MS pulled the XML support, which was what started the
thread on webrelease newsgroup referred to earlier.
I happen to be a mathematician and happen to be an editor of the MathML
spec so MathML is particulary interesting to me, but the same applies to
any XML language you might want to send, docbook, tei, svg, whatever.
Client side transformations allows you to send semantically rich
accessable data which is transformed as late as possible to the
rendering-only form. Server side transformation means you have to send
low level junk down the wire.
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.