[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: json v. xml
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|