OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] [SUMMARY #1] Why is there little usage of XML on the'visib

[ Lists Home | Date Index | Thread Index ]

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








 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS