We tried this a while back. The server code would sniff out if the client
had an XSLT engine (mainly by cracking the user-agent and matching it against a
client. We didn't embed the stylesheet reference inside the XML at that time. A
few of the issues we learned from the experience:
XSLT engines on the server and client may not be the same, so you have to be
very careful what flavor of XSLT you use. Yes, it was supposed to be all
compatible, but in practice, XALAN-J on Solaris and MS-XML on the desktop did
things differently. With XSLT 2.0, the gap will get even worse, I
There was too much performance variance on the client. Unfortunately, the
server doesn't necessarily know the memory/CPU configuration of the client
before sending up raw XML. It seems to me the decision point for
whether to do the processing on server vs. client isn't whether the client *has*
an XSLT engine, but whether the user experience is enhanced by doing it up there
in the desktop. We thought of putting up a sort of 'pre-tester plug-in' up in
the client to sniff out performance metrics and communicate it to the server
(the way videogames 'pre-test' your graphics card and build a capability profile
the first time you run them). Haven't tried that yet.
get a *lot* of performance boost if you can cache the stylesheet and graphics up
in the client. We used a programmable browser cache program we had developed and
the performance was much better since you usually only had to download the raw
XML data and could retrieve the XSLT stylesheet locally. But since not every
client has the cache software, you still have to develop your server code to
handle other clients.
pragmatic matter: when you're under deadline to build a web-based application,
you barely have enough time to finish the server-side code, let alone branch it.
Effectively you are writing two applications in one. You can do some clever
designs to reduce this work, but it's extra work that would otherwise delay a
project, requiring some advanced programming, and may or may not provide a
Overall, I think the approach has merit. But the server frameworks have a
long way to go before being able to handle this automatically. Until then, you
have to roll your own.
Does anyone built or is using a
server able to partition the XSLT transformation process either on the server
side or on the client side. In other words, if the client support XSLT, then
the server sends the XML document with the stylesheet link included in the
document (the client performs the transformation). Otherwise, if the client
does not support XSLT, the transformation occurs on the server side (the
server performs the transformation).
question. Does anyone have build or is using an XSLT engine able to stand as a
reverse proxy. Is this reverse proxy having the capabilities mentioned above.
Thanks a lot for your
Note: This is not a marketing
survey, I am writing a text about the current state of the art in the XML
world. I mean the real world not the political or the philosophical world but
a world with a the day to day usage of XML. So I need
to know what is _really_ being
used in the field.