6 ms·

JSON mania has given me an appreciation for XML not having been so bad after all.

by juped 5y ago

dnautics 5y ago
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
jchw 5y ago
I like JSON a lot more than XML for what JSON is used for. XML did have some advantages, like more standards for schemas and templating, but the JSON ecosystem has at least decent facsimiles for these facilities. But the real star of the show is the data model: XML is a markup language. Jamming data structures into it is awkward. Not so for JSON, which has two aggregate types, a list type and a map type, followed by the usual suspects of primitive types: string, number, boolean, null. I can implement a full, strict, compliant JSON parser in an afternoon, maybe even less time. It is simple enough to parse that you can even do it in pure C with relative ease. XML is a lot more complex and a lot of implementations skimped pretty hard on the details. I mean I have fond memories of tinyxml2, and if you take apart any app made in the 2000s you have a good chance of finding reference to it (or on Windows-only apps, MSXML3, or on Linux, libxml...) but it certainly let you do a lot of surprising things. I saw a lot of apps doing XML documents with multiple root nodes. And Apple's plist format is a nightmare. It's so easy to fuck up interpreting XML plist, that Apple did, and it lead to one of the more entertaining privilege escalation bugs in iOS history. I have some fond memories, but I just don't miss XML. :)
- skissane 5y ago
  One thing I miss from XML is namespaces. Made it easy to extend an existing format with some custom extensions, with the likelihood that tools that didn't know the extensions would just ignore them, and that your extensions wouldn't conflict with anybody else's or with future versions of the underlying format. I haven't seen any widely-adopted equivalent in JSON. I've seen some proposals floating around but none of them seem to have really taken off.
  - XorNot 5y ago
    God no. No one handles XML namespaces well. They are an absolute nightmare to deal with in almost every language. We already have this in JSON: add a hashmap key with a prefix. It's at least as robust provided tools do the sensible thing and ignore keys they don't care about. But as with XML, sometimes, they don't, or do, or something.
    - 5y ago

JSON mania has given me an appreciation for XML not having been so bad after all.

by juped 5y ago

JSON mania has given me an appreciation for XML not having been so bad after all.

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

jchw 5y ago

I like JSON a lot more than XML for what JSON is used for. XML did have some advantages, like more standards for schemas and templating, but the JSON ecosystem has at least decent facsimiles for these facilities. But the real star of the show is the data model: XML is a markup language. Jamming data structures into it is awkward. Not so for JSON, which has two aggregate types, a list type and a map type, followed by the usual suspects of primitive types: string, number, boolean, null. I can implement a full, strict, compliant JSON parser in an afternoon, maybe even less time. It is simple enough to parse that you can even do it in pure C with relative ease. XML is a lot more complex and a lot of implementations skimped pretty hard on the details. I mean I have fond memories of tinyxml2, and if you take apart any app made in the 2000s you have a good chance of finding reference to it (or on Windows-only apps, MSXML3, or on Linux, libxml...) but it certainly let you do a lot of surprising things. I saw a lot of apps doing XML documents with multiple root nodes. And Apple's plist format is a nightmare. It's so easy to fuck up interpreting XML plist, that Apple did, and it lead to one of the more entertaining privilege escalation bugs in iOS history. I have some fond memories, but I just don't miss XML. :)

skissane 5y ago
One thing I miss from XML is namespaces. Made it easy to extend an existing format with some custom extensions, with the likelihood that tools that didn't know the extensions would just ignore them, and that your extensions wouldn't conflict with anybody else's or with future versions of the underlying format. I haven't seen any widely-adopted equivalent in JSON. I've seen some proposals floating around but none of them seem to have really taken off.
- XorNot 5y ago
  God no. No one handles XML namespaces well. They are an absolute nightmare to deal with in almost every language. We already have this in JSON: add a hashmap key with a prefix. It's at least as robust provided tools do the sensible thing and ignore keys they don't care about. But as with XML, sometimes, they don't, or do, or something.
  - 5y ago