Cart
[Home] [By Thread] [By Date] [Recent Entries]
Hello Mitch, Mitch said: My point is - maybe wrong but it is - that people saw it was not working very well, and said maybe later. And for Roger's scenario, they've been sending out HTML instead. Didier replies: Mitch, this is my own opinion and belief based on personal experiments, market study and observations. Let's distinguish two usage of XML: a) Data encoding also known as the "model" b) Rendition also known as the "view" Add to the last two the "control" or "behaviour" based on ECMAScript/javascript - XMLHttpRequest. You can create model driven applications with the couple XML/XSLT by performing a request to a server for some encoded data (in XML), then transform this model into a "view" using XSLT to construct a display list of HTML element/visual-aural objects. Even more, add to this "view" (the result of an XSLT transform) some behaviour incarnated by ECMAScript + XMLHttpRequest and you get something pretty sophisticated, at least as sophisticated as certain desktop applications. In fact, when this is well understood and well done, this leads to more versatile and adaptive applications. Now the bad thing is that if you modify the "model" incarnated by an XML document by modifying the XML document (adding, modifying, subtracting elements/attributes) you have actually no ways to send back the data and get it dispatched to the different tables in an RDB (I man here without writing a dedicated process to do it). So, you can easily, today, create an XML document from an SQL/xml or Xquery request. Hence, mapping a set of flat arrays into a hierarchy of data, transform it into a view, add some behaviour for user interaction but cannot send it back to the server through the same channel. You will have to create your own code to do so and this is a show stopper. If, on the contrary, you can send back the data created with a SQL/XML or Xquery and see the latter being placed back automatically into the proper and respective tables, then you have power, economy of time and a valid offer from the market place. What is missing though is an intelligent RDB to XML mapping language for IN and OUT. Bottom line: AJAX was ECMAScript/javascript + xmlHttprequest. ECMASCript became very interesting when the capacity to communicate with the server was added to scripts. Plus a good re-branding and PR effort helped. Maybe today you can forget the X in Ajax because more and more people are discovering that transferring the data in JASON is more efficient and is interpreted faster than having to use XML. And since, anyway, you'll have to create some code to process the data IN and OUT, better do it in JASON and gain faster interpretation and a simpler less verbose format (easier to do with templates). If, in contrast, XML can be used two ways to communicate with RDBs using a single query definition that can intelligently map XML to tables for IN and OUT processes. Then you have a more convincing offer. Add to this compelling offer some re-branding and PR and voila how to create a phoenix Where this can be useful? for authoring. Every time I need to author something. Today, the visible web is mostly a "readable web" not an "authoring web". I think the authoring web is under construction. XML can be a good candidate but nig chuncks are still missing. For rendering format we have HTML as the king pin language. For interaction we have HTML + ECMScript/javascript. We'll see what will be the impact of the .net platform and XAML as an challenge to the incumbent rendering language. In any cases if the rendering language is XAML+script or HTML+script we still need a decent way to get data, and send back the modified one to the server. If we have a single XML - RDB mapping to define in the process (plus maybe the rage selection to fill the document) we are definitively into something useful and cost efficient. So what is needed? A) Query (data - xml mapping + range selection) ----> RDB --------------> XML encoded data B) XML encoded data (plus modifications) -----------> RDB Do I think W3C can do it? Do I think government spend wisely our money? Same answer for both :-) Do I think that a market driven vendor will do it? This is my hope. Can I do it? Probably yes if I got the talent to raise the money and make a decent living. Will I do it? I need a decent living :-) Cheers Didier PH Martin
|
