3 ms·

I surprises me that the author doesn't list XML as an option. XML has been used for configuration for 15+ years where I work with little or no issues. It is eas

I surprises me that the author doesn't list XML as an option. XML has been used for configuration for 15+ years where I work with little or no issues. It is easy to use and easy to read and because of that I will continue to prefer XML over the alternate format listed in the article.

nineteen999 8y ago
I have entire environments marked up as XML, including application servers and various parameters, database clusters and their replication parameters/partners etc. This feeds into automation for everything from inventory/hostvars for ansible, DNS zone file contents, DHCP configuration, placement of VM's on VMware hosts etc. Clear yet flexible structure and the ability to have attributes on the nodes itself as well as data within them makes it so much more versatile than YAML or JSON for me. Add to that XPath queries etc. xmllint/xmlstarlet/python+lxml are so useful, every time I try to process JSON with tools like jq I feel like I am going crosseyed.
- edejong 8y ago
  Yes, and editors with tab completion and validation based on XML schemas.
geezerjay 8y ago
> I surprises me that the author doesn't list XML as an option. The author points out that in his opinion the fact that JSON objects are sandwiched between brackets makes the language overly verbose. By the same reasoning this makes XML an unusable absurd mess of a language, even without taking into account all the boilerplate code.
- Mikhail_Edoshin 8y ago
  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.)
thayne 8y ago
I didn't mention XML for a couple of reasons: 1. As others mentioned it can be pretty verbose (especially with doctypes and namespaces) 2. Potential security concerns (https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...) although that doesn't matter so much if the configuration is trusted (not always the case though) and can be mitigated if you know what you are doing.

nineteen999 8y ago

I have entire environments marked up as XML, including application servers and various parameters, database clusters and their replication parameters/partners etc. This feeds into automation for everything from inventory/hostvars for ansible, DNS zone file contents, DHCP configuration, placement of VM's on VMware hosts etc. Clear yet flexible structure and the ability to have attributes on the nodes itself as well as data within them makes it so much more versatile than YAML or JSON for me. Add to that XPath queries etc. xmllint/xmlstarlet/python+lxml are so useful, every time I try to process JSON with tools like jq I feel like I am going crosseyed.

edejong 8y ago
Yes, and editors with tab completion and validation based on XML schemas.

geezerjay 8y ago

> I surprises me that the author doesn't list XML as an option. The author points out that in his opinion the fact that JSON objects are sandwiched between brackets makes the language overly verbose. By the same reasoning this makes XML an unusable absurd mess of a language, even without taking into account all the boilerplate code.

Mikhail_Edoshin 8y ago
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.)

thayne 8y ago

I didn't mention XML for a couple of reasons: 1. As others mentioned it can be pretty verbose (especially with doctypes and namespaces) 2. Potential security concerns (https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Pr...) although that doesn't matter so much if the configuration is trusted (not always the case though) and can be mitigated if you know what you are doing.