Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hello Chris, Chris said: For a developer, at the present time, sending XML to the browser may lack a certain appeal because of the limits of browser implementation of XSLT, particularly XSLT 2.0. Tools available to the developer on the server-end are far more robust and up-to-date. Didier replies: I guess that you mean here that because of roughly 4% of non XSLT enabled browsers; client side transformation is not done on the client side. This even if roughly 96% of the current browsers are XSLT enabled. I am attributing this state of affairs to the lack of good partitioning tools able to detect the capacities of browsers and perform the transformation on the server side (4% of the time) or on the client side (96% of the time). Off course the main publication target are mobile devices, these numbers (96%-4%) do not stand anymore. We can also state that roughly 10% of browsers have scripting disabled and therefore cannot run web apps like gmail or google maps. That about 80% of browsers cannot decipher SVG, etc... The only language understood by all browsers is HTML and even though, not entirely. On the other hand we find sites publishing SVG maps and drawings. Sites publishing script enabled AJAX applications. Sites publishing videos (even if this requires to install a plug-in/activeX component and more probably requires a high speed connection). I personally think that the reasons are not a lack of XSLT enabled browsers but more a lack of good data round trip data maintenance on top of RDB (using XML as a marshalling format). Difficulties for a lot of developers to go out of the imperative programming comfort zone. So, the problem is not a capacity problem but more a social and human problem and some tools lacking like for instance the capacity to easily marshall in and out data packaged in XML format. Finally I think that a lot of data publisher are targeting people reading the content and not processing agent at the other end of the pipe. This can easily be understood by the fact that raw data can be re-packaged without any clear benefit to the original publisher. This last fact explains a lot why we do not see data packaged as XML but more readable material packaged in HTML. It's simple, There are more vested interest and benefits to provide reading material (or video content) than to provide raw data or potentially provide data that can be easily re-packaged without giving benefits to the original producers. Note that when google freely make available its map content to the publishers/developers, they provide images containing the google brand and credits. Hard to do with XML... Cheers Didier PH Martin
|
