5 ms·

I dunno, to me it's pretty clear that JSON has improvements over XML; XML: - does not entirely make it clear what should go into a tag attribute versus a neste

I dunno, to me it's pretty clear that JSON has improvements over XML; XML: - does not entirely make it clear what should go into a tag attribute versus a nested tag - conversion of those two features into a unified internal datatype can be tricky (for example, this property led to choices that for erlang's xmerl causes a security regression if you are handling user-submitted xml). - first class support for text inside of a tag is not what you want in 90% of data interchange events, and support for it creates a burden when deserializing. - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. - because there aren't good "best practices" around it, everyone rolls their XML schemas with their own ideas about what sort of thing should go where. The major benefit of XML is its obession with schematization means that at least in many case you can grab a schema and figure out an appropriate declarative command to obtain what you want (if you have the right library), but this has basically been conquered in JSONland using JsonSchema/OpenAPI, and stuff like JsonLogic.

bokchoi 5y ago
> - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. JSON's types are pretty anemic compared to the XMLSchema's datatypes[0]. Even it you don't use all of XSD's complex type system, having these basic datatypes is extremely useful and I wish JSON had similar. [0] https://www.w3.org/TR/xmlschema11-2/ https://www.w3.org/TR/xmlschema11-2/
- dragonwriter 5y ago
  > JSON's types are pretty anemic compared to the XMLSchema's datatypes The same thing is true if you replace “JSON” and “XMLSchema” with “XML” and “JSON Schema”, respectively. And also, though less so, if you do the same but replace “XML Schema” with “JSON” instead of “JSON Schema”.
legulere 5y ago
- JSON just has UTF-8. XML has encoding madness. - JSON has just one escape format and all unicode codepoints can be used. XML generally allows only certain unicode codepoints, at some places like element names its further restricted (Quick: Which characters are not allowed? What's the difference between XML 1.0 and 1.1 here?). XML escapes at every place differently. In comments you need to escape less than elsewhere. In attributes you can use newlines but they will get normalized to spaces, you have to hex-encode newlines. There's Cdata. - JSON doesn't have the entity madness with potential security issues. - JSON doesn't have namespaces that add a lot of complexity with little benefit
- smitty1e 5y ago
  JSON maps nicely into a python dictionary.
- npwr 5y ago
  JSON is arguably easier to read than XML
nly 5y ago
JSON can't express ordering or duplicate fields in a consistent way. Consider how you'd write these 2 bits of XML in JSON: <A>foo<C>bar</C></A> vs. <A>too<C>bar</C>uh oh</A> Without a schema, in the first case, how do you determine whether B should be "foo" or ["foo"]? In the second how do you preserve the relative ordering of B #1, C and B #2? I worked on a project where we had a parse tree that we wanted to serialize out, and for this reason XML was the natural choice.
- picometer 5y ago
 { "a": [ { "b": "foo" }, { "c": "bar" } ] } vs. { "a": [ { "b": "too" }, { "c": "bar" }, { "b": "uh oh" } ] }
 - nly 5y ago
 Yes, so in essence: - Only ever have a single key in each JSON object (treating them as tuples) - Make all object values arrays. It makes for some very unnatural looking JSON.
 - 8note 5y ago
 The only thing that doesn't look natural to me is that it's all on one line. Otherwise it's very clear about the data's format and when there's ordering required
 - dragonwriter 5y ago
 > It makes for some very unnatural looking JSON. Not to me; its a fairly standard and natural JSON pattern. It’s tue that it use is usually quite limited in any given representation, but usually the thing you are modelling in JSON isn’t general XML with no further knowledge of application domain or logical schema.
 - enriquto 5y ago
 > { "a": [ { "b": "foo" }, { "c": "bar" } ] } This looks like line noise to me. All that punctuation and quoting looks ridiculous. What is the problem with straightforward and trivial to parse things like [a] b = foo c = bar or even a.b = foo a.c = bar

bokchoi 5y ago

> - it's confusing what should be a text inside a tag versus a tag attribute. Or should that text be parsed into a number? At least JSON is strongly typed, you know what datatype is what just by looking at it. JSON's types are pretty anemic compared to the XMLSchema's datatypes[0]. Even it you don't use all of XSD's complex type system, having these basic datatypes is extremely useful and I wish JSON had similar. [0] https://www.w3.org/TR/xmlschema11-2/ https://www.w3.org/TR/xmlschema11-2/

dragonwriter 5y ago
> JSON's types are pretty anemic compared to the XMLSchema's datatypes The same thing is true if you replace “JSON” and “XMLSchema” with “XML” and “JSON Schema”, respectively. And also, though less so, if you do the same but replace “XML Schema” with “JSON” instead of “JSON Schema”.

legulere 5y ago

- JSON just has UTF-8. XML has encoding madness. - JSON has just one escape format and all unicode codepoints can be used. XML generally allows only certain unicode codepoints, at some places like element names its further restricted (Quick: Which characters are not allowed? What's the difference between XML 1.0 and 1.1 here?). XML escapes at every place differently. In comments you need to escape less than elsewhere. In attributes you can use newlines but they will get normalized to spaces, you have to hex-encode newlines. There's Cdata. - JSON doesn't have the entity madness with potential security issues. - JSON doesn't have namespaces that add a lot of complexity with little benefit

smitty1e 5y ago
JSON maps nicely into a python dictionary.
npwr 5y ago
JSON is arguably easier to read than XML

nly 5y ago

JSON can't express ordering or duplicate fields in a consistent way. Consider how you'd write these 2 bits of XML in JSON: <A>foo<C>bar</C></A> vs. <A>too<C>bar</C>uh oh</A> Without a schema, in the first case, how do you determine whether B should be "foo" or ["foo"]? In the second how do you preserve the relative ordering of B #1, C and B #2? I worked on a project where we had a parse tree that we wanted to serialize out, and for this reason XML was the natural choice.

picometer 5y ago
{ "a": [ { "b": "foo" }, { "c": "bar" } ] } vs. { "a": [ { "b": "too" }, { "c": "bar" }, { "b": "uh oh" } ] }
- nly 5y ago
  Yes, so in essence: - Only ever have a single key in each JSON object (treating them as tuples) - Make all object values arrays. It makes for some very unnatural looking JSON.
  - 8note 5y ago
    The only thing that doesn't look natural to me is that it's all on one line. Otherwise it's very clear about the data's format and when there's ordering required
  - dragonwriter 5y ago
    > It makes for some very unnatural looking JSON. Not to me; its a fairly standard and natural JSON pattern. It’s tue that it use is usually quite limited in any given representation, but usually the thing you are modelling in JSON isn’t general XML with no further knowledge of application domain or logical schema.
- enriquto 5y ago
  > { "a": [ { "b": "foo" }, { "c": "bar" } ] } This looks like line noise to me. All that punctuation and quoting looks ridiculous. What is the problem with straightforward and trivial to parse things like [a] b = foo c = bar or even a.b = foo a.c = bar