[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Is letting the browser transform XML to XHTML usin

Subject: RE: Is letting the browser transform XML to XHTML using XSLT a good choice?
From: Didier PH Martin <martind@xxxxxxxxxxxxx>
Date: Sat, 04 Mar 2006 18:22:33 -0500
check useragent
Hello Michael,

Michael said:
It's none of the above: it's because of costs and risks.

I think most of us can see that doing transformation on the client makes
sense in principle. But the problem is that you have much more control over
the server than you have over the client. As soon as you do things on the
client you have to cope with a bewildering variety of versions and variants,
and this is a nightmare for quality assurance and potentially for support
costs. Also, it means you have to put up with using highest-common-factor
technology: you can't use technologies like XSLT 2.0 until five years after
they emerge, despite the huge productivity gains they bring. (XForms and SVG
suffer from the same issues.)

So it's not an easy choice, and there's no single answer that's right for
every project.

The option of doing both - client side when possible and server side
otherwise - is one way forward, but it adds to your overall system
complexity and cost.

I reply:
I don't catch you Micheal, and I read two times your message before
answering. Do you mean it's a matter of cost of not doing the kind of server
extension we did about 6 years ago? If yes believe me, the cost where not
outrageous. If you mean a lack of market for it, you make me think that on
the basis of the comment I read on this list you are probably right.

If you meant is doing transformation on the server side instead of the
client side. I guess that you mean that unless you have the kind of server I
describe you cannot do it with decent costs. After all, the only requirement
is to check the user agent capabilities with a simple pattern match based on
the user-agent HTTP header. A database stating the capabilities or a more
simplier algorithm checking only for IE 5 and up and Firefox and mozilla and
you get more than 90% of the the potential web clients. For the other 10%,
the server side processor has just to insert the stylesheet processing
instruction. And obviously, target an XSLT version 1.0 processor because
it's the one supported by the browsers.

Like I said, I am surprised that no server add-on like that still do not
exist. And it is surely not a question of cost but more of attitude, market
potential and perception. For several years, I though that cocoon would
support such capability but it seems that a lack of imagination or vested
interest never materialized such useful feature in a web server add-on.

Didier PH Martin

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.