9 ms·

JSON is a poor format for humans But do you know what sucks even harder? XML. If I can replace an XML configuration file with JSON then screw it.

Filligree 8y ago
Why would you limit yourself to those two options? Use TOML or something.
- amelius 8y ago
  TOML kinda breaks down when you have nested data: https://stackoverflow.com/questions/48998034/does-toml-support-nested-arrays-of-objects-tables https://stackoverflow.com/questions/48998034/does-toml-suppo...
  - ChrisSD 8y ago
    Your link shows nested data structures working? But regardless TOML is a configuration file format (like INI), not a general purpose data structure format (like JSON is).
    - TheDong 8y ago
      > general purpose data structure format General purpose until you need to store dates/times, self-referential structures, enums, etc. json and toml are both serializations of data. I don't think the line you're trying to draw between "configuration file format" and "data structure format" is a well-defined line.
      - ChrisSD 8y ago
        Sure it's a blurry line but some formats are better than others for some specific tasks. JSON isn't the right tool for every job but it's a good enough lowest common denominator for data sharing. I wouldn't want to use if for config files or passing complex data but then it's not designed for that.
        afiori 8y ago
        TOML also has more "normal" notations for dicts and lists that are almost the same as JSON. There is a distinction between markup languages e object notation languages. XML, HTML and Markdown are markup, JSON, YAML, TOML and most other are object notations. (here my distinction, in general, is if they allow unquoted text)
  - Dylan16807 8y ago
    The answer to the question is "yes it is supported", it doesn't break down at all. It's even in the example file https://github.com/toml-lang/toml/blob/master/examples/example-v0.4.0.toml#L225 https://github.com/toml-lang/toml/blob/master/examples/examp...
    - je42 8y ago
      looks quite ugly. repeating keys... yaml looks better (while it has other problems)
Thiez 8y ago
How does it suck harder? Sure, the closing tags can be a bit annoying (but decent editors can insert those automatically), but attributes don't have that problem, and contrary to JSON it has comments.
- thechao 8y ago
  I find it interesting you're being downvoted. I think your question is reasonable: why does XML suck "harder" than JSON? This just seems a bit faddish to me. Things like namespaces and attribute/child distinction in XML are super annoying ... until you really need them in your ML (JSON, in this case). Then, suddenly, you're reinventing a wheel, hoping all of your downstream tools 'agree' on the behavior.
  - Thiez 8y ago
    The votes seem to be going the other way now :-) I've heard people prefer JSON over XML because XML is too complex... and now we have json schemas, jsonpath... the namespaces can't be far away. I'll admit that XML probably would be better without entities and the crazy whitespace handling.
  - joezydeco 8y ago
    Why does it suck harder? I’ll give one example: arrays. In JSON they’re plain and simple. You even get to use good ‘ol [ ] delimiters. In XML? It’s a sea of open and close tags. Now do an array of arrays. Then hand-edit it. Like I said, it’s no better. But it’s way easier to read.
- revvx 8y ago
  Closing tags is not really an issue with XML. In my experience, the biggest reason people hate it is because it has too many ways of structuring data, and it allows people who design the schemas to go overboard. Attributes or child nodes? Multiple namespaces or just extend the one you have? CDATA or embedding? That said, simple XML is as good as simple JSON. XML is fine if you keep it simple when designing the schema. AND of course one can screw up with JSON too. But after almost 20 years of people over-engineering their XML schemas, I can't fault anyone for choosing a simpler data format.
breck 8y ago
Shameless plug for a notation I work on: http://treenotation.org http://treenotation.org To me it’s an improvement over JSON which is an improvement over XML.
rmetzler 8y ago
At least XML has comments and you can simply duplicate the last element in a list without fear of forgetting a comma. XML has other problems though.
- TeMPOraL 8y ago
  And the problem would not exist if we just used the good ol' s-expressions. Gets all the structural benefits of XML and JSON with few of the drawbacks.
  - afiori 8y ago
    The problems people have with XML is not the syntax. Also, how would you represent (optional) attributes in s-expression? I could think of a couple ideas but none that is nice.
    - int_19h 8y ago
      Basic S-expressions also don't distinguish between lists and maps, which is something that turns out to be very convenient in practice. Sure, a map is just a list of pairs - but the deserializer needs to be aware of its meaning to parse it into the appropriate data structure. So you either need a schema even for the most trivial cases, or you need a distinct syntax. EDN is a better Lisp-flavored candidate, IMO.
      - kazinator 8y ago
        Basic S-exp syntax can easily be extended to denote dictionaries. Just like #(...) gives us vectors and #S structures, some #H can provide hash tables.
        int_19h 8y ago
        Of course, but then we're not talking about raw S-exps, but something built on top of them. And then you get something like EDN anyway.
