xsl-list
[Top] [All Lists]

RE: Is letting the browser transform XML to XHTML using XSLT a good choice?

2006-03-03 08:08:05
Hello Gowri,

You heard that it's better to do transform on the server side. I will give
you a more balanced point of view.

a) if you need to publish your apps or documents to the internet and want to
be sure absolutely everybody can access the apps or content, then, yes, it's
better to perform the transformation on the server side and transform into a
very basic HTML with very little (or preferably no) ECMAScript. In other
words target the least common denominator.

b) If you target an intranet or an internet niche market where most of the
browsers are upgraded to either firefox/mozilla (version 1.3 and up for
firefox and version 1.6 and up for Mozilla) or IE (version 6 and up - 5 may
be ok for transform but be careful on the HTML/ECMAScrip side) then you can
perform the transformation on the client side. I would comment that the IE
XSLT engine is less buggy than the firefox one. So if the intranet/niche
market has a majority or IE it's even better. If not, be cautious to test
with both. For instance a well known bug and still not resolved after more
than 5 years is the limitation on xpath constructs found in firefox/mozilla.
It is because, the internal XSL engine (transformMix) didn't got any
improvement since Keith from Mitre gave it to the Mozilla project. Bottom
line, if you target an intranet with a majority of IE browsers (v 6 and up),
go for a client side transformation with confidence. In other words, be
cautious firefox XSLT engine is buggy and test on both to be sure.

Note about testing if you intend to create a more sophisticated AJAX
application using XSLT: you'll have more success to test you AJAX
application in IE since the debugger (provided by either Microsoft Office or
Visual studio) will work after the transformation. Hence, produced
HTML/ECMAScript apps can be debugged after an XML to XSLT transformation. It
is not the case with Firefox. Firefox debugger (Venkman) doesn't use the
result of a transform as source for debugging but instead the orginal
document source which in the case of a transformation an XML document.
Bottom line, Firefox is a lousy environment to test AJAX applications using
XSLT transforms. But IE allows you to do that. Please note that I am in no
ways attached to Microsoft and what I am telling you now, is the result of
concrete experience but pseudo expertise or religious attachment to a
certain technology.

Now for XML to PDF transform and this is an opinion, not knowledge gained
from experience, I think that the advice given by others about FOP is a good
one. My limited experience of using FOP is also very good. But in that case,
forget about client side transform unless you include it into an applet. For
PDF transform I would also perform it on the server side. 

Up to my experience and knowledge client side transform is working well for:

HTML/ECMAScript (using output HTML), ECMAScript only (using output text),
SVG (using output XML)

In the last 3 years I was able to create very sophisticated applications and
applying model driven architecture using XML, XSLT, XHTML/ECMAScript and
SVG. In the last case using the Adobe plug-in/activeX to render SVG in the
IE browser. Data is encoded in XML and transformed into XHTML/ECMAScript,
SVG components and rendered in the browser preferably in IE (for reasons
mentioned earlier) 

Hope this more elaborate answer gives you enough info to base your decision.
If not, feel free to email me, *** real *** experience on client side XSLT
transformations is very rare. This is not the case for server side
transforms where the corpus of knowledge is well established, rich and
diversified.

Now let's go back to work....

PS: sorry for style and syntax errors, I wrote this in a rush between two
client side transformation debugging sessions ;-)

Cheers

Didier



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--