RE: xslt on server-side vs. client-side

> - Server-side you could cache the transformation.  This is only valid if
the
> xml data never (or rarely) changes.

Caching happens at many levels on a properly designed server environment:
transform, file, database, referenced Java objects and HTML page come to
mind immediately. The hardware on the server will also have other assists.
You might get some of these on the client, but not all of them (e.g., when's
the last time you configured a client with 128MB of memory on a RAID
controller?).

> - The server is also centralized, so many high-processing transformations
> will more likely bog down if server-side is used.

You do have to design a server for the work loaded required... 

> - Client-side almost definitely saves processing time (possibility of
> avoiding multiple transformations), 

The main real life example I see offered up is resorting of tabular results.
It seems to me that the main time you can design for client side transform
is on an Intranet where you have control over the client.  As such you have
some control over the network and it's likely a LAN or WAN.  As such, if the
table is really big enough to have an impact on the network then it's likely
that client is in danger of running into problems crunching the thing in the
first place...?

> electricity (network traffic all
> requires electricity all along the way), 

If and only if you have reused transforms on the client.

> less help desk headaches (less of a lag
> on the client so less angry people calling up to demand that it get
faster)

Boy, that seems a leap.  Ever had to field the support calls that come in
when you upgrade a users browser from what they are used to? (Or for that
matter, ever had to manage the support costs associated with upgrading 2000
copies of IE 5 to use MSXML 3?)




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list