Right, because JSON makes a great ad-hoc data format. XML is a heavy duty format with very strict heavy duty tooling which can do things that JSON isn’t a great fit for (heavily nested, structurally complex, large, exactingly created, extremely formalized, etc.) Developers of a certain age were traumatized by having to work with XML that was the default choice for applications that JSON would have been a much better fit for: lightweight tasks with ad-hoc formats like simple configuration files, simple request data for async JavaScript, etc. They often had lax specifications with poorly considered nesting rules, improper namespace configuration, etc. Or, even worse, I had to regularly parse large amounts of XML handwritten in editors by nontechnical people following policies written by other nontechnical people that thought they were technical.
Having to parse a big pile of sloppy JSON data can inspire you to take an eeextra long lunch. Having to parse a big pile of sloppy XML using real XML tools inspires you take an extra long lunch browsing job openings that don’t contain the word XML.
My biggest issue with XML is trying to figure out if something is an attribute or a sub element. On the contrary, there are time when it would be nice for json to have attributes.
I think the only really happy path with XML is starting with an extremely rigid spec for extremely consistent data where you have official dtd releases if something changes, etc. I think if you’re trying to figure something structural out when you’re processing the data, you’ve already lost.
Comments
Right, because JSON makes a great ad-hoc data format. XML is a heavy duty format with very strict heavy duty tooling which can do things that JSON isn’t a great fit for (heavily nested, structurally complex, large, exactingly created, extremely formalized, etc.) Developers of a certain age were traumatized by having to work with XML that was the default choice for applications that JSON would have been a much better fit for: lightweight tasks with ad-hoc formats like simple configuration files, simple request data for async JavaScript, etc. They often had lax specifications with poorly considered nesting rules, improper namespace configuration, etc. Or, even worse, I had to regularly parse large amounts of XML handwritten in editors by nontechnical people following policies written by other nontechnical people that thought they were technical.
Having to parse a big pile of sloppy JSON data can inspire you to take an eeextra long lunch. Having to parse a big pile of sloppy XML using real XML tools inspires you take an extra long lunch browsing job openings that don’t contain the word XML.
My biggest issue with XML is trying to figure out if something is an attribute or a sub element. On the contrary, there are time when it would be nice for json to have attributes.
I think the only really happy path with XML is starting with an extremely rigid spec for extremely consistent data where you have official dtd releases if something changes, etc. I think if you’re trying to figure something structural out when you’re processing the data, you’ve already lost.
I think you meant to write "...paid well for..."
Some tools we don't get to choose. Part of any job.
That very much depends on the job. The job I had to process all that handwritten XML in was a library job.