manigandham 8y ago
Millions of developers use XML all the time, it's called HTML. People can easily read and edit it with deeply nested structures, attributes, and even malformed data. Frontend frameworks using components and variations like JSX also maintain the same style because it's very natural to use. Now try taking a typical HTML document and expressing it in JSON. Even an empty page would be completely unmanageable without tooling. People have a strange reaction when they hear "XML" but it's much more structured, usable, and widespread than you think.
- therein 8y ago
  I think the stigma comes from issues using XQuery etc. Not that they are unusable but they require adjusting your way of thinking.
  - int_19h 8y ago
    But XQuery (and XPath, being its subset) is pretty much just pure sequence comprehensions for the XML Data Model. It might have been unusual from a mainstream PL perspective back when it was introduced, but today, when C# has LINQ, and JS developers preach the miracles of map/filter/fold over immutable data structures, I don't think XQuery is all that exotic.
  - manigandham 8y ago
    JSON has no querying system, it can only be accessed by deserializing to an in-memory object or using whatever custom APIs are available (like postgres json functions). JsonPath is the proposed standard, and it looks pretty much like XPath. And that's before getting into Json Schema.
- gridlockd 8y ago
  > Millions of developers use XML all the time, it's called HTML. HTML is not XML and even then few developers today use HTML without some sort of processing involved. HTML is also not a language used for configuration files, so it is really off-topic. The question is, do people prefer XML configuration over JSON configuration. The answer is that people generally prefer JSON. JSON just maps far better to data types we use in everyday programming. Have you seen some of the common ways of expressing key-value pairs in XML? It's horrible. > Now try taking a typical HTML document and expressing it in JSON. That's not the problem anybody is trying to solve here. We're talking about configuration files, not complex documents. But let's say I wanted to solve that problem, the representation would look like this: http://www.jsonml.org/ http://www.jsonml.org/ Not that bad at all.
arcticbull 8y ago
This is a false choice. These aren't the only two options.
icedchai 8y ago
XML does suck, but at least it supports comments.
statictype 8y ago
Its easy to write multiline xml and add conments. Cant do that with json.
monocasa 8y ago
At least XML has comments.
emn13 8y ago
I mean, we're not going back to xml anyhow; and xml is considerably older anyhow, so this is a pretty hypothetical case. But I'd posit that most - but not all - of the issues with xml config files have little to do with xml per se, and everything to do with the crazily detailed stuff people squeezed in it. You don't have to stick everything in a namespace, and nest even trivial things 3 deep with annotations for obvious types. And if you do those things in json it turns into a mess too. SOAP is a perfect example of that. But: just because soap is messy doesn't imply xml everywhere has to be that. But sure, xml has some downsides. Then again, so does json. Oh well!

Filligree 8y ago

Why would you limit yourself to those two options? Use TOML or something.

amelius 8y ago
TOML kinda breaks down when you have nested data: https://stackoverflow.com/questions/48998034/does-toml-support-nested-arrays-of-objects-tables https://stackoverflow.com/questions/48998034/does-toml-suppo...
- ChrisSD 8y ago
  Your link shows nested data structures working? But regardless TOML is a configuration file format (like INI), not a general purpose data structure format (like JSON is).
  - TheDong 8y ago
    > general purpose data structure format General purpose until you need to store dates/times, self-referential structures, enums, etc. json and toml are both serializations of data. I don't think the line you're trying to draw between "configuration file format" and "data structure format" is a well-defined line.
    - ChrisSD 8y ago
      Sure it's a blurry line but some formats are better than others for some specific tasks. JSON isn't the right tool for every job but it's a good enough lowest common denominator for data sharing. I wouldn't want to use if for config files or passing complex data but then it's not designed for that.
      - afiori 8y ago
        TOML also has more "normal" notations for dicts and lists that are almost the same as JSON. There is a distinction between markup languages e object notation languages. XML, HTML and Markdown are markup, JSON, YAML, TOML and most other are object notations. (here my distinction, in general, is if they allow unquoted text)
- Dylan16807 8y ago
  The answer to the question is "yes it is supported", it doesn't break down at all. It's even in the example file https://github.com/toml-lang/toml/blob/master/examples/example-v0.4.0.toml#L225 https://github.com/toml-lang/toml/blob/master/examples/examp...
  - je42 8y ago
    looks quite ugly. repeating keys... yaml looks better (while it has other problems)

Thiez 8y ago

How does it suck harder? Sure, the closing tags can be a bit annoying (but decent editors can insert those automatically), but attributes don't have that problem, and contrary to JSON it has comments.

thechao 8y ago
I find it interesting you're being downvoted. I think your question is reasonable: why does XML suck "harder" than JSON? This just seems a bit faddish to me. Things like namespaces and attribute/child distinction in XML are super annoying ... until you really need them in your ML (JSON, in this case). Then, suddenly, you're reinventing a wheel, hoping all of your downstream tools 'agree' on the behavior.
- Thiez 8y ago
  The votes seem to be going the other way now :-) I've heard people prefer JSON over XML because XML is too complex... and now we have json schemas, jsonpath... the namespaces can't be far away. I'll admit that XML probably would be better without entities and the crazy whitespace handling.
