> Why did xml lose to yaml/json? XML had gained complexity: schemas, namespaces, validation, translation, and then was extended to cover RPC behaviour via SOAP

> Why did xml lose to yaml/json? XML had gained complexity: schemas, namespaces, validation, translation, and then was extended to cover RPC behaviour via SOAP, WSDL, etc, with some annoyances and papercuts around escaping things and using CDATA. At a certain point the onboarding requirement for a new engineer who just wanted to exchange some data between two systems or write a config file was no longer "open a text file and write what you want" but "learn all of this tooling and perform this incantation". Then, when you factor in that JavaScript was becoming the default for everything on the web and JQuery had given the world a better interface to XmlHttpRequest... but that you had to then translate client-side the XML into JS objects... At this point convenience won. Just write the config file in JSON, send data as JSON over HTTP, have the browser just receive native JavaScript objects. Of course, time passes and now we're slowly adding in all of the complexity again as it turns out it's needed at a certain scale to be sure that systems work as intended. YAML emerged when managing JSON configs via build tools become troublesome (trailing commas within config files for arrays built via Puppet, etc). YAML solved that, and made it also a little easier to read (for some other compromises, like now being whitespace sensitive). Perhaps something else more convenient is just around the corner and we can do it all again. If you were to build a competitor to XML/JSON/YAML today... what would it look like?