9 ms·

I'm a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype. Also the point about the ad-hoc client vali

I'm a bit annoyed that the author of the article seems to be imply that the move away from XML is just due to hype. Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow. My biggest gripes with XML are twofold: - It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help). - The community seems to have this obsession with solving every problem under the sun with more XML and more specifications. I believe, this is wrong. Trying to standardise across the whole range of data interchange and configuration needs is the wrong approach, IMHO. JSON wins here, because it gets out of the way. I do wish JSON had comments and that JSON schema was better (for when you really need it), but nobody ever had an expectation that keys are unique across all JSON documents in existence, something that XML somehow insists is necessary for its elements and attributes. But what the author is right about is that YAML is an absolute nightmare, and I can't understand why it continues to be so popular. Apart from the dozens of ways of writing booleans or strings, it's also way, way too easy to forget what level of indentation you're currently at, especially if you're navigating large files like Kubernetes or CI configs. I think more projects (at least larger ones) should adopt their own DSL for configuration. For example, I find the terraform config format much cleaner than any of the YAML stuff.

kanox 6y ago
The biggest advantage of JSON and YAML is that it has a very straight-forward object model consisting of literals, lists and dicts. All of these constructs map very easily to native data structures in most languages: you can just "load" and "save" an arbitrary json or yaml document. The XML DOM is very different and does not map in an obvious way to objects in any programming language: you either use a DomDocument or object serialization for a subset of XML. This alien object model makes programming with XML painful and verbose for no gain. Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don't have to deal with elements and attributes. If standardization around YAML and XML was equally good would anyone pick XML? > way too easy to forget what level of indentation you're currently at This is easily solvable by tools. How is it worse than getting lost in braces or open/close tags? > I think more projects (at least larger ones) should adopt their own DSL for configuration. Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file.
- Tainnor 6y ago
  > This is easily solvable by tools. Maybe, but I want it to work with standard tools. Most editors seem to arbitrarily jump back a couple of indentation levels e.g. if you add newlines somewhere. This obviously doesn't happen with JSON, since the editor won't have to guess whether you wanted to de-dent or not, it's all explicit. And I'm not making this problem up, it's literally a problem almost every time I have to edit some larger YAML file. I'm not a fan of whitespace sensitivity in programming languages either, but at least Python etc. make a habit of discouraging 15 layers of indentation. > Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file. What? Why would you parse a DSL with regex? I'm not saying people should write crappy DSLs. You can either write your own proper parser or you just use an embedded DSL, since there are multiple languages out there who are quite good at providing DSL support. The bonus is that it's often even type-safe, without having to be as mind-numbingly obtuse as XML.
  - Pako 6y ago
    On the note of type safety I can always suggest people to take a look at Dhall. https://dhall-lang.org https://dhall-lang.org
    - Tainnor 6y ago
      Yes, this is something I've wanted to check out for a while now, I just don't think I could convince other people on any team to look at it. :D
  - thinkharderdev 6y ago
    I've had the same experience. Different editors and IDEs seem to handle YAML in wildly different ways. If you copy/paste a YAML stanza into a different document there is no telling how the editor is going to indent it. And trying to fix it can be something of a nightmare, especially when the editor indents different lines in the pasted text differently.
  - 6y ago
AnimalMuppet 6y ago
To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format. Annoyingly verbose: Yup. Absolutely. I thought XML was kind of OK. Then I learned some about S expressions, and looked at XML with those eyes, and it was absolutely disgustingly verbose.
- Tainnor 6y ago
  > To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format. Maybe I'm misunderstanding, but it seems to me you can do the same thing with JSON.
  - AnimalMuppet 6y ago
    Sure. It's just that, during the days that I had to do much with XML, JSON wasn't really a thing yet. I'm comparing XML to the binary formats that came before it (in wide use), not to JSON that came after it.
Phrodo_00 6y ago
My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. You can also use multiple child tags and it's not obvious whether you should mix multiple kinds or not. The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. You can have style guidelines, but other data formats don't really need that to answer those questions. More flexible is not always better, especially in languages.
- thesuperbigfrog 6y ago
  >> XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. >> The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. Either approach is valid. Having a choice about how to structure the data is not a bad thing. My preferred approach is to use attributes for simple key-value pairs that are mainly used to select structured data found in child tags. If you have configuration data that is stored as XML, you could use attibutes to mark where the contained structured data should be used. For example: 1) language localization data could be stored stored in XML with attributes describing the language or locale; 2) build configuration settings might be stored in XML with attributes describing the target platform or CPU architecture. For more formalized data formats, create an XML Schema that defines what the XML data should look like and then you can easily validate that the XML data is structured correctly and even generate parsers or XML to programming language bindings.
  - SiempreViernes 6y ago
    > Either approach is valid. Having a choice about how to structure the data is not a bad thing. I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. In another sense, xml gives no options: your data is going to live in a string.
    - thesuperbigfrog 6y ago
quercusa 6y ago
> - It's as annoyingly verbose as Java is I reviewed an XML-based international industry 'standard' that allowed both verbose and terse versions of the same tags. Example files I saw tended to use the terse ones for common tags and the verbose ones for rare ones.
- SahAssar 6y ago
  The last time I dealt with XML based services I tried to push "If we can't be right let's at least be consistent"
bryanrasmussen 6y ago
>- It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help) I guess if you take the effort to make it as annoyingly verbose it is, but in regards to namespaces for example Joe English's email on the psychopathologies of namespace usage http://www.flightlab.com/~joe/sgml/sanity.txt http://www.flightlab.com/~joe/sgml/sanity.txt if followed for best practices also has the side effect of reducing much potential verbosity.
solatic 6y ago
> Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow. To be fair, there are often tools that will generate object definitions in the target language from an XML schema. It's not a perfect solution - you need to rebuild the project when upstream changes - but it's not like this hasn't been addressed. For what it's worth, Protobuf has the same property.
- Tainnor 6y ago
  Yes. And then you end up with a domain-model that is badly designed because XML is not capable of expressing rich and nice-to-use data structures (as is possible both in OOP and in FP languages). You end up with lowest-common-denominator stuff, at which point you might just as well use JSON and parse it into something type-safe yourself (or not, and just use it as a [String: Any] dict).
GoblinSlayer 6y ago
Matrix protocol uses JSON with namespaces, both Java-style, C and XML-style namespaces.
- SamWhited 6y ago
  And because it's non-standard it's irritating. Every JSON parser doesn't have this built in, so you have to implement it at the application layer if you want it.

kanox 6y ago

The biggest advantage of JSON and YAML is that it has a very straight-forward object model consisting of literals, lists and dicts. All of these constructs map very easily to native data structures in most languages: you can just "load" and "save" an arbitrary json or yaml document. The XML DOM is very different and does not map in an obvious way to objects in any programming language: you either use a DomDocument or object serialization for a subset of XML. This alien object model makes programming with XML painful and verbose for no gain. Sure: standards for xml schema and xpath are pretty nice but there are json equivalents which don't have to deal with elements and attributes. If standardization around YAML and XML was equally good would anyone pick XML? > way too easy to forget what level of indentation you're currently at This is easily solvable by tools. How is it worse than getting lost in braces or open/close tags? > I think more projects (at least larger ones) should adopt their own DSL for configuration. Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file.

Tainnor 6y ago
> This is easily solvable by tools. Maybe, but I want it to work with standard tools. Most editors seem to arbitrarily jump back a couple of indentation levels e.g. if you add newlines somewhere. This obviously doesn't happen with JSON, since the editor won't have to guess whether you wanted to de-dent or not, it's all explicit. And I'm not making this problem up, it's literally a problem almost every time I have to edit some larger YAML file. I'm not a fan of whitespace sensitivity in programming languages either, but at least Python etc. make a habit of discouraging 15 layers of indentation. > Please don't. JSON, YAML and XML config files can be easily and safely manipulated in all programming languages, for custom DSLs people end up using brittle regexps. It's not much better than putting config consts in a code file. What? Why would you parse a DSL with regex? I'm not saying people should write crappy DSLs. You can either write your own proper parser or you just use an embedded DSL, since there are multiple languages out there who are quite good at providing DSL support. The bonus is that it's often even type-safe, without having to be as mind-numbingly obtuse as XML.
- Pako 6y ago
  On the note of type safety I can always suggest people to take a look at Dhall. https://dhall-lang.org https://dhall-lang.org
  - Tainnor 6y ago
    Yes, this is something I've wanted to check out for a while now, I just don't think I could convince other people on any team to look at it. :D
- thinkharderdev 6y ago
  I've had the same experience. Different editors and IDEs seem to handle YAML in wildly different ways. If you copy/paste a YAML stanza into a different document there is no telling how the editor is going to indent it. And trying to fix it can be something of a nightmare, especially when the editor indents different lines in the pasted text differently.
- 6y ago

AnimalMuppet 6y ago

To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format. Annoyingly verbose: Yup. Absolutely. I thought XML was kind of OK. Then I learned some about S expressions, and looked at XML with those eyes, and it was absolutely disgustingly verbose.

Tainnor 6y ago
> To me, one of the virtues of XML is that, if the server changes the XML response, you can capture it, and a human can eyeball parse it and figure out what went wrong, and figure out how to change the code on the receiving end to compensate. It's hard to automate, sure, but it's far better than having the server hand you some updated binary format. Maybe I'm misunderstanding, but it seems to me you can do the same thing with JSON.
- AnimalMuppet 6y ago
  Sure. It's just that, during the days that I had to do much with XML, JSON wasn't really a thing yet. I'm comparing XML to the binary formats that came before it (in wide use), not to JSON that came after it.

Phrodo_00 6y ago

My biggest gripe with XML has more to do with how data is structured: XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. You can also use multiple child tags and it's not obvious whether you should mix multiple kinds or not. The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. You can have style guidelines, but other data formats don't really need that to answer those questions. More flexible is not always better, especially in languages.

thesuperbigfrog 6y ago
>> XML offers both tag attributes and child tags and when encoding data it's not obvious which one to use. >> The usage is obvious when using XML as markup, but when used for data it's left to the one creating the particular spec. Either approach is valid. Having a choice about how to structure the data is not a bad thing. My preferred approach is to use attributes for simple key-value pairs that are mainly used to select structured data found in child tags. If you have configuration data that is stored as XML, you could use attibutes to mark where the contained structured data should be used. For example: 1) language localization data could be stored stored in XML with attributes describing the language or locale; 2) build configuration settings might be stored in XML with attributes describing the target platform or CPU architecture. For more formalized data formats, create an XML Schema that defines what the XML data should look like and then you can easily validate that the XML data is structured correctly and even generate parsers or XML to programming language bindings.
- SiempreViernes 6y ago
  > Either approach is valid. Having a choice about how to structure the data is not a bad thing. I though the point of using a well defined markup language was exactly that it imposed a clear structure on your data. In another sense, xml gives no options: your data is going to live in a string.
  - thesuperbigfrog 6y ago

quercusa 6y ago

> - It's as annoyingly verbose as Java is I reviewed an XML-based international industry 'standard' that allowed both verbose and terse versions of the same tags. Example files I saw tended to use the terse ones for common tags and the verbose ones for rare ones.

SahAssar 6y ago
The last time I dealt with XML based services I tried to push "If we can't be right let's at least be consistent"

bryanrasmussen 6y ago

>- It's as annoyingly verbose as Java is; I just get lost looking at all the tags (the namespaces don't help) I guess if you take the effort to make it as annoyingly verbose it is, but in regards to namespaces for example Joe English's email on the psychopathologies of namespace usage http://www.flightlab.com/~joe/sgml/sanity.txt http://www.flightlab.com/~joe/sgml/sanity.txt if followed for best practices also has the side effect of reducing much potential verbosity.

solatic 6y ago

> Also the point about the ad-hoc client validation doesn't seem right to me. If the server changes the XML response, the client may be able to fetch the updated schema (assuming the devs didn't forget to publish the update...), but then what? You still have to handle the new or updated fields in code somehow. To be fair, there are often tools that will generate object definitions in the target language from an XML schema. It's not a perfect solution - you need to rebuild the project when upstream changes - but it's not like this hasn't been addressed. For what it's worth, Protobuf has the same property.

Tainnor 6y ago
Yes. And then you end up with a domain-model that is badly designed because XML is not capable of expressing rich and nice-to-use data structures (as is possible both in OOP and in FP languages). You end up with lowest-common-denominator stuff, at which point you might just as well use JSON and parse it into something type-safe yourself (or not, and just use it as a [String: Any] dict).

GoblinSlayer 6y ago

Matrix protocol uses JSON with namespaces, both Java-style, C and XML-style namespaces.

SamWhited 6y ago
And because it's non-standard it's irritating. Every JSON parser doesn't have this built in, so you have to implement it at the application layer if you want it.