Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Bad News on IE6 XML Support
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
