4 ms·

Well, when it comes to object notation XML is actually less noisy than JSON. It has more characters (maybe), but fewer special symbols. For example, let's imagi

Well, when it comes to object notation XML is actually less noisy than JSON. It has more characters (maybe), but fewer special symbols. For example, let's imagine a notation to describe a chess party: <party xmlns="urn:mycompany:games:Chess"> <move white="e4" black="e5" /> <move ... /> </party> { "__type": "urn:mycompany:games:Chess:Party", "moves" : [ {"white": "e4", "black": "e5" }, { ... } ] } Compare the lines to describe the moves: <move white="e4" black="e5" /> {"white": "e4", "black": "e5" }, The one for JSON is actually two characters longer and (in my opinion) is harder to read because of all these noisy symbols to enclose and separate values. Lets' look at them in isolation: XML <=""=""/> JSON {"":"","":""}, This is indeed boilerplate. Also note that XML includes the element name, while with JSON we are supposed to know the object structure. (And while I'm at it note that this XML name, despite being just a generic "move", is actually globally unique so when you process XML with any tools you'll never mess up two different "move" elements from different XML dialects. With JSON our best shot is to have an in-house convention of how we mark object types and roll our own tools to check this.) At the end JSON kind of becomes more concise compared to XML: ]} </party> I don't think it's such a huge win, especially because these are again special symbols. Besides, being overly concise is not always a virtue. Compare, for example, the syntax of functions in Ada: procedure Test ... begin ... end Test; Note that the designers of Ada decided to require a qualifier after the generic "end" to clearly mark it as the end of a specific procedure. It's interesting to read Ada Design Goals[1], which clearly mentions this in the section "Concern for programmer: Language is small and consistent. Readability favored over writability". JSON has its strong points compared to XML, but for some reason every discussion about XML is riddled with over-the-top negative generalizations like "unusable absurd mess of a language", while in fact XML is a very solidly engineered thing. Just like Ada :) [1]: https://www.radford.edu/~nokie/classes/320/designGoals.html https://www.radford.edu/~nokie/classes/320/designGoals.html

geezerjay 8y ago
> For example, let's imagine a notation to describe a chess party: In that example XML is missing the XML declaration. Furthermore, JSON doesn't require a type field. That skews the comparison quite a bit. Furthermore, the amount od symbols is irrelevant. Otherwise brainfuck would be considered exemplar wrt clarity. > Also note that XML includes the element name, while with JSON we are supposed to know the object structure. Exactly, that's another way JSON is simpler than XML as it requires no boilerplate code to convey structure. That is particularly obvious in the sort of application covered in this discussion.
- Mikhail_Edoshin 8y ago
  XML declaration is optional (in 1.0, which everybody uses). My point was not that JSON is longer; JSON is noisier. XML in this example is longer, but easier to read because it has more content and less visual and cognitive overhead to convey the same structure (plus extra: element name). Some structural symbols are necessary, of course; we cannot just write "whitee4blacke5" (we can, in fact, it's parseable), but JSON uses more than XML. XML element names are not boilerplate, they're type names. Maybe configs do not need types, but who knows; maybe they do. Types are there for a reason. E.g. if users write configs, it would be totally cool to verify they're at least syntactically correct before using them. With JSON there's no standard way to do this; with XML there is. (And users write configs all the time; I, for example, being a user of Make and Apache routinely write Makefiles and .htaccess files.)

geezerjay 8y ago

> For example, let's imagine a notation to describe a chess party: In that example XML is missing the XML declaration. Furthermore, JSON doesn't require a type field. That skews the comparison quite a bit. Furthermore, the amount od symbols is irrelevant. Otherwise brainfuck would be considered exemplar wrt clarity. > Also note that XML includes the element name, while with JSON we are supposed to know the object structure. Exactly, that's another way JSON is simpler than XML as it requires no boilerplate code to convey structure. That is particularly obvious in the sort of application covered in this discussion.

Mikhail_Edoshin 8y ago
XML declaration is optional (in 1.0, which everybody uses). My point was not that JSON is longer; JSON is noisier. XML in this example is longer, but easier to read because it has more content and less visual and cognitive overhead to convey the same structure (plus extra: element name). Some structural symbols are necessary, of course; we cannot just write "whitee4blacke5" (we can, in fact, it's parseable), but JSON uses more than XML. XML element names are not boilerplate, they're type names. Maybe configs do not need types, but who knows; maybe they do. Types are there for a reason. E.g. if users write configs, it would be totally cool to verify they're at least syntactically correct before using them. With JSON there's no standard way to do this; with XML there is. (And users write configs all the time; I, for example, being a user of Make and Apache routinely write Makefiles and .htaccess files.)