RE: [xml-dev] json v. xml

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

Hello

My own conclusions about the subject based on hundreds of hours of
experiments in Didier's labs.

a) JSON is obviously convenient in the context of javascript because it is
possible to convert the text data structure into working code with the
eval() function. Obviously parsing JSON is tremendously faster than parsing
XML if you need to later on access the object with javascript. The resulting
code can also be a lot easier to read and maintain. The CON is that if the
source of the data is unsafe, other harmful code can be included and
executed after the eval(). But within a trusted context and if you need data
to be processed with javascript, JSON wins on the speed, maintenance and
readability factors.

b) XML strength is if you use a model driven development and have a powerful
two way XML data store. In other words, a server able to give you data
formatted in XML, let you process it on the client side and return the
modified XML to update the content on the server without extra code.
Undortunately, we do not have yet such powerful server if the data is stored
in legacy relational database (at least without extra code to be written to
resolve the impedence mismatch - Even XQuery has not resolved the "return
the data" problem, just the "get the data" issue). So, if, by chance you
have a powerful XML store, then XML data (i.e. model) transformed into a
rendering language + script (i.e. HTML + ECMAScript) using XSLT can be a
powerful solution. IN that case we have XML data + XSLT transform --->
manipulation of the data by the user and hence the XML fragment is modified
---> the modified XML is sent back to the server to update its content. This
whole process is still more hope and desire than concrete offering from the
marketplace. But can be potentially a real solution for model driven
development.

Concusion: if working in a safe environment and if I need data to be
processed by ECMAscript at a later stage in the application (not for initial
rendering of the user interface), I use JSON (solution (a) because it is
tremendously faster, easier to use and maintain than XML. If I am lucky to
have the right XML server environment, then I prefer model driven
development or solution (b). In fact for a lot of reasons I prefer (b) but
found a lack of tool from the marketplace. The ideal situation would be that
data stores or any interface in front of them, offer a way to present an XML
representation of data, allowing a blend of data from different sources.
Assemble all that into an XML document let the client modify this XML
document and return it to the server or the interface which would take care
of storing, modifying the data correctly. The only code I would have to
write would be the request to assemble the XML, the transformation script or
transformation specification (could be XSLT for example), and an API to get
and post the XML document. However, this requires a new mindset that few
"procedure driven" developer would grasp unless the economical evidences are
offered by tools. In other words, this is a paradigm shift that could be
made only if we have the right tools. So, for now, JSON seems to be the best
candidate for "procedure driven" developers.

Cheers
Didier PH Martin