4 ms·

> but XML requires APIs to work with in any meaningful way. And JSON doesn't?! Sure it does. E.g., I regularly use the jv API in libjq. I wouldn't want to u

> but XML requires APIs to work with in any meaningful way. And JSON doesn't?! Sure it does. E.g., I regularly use the jv API in libjq. I wouldn't want to use JSON in any other way than via an API, honestly. You could also argue that XSLT/XPath are part of the XML API / ecosystem, much the way I think of JSONPath / jq as part of the JSON ecosystem. And yes, the world has moved away from XML... for non-document purposes. XML was a poor fit for encoding non-document data. SOAP's use of XML to encoded non-document data sure sucked, though it died of other things too (e.g., REST becoming more popular and being more appropriate in some ways). That's why we have things like protocol buffers, flat buffers, etc. Some even remember XDR, NDR, ASN.1 and its many encoding rules. Some even remember those and curious enough to have noticed that protocol buffers is DER reinvented. JSON is much more appropriate for non-document data than XML, and unlike XDR/NDR/<various>buffers/DER/BER/CER/XER/PER/OER you don't have to agree on a schema a priori, which makes JSON very useful in REST APIs. But you could still define REST services in relation to schemas and then use OER or flat buffers to get very efficient encodings. At the end of the day it's all the same data no matter how you encode it, provided the choice of encoding doesn't force you to give up some metadata or force you to express it in a convoluted way. The point isn't that you can't do with JSON what you can with XML, or that you can't do with XML what you can with <various>buffers. The point is that XML has decades of evolution baked in already. You should not reinvent a document format without being very explicit about what's wrong with XML, what's missing that can't be added, and what you're willing to throw out, otherwise you'll find yourself replicating that evolution.

atombender 8y ago
JSON doesn't need an API because it's a subset of Javacript: const foo = { bar: n, children = users.map(({name, id}) => ({name, id}); } foo.x = 42; DOM: const foo = document.createElement("root"); foo.setAttribute("bar", `${n}`); for (const ({name, id)} of children) { const child = document.createElement("child"); child.setAttribute("name", name); child.setAttribute("id", id); foo.appendChild(child); } foo.setAttribute("x", `${42}`); Querying with jq isn't an "API". JSON and XML are both encodings of two different formal data models. The difference is that JSON is native to JS. XML requires an API to build a safe and valid document. There are simplifying wrappers around the DOM, but they'd be yet another API on top of an API. Also note how XML is string-based. In order to get any type safety at all you have to use XML Schema, which only works with a data consumer that also knows XML Schema. So given <foo x="1"/>, there's no way to tell arbitary consumers that x is, in fact, a number. There are undoubtedly toolchains that do higher-level manipulation of XML data so that you can serialize and deserialize rich, type-safe data, but the fact remains that you need such a toolchain, in every single language that is to deal with this data.

atombender 8y ago

JSON doesn't need an API because it's a subset of Javacript: const foo = { bar: n, children = users.map(({name, id}) => ({name, id}); } foo.x = 42; DOM: const foo = document.createElement("root"); foo.setAttribute("bar", `${n}`); for (const ({name, id)} of children) { const child = document.createElement("child"); child.setAttribute("name", name); child.setAttribute("id", id); foo.appendChild(child); } foo.setAttribute("x", `${42}`); Querying with jq isn't an "API". JSON and XML are both encodings of two different formal data models. The difference is that JSON is native to JS. XML requires an API to build a safe and valid document. There are simplifying wrappers around the DOM, but they'd be yet another API on top of an API. Also note how XML is string-based. In order to get any type safety at all you have to use XML Schema, which only works with a data consumer that also knows XML Schema. So given <foo x="1"/>, there's no way to tell arbitary consumers that x is, in fact, a number. There are undoubtedly toolchains that do higher-level manipulation of XML data so that you can serialize and deserialize rich, type-safe data, but the fact remains that you need such a toolchain, in every single language that is to deal with this data.