[
Lists Home |
Date Index |
Thread Index
]
Hello Mitch,
Mitch said:
First, because the trouble of dealing with non-existent or defective browser
implementations means delivering XML + XSLT to the client is not worth the
effort.
Second, because the client-side experience isn't sufficiently enhanced to
warrant the transform on the client side.
Third, because it isn't worth it to me to share my grocery list.
Didier replies:
Sorry Mitch I have to disagree on several points:
a) if you target solely XSLT 2.0 then you are right, none of the actual
browsers are supporting XSLT 2.0. I you can deal with the XSLT 1.0
limitations, then, roughly 96% of the actual browsers in the fields are
waiting to process XML documents with XSLT 1.0. The only real limitation I
encountered so far when browsers are performing XSLT transformations is with
Mozilla when using long or complex XPath expressions. Otherwise, I am able
to perform quite sophisticated transformations without any problems.
b) Client side experience can be tremendously enhanced by a client side
transform. I agree that the views can be created through other means and
that clients deal more with what they see and interact than with what's
behind. I agree that an alternative way is to set an AJAX like structure
expressed as HTML and then use JASON like data transfer (in and out) or use
a web service client.
Like I said previously, the real drawback to client side transformations
isn't a lack of XSLT support in browsers but more a lack of simple and
efficient technologies to perform round trip data manipulation with
relational data bases. When we will be able to create an XML document from
tables in RDB (we can do that that today with SQL/XML or XQuery) and then
send back the same updated document to a process that will dispatch the data
back to RDB (not available today) then you get now a real incentive to use
client side transformation from XML data encoded (i.e. the model) into
rendering languages like for instance XHTML/HTML, SVG, SMIL or any other XML
based rendering language implemented by browsers or third parties plug-ins.
Bottom line:
I would restate one of Roger's assumptions to say that the visual web is
actually based on a dominant rendering language: HTML. Alternative rendering
languages like SVG or SMIL are still confined to certain niche
markets/targets. The "data model" to rendition transformation paradigm is
absent (with only very rare exceptions) from the visual web. Reasons are
based on business matters (ex: information/brand protection) and actual
technical reasons (lack of two way XML marshalling technologies). Possibly
also due to the fact that search engines do not index XML encoded data but
do encode more static structures (i.e. readable documents).
Cheers
Didier PH Martin
|