- joezydeco 8y ago
  Why does it suck harder? I’ll give one example: arrays. In JSON they’re plain and simple. You even get to use good ‘ol [ ] delimiters. In XML? It’s a sea of open and close tags. Now do an array of arrays. Then hand-edit it. Like I said, it’s no better. But it’s way easier to read.
revvx 8y ago
Closing tags is not really an issue with XML. In my experience, the biggest reason people hate it is because it has too many ways of structuring data, and it allows people who design the schemas to go overboard. Attributes or child nodes? Multiple namespaces or just extend the one you have? CDATA or embedding? That said, simple XML is as good as simple JSON. XML is fine if you keep it simple when designing the schema. AND of course one can screw up with JSON too. But after almost 20 years of people over-engineering their XML schemas, I can't fault anyone for choosing a simpler data format.

breck 8y ago

Shameless plug for a notation I work on: http://treenotation.org http://treenotation.org To me it’s an improvement over JSON which is an improvement over XML.

rmetzler 8y ago

At least XML has comments and you can simply duplicate the last element in a list without fear of forgetting a comma. XML has other problems though.

TeMPOraL 8y ago
And the problem would not exist if we just used the good ol' s-expressions. Gets all the structural benefits of XML and JSON with few of the drawbacks.
- afiori 8y ago
  The problems people have with XML is not the syntax. Also, how would you represent (optional) attributes in s-expression? I could think of a couple ideas but none that is nice.
  - int_19h 8y ago
    Basic S-expressions also don't distinguish between lists and maps, which is something that turns out to be very convenient in practice. Sure, a map is just a list of pairs - but the deserializer needs to be aware of its meaning to parse it into the appropriate data structure. So you either need a schema even for the most trivial cases, or you need a distinct syntax. EDN is a better Lisp-flavored candidate, IMO.
    - kazinator 8y ago
      Basic S-exp syntax can easily be extended to denote dictionaries. Just like #(...) gives us vectors and #S structures, some #H can provide hash tables.
      - int_19h 8y ago
        Of course, but then we're not talking about raw S-exps, but something built on top of them. And then you get something like EDN anyway.

manigandham 8y ago

Millions of developers use XML all the time, it's called HTML. People can easily read and edit it with deeply nested structures, attributes, and even malformed data. Frontend frameworks using components and variations like JSX also maintain the same style because it's very natural to use. Now try taking a typical HTML document and expressing it in JSON. Even an empty page would be completely unmanageable without tooling. People have a strange reaction when they hear "XML" but it's much more structured, usable, and widespread than you think.

therein 8y ago
I think the stigma comes from issues using XQuery etc. Not that they are unusable but they require adjusting your way of thinking.
- int_19h 8y ago
  But XQuery (and XPath, being its subset) is pretty much just pure sequence comprehensions for the XML Data Model. It might have been unusual from a mainstream PL perspective back when it was introduced, but today, when C# has LINQ, and JS developers preach the miracles of map/filter/fold over immutable data structures, I don't think XQuery is all that exotic.
- manigandham 8y ago
  JSON has no querying system, it can only be accessed by deserializing to an in-memory object or using whatever custom APIs are available (like postgres json functions). JsonPath is the proposed standard, and it looks pretty much like XPath. And that's before getting into Json Schema.
gridlockd 8y ago
> Millions of developers use XML all the time, it's called HTML. HTML is not XML and even then few developers today use HTML without some sort of processing involved. HTML is also not a language used for configuration files, so it is really off-topic. The question is, do people prefer XML configuration over JSON configuration. The answer is that people generally prefer JSON. JSON just maps far better to data types we use in everyday programming. Have you seen some of the common ways of expressing key-value pairs in XML? It's horrible. > Now try taking a typical HTML document and expressing it in JSON. That's not the problem anybody is trying to solve here. We're talking about configuration files, not complex documents. But let's say I wanted to solve that problem, the representation would look like this: http://www.jsonml.org/ http://www.jsonml.org/ Not that bad at all.

arcticbull 8y ago

This is a false choice. These aren't the only two options.

icedchai 8y ago

XML does suck, but at least it supports comments.

statictype 8y ago

Its easy to write multiline xml and add conments. Cant do that with json.

monocasa 8y ago

At least XML has comments.

emn13 8y ago

I mean, we're not going back to xml anyhow; and xml is considerably older anyhow, so this is a pretty hypothetical case. But I'd posit that most - but not all - of the issues with xml config files have little to do with xml per se, and everything to do with the crazily detailed stuff people squeezed in it. You don't have to stick everything in a namespace, and nest even trivial things 3 deep with annotations for obvious types. And if you do those things in json it turns into a mess too. SOAP is a perfect example of that. But: just because soap is messy doesn't imply xml everywhere has to be that. But sure, xml has some downsides. Then again, so does json. Oh well!