RE: Bad News on IE6 XML Support

[Didier PH Martin <martind@netfolder.com>]

Hi Bjoern

Didier said:
>c) if the transformation occurs on the server side, this same server just
>got its workload increased especially if the processed XML document is
>dynamically produced by a server side script.

Bjoern said:
I'm sorry but delivering the same XSLT transformation sheet to 1000
clients takes far more resources than one simple transformation.
Dynamically generated documents don't count; those scripts should have
produced XHTML instead of something else.

Didier replies:
Maybe you have some difficulties with the English language but this sentence
fragment makes the difference "especially if the processed XML document is
dynamically produced by a server side script". In this case, the same data
may need to be transformed 1000 times. Now let's take a look at this topic
from a different perspective. Out of these 1000 transactions, make the
hypothesis that 80% of these transactions are PC browser requests (like IE,
Mozilla or Opera) 20% of these transactions ofr other devices WML, VoiceXML,
etc... If you choused a vendor independent strategy to publish your data you
may have chosen an XSLT based strategy. (otherwise forget what I said). If
you do not have a multi-modal strategy I agree, you're better with XHTML or
even more with HTML since this latter has more support from the actual
vendors' tools.

As soon as you increase the number of XSLT enabled processor you gain more
processing power for you server. This sometimes implies reduced costs since,
this process partitioning may mean less servers in your servers' farm, less
rack space costs, etc.. For instance, out of these 80%, if the number of
XSLT enabled browsers increases, then your server has more free processing
time. Same thing for the remaining 20% of WAP or VoiceXML gateways. This
could also be the case if edge content management servers like, for
instance, Akamai support XSLT processing at the edge. Idem for cache servers
(i.e. proxies). The more we have XSLT processing at the edge, the more we
can publish data (instead of presentation) and adapt it to the requesting
device at the edge. This reduces your server workload.
What is missing today is:
a) support for XSLT on WAP2 gateways
b) support for XSLT on VoiceXML gateways
c) support for XSLT on LAN/MAN/intranets proxies
d) support for XSLT on Edge Content Server or Content Delivery networks like
Akamai
e) Support for XSLT on distributed networks like Gnutella, etc..

So, the whole question about data vs. presentation is the level of support
not only on local browsers but also in gateways, proxies, content delivery
networks, etc... The more we'll have support on these network elements the
more XSLT may be used to  transform the data (modeling language) into
rendition (rendering language). It seems that XSLT as a vendor neutral
language based on markup notation (i.e. itself XML based) is more adapted to
transform a data model encoded in XML into one of the actual vendor neutral
rendering languages (also based on XML: VoiceXML, XHTML basic, SMIL, SVG,
etc...). If the transformation workload is well partitioned on the net,
we'll probably start to see the internet Version 3.0 to show its nose.

Cheers
Didier PH Martin