[
Lists Home |
Date Index |
Thread Index
]
IMHO, when the idea of XML + XSLT was first stirred up, I think there
was a window of time in which the idea could be rapidly adopted, or
pushed to the side. Inconsistencies and defectiveness of the browser
support meant it was pushed the side.
Didier, are you really commenting on XML + XSLT "on the visible Web", as
Roger has defined it? I agree that the client side experience *can* be
enhanced through transforms. But if all that's being done is presenting
plain-old-HTML it doesn't seem worth it. Perhaps I'm being too literal
here.
Didier PH Martin wrote:
> 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
>
>
>
>
>
>
>
|
