3 ms·
I'm not disagreeing, but there's a case for simplistic config via JavaScript object literals in native JavaScript apps (node.js and browser apps). Of course, on
by tannhaeuser 8y ago
I'm not disagreeing, but there's a case for simplistic config via JavaScript object literals in native JavaScript apps (node.js and browser apps). Of course, once you confine yourself to the JSON subset of JavaScript object literals, you'll soon find yourself wanting commenting syntax and other things. What I don't get is people using JSON religiously in apps that are neither using JavaScript, nor provide browser-facing web services. For example, in Java you'd need to do the exact same things for JSON serialization that you'd be doing for XML serialization (eg. jackson/jackson-xml or JAXB annotations on POJOs).
The case for XML as service payload IMHO is when you need an upfront design with schemas and all for multi-party or vertical data exchange (such as for payment providers to stick to TFA's topic).
- dullgiulio 8y agoThe real difference between XML and JSON is that XML is not directly serializable to a data structure because it's too "rich", with both tag attributes and values. For serializing data DOM, XPath etc are really not the right fit.
- tannhaeuser 8y agoI agree. SGML/XML was invented for representing and editing semistructured text, not as generic data serialization format. In markup text, attributes are for data that isn't to be rendered itself, but for specifying how rendering should be performed and other things (how CSS fans thought it would be a good idea to make up an entire new ad-hoc language for this purpose, then reclaiming "HTML is for content not presentation" is another discussion). But the NoXML/JSON folks haven't really come up with a widely used alternative to eg. XML Schema (which isn't surprising since JavaScript isn't statically typed). The majority of the work where standardization of message payloads is useful (such as for parties in e-Commerce) has already been carried out. The world hasn't and couldn't have waited for JSON to become a viable alternative. Besides, what makes JSON so practical - that it is schema-less - is exactly the reason it isn't a good fit for describing upfront protocols for long-term multi-party data exchange.