In what way is JSON a step down versus XML? Frankly I get nervous and sweaty every time I need to deal with XML, because of the inherent performance/security issues it brings into my codebase.
XML is much more precise and much more flexible. It also benefits from much more powerful and mature tooling. The few comparative downsides it has include verboseness, which doesn't matter to machines, and that younger devs don't know how to work with it, which again shouldn't be much of an issue in this use case.
XML is less precise, because it's more flexible. Powerful and mature tooling only matters to people creating and editing XML, not computers. XML Schemas are there to support human editors, not computers. Verboseness means larger files and longer processing times, which does matter to computers; the verbosity is explicitly and only there for human readers and editors. JSON is a much better format for something humans only occasionally look at.
You're wrong in almost every point. Flexible definition of data allows for greater precision of data structure. Something like XSLT isn't for human interaction; it's for super-powerful machine transformations. I'll grant XML files are larger, but not enough to make much difference when opening a music notation file. Any time a dev pushes back against XML, it's been my experience they are uneducated on the subject.
The reason why you don’t need some big, formal JSON schema (though they do exist) is because you can notate most of the constraints people care about in TypeScript. It’s just a bunch of structs, arrays, string enums, etc. XML doesn’t really have a nice mapping to type systems like that so it needs schemas.
My coup de grace against XML is that it is wholly unsuitable for serializing arbitrary strings in most programming languages. It’s defeated by quite simple strings like “hello\0world”. You can’t just escape the null using &#; because the standard, in its infinite wisdom, forbids it. Instead, you’re just expected to come up with some completely non-standard way like <null-char /> or just interpret “\0” specially in your application code. Meanwhile, JSON just lets you put pretty much whatever Unicode you want into a string with a standard way of escaping characters like the double quote.
> Flexible definition of data allows for greater precision of data structure.
Other way around. If there are 3 different ways of doing something, the data structure is less precise. Say you have an object with a Name as a string. You know exactly what this is going to look like in JSON:
{
"name": "Whizzbang"
}
How is it going to look in XML? It might look like this:
<Foo name="Whizzbang" />
It might look like this:
<Foo>
<Name>Whizzbang</Name>
</Foo>
It might look like this:
<Foo>
<Name value="Whizzbang" />
</Foo>
XML is less precise because it's more flexible. "But you just define an XML Schema to disambiguate" -- so now you're doing more work in a separate file that you have to publish and link in just to solve a problem that JSON doesn't have at all.
> Something like XSLT isn't for human interaction; it's for super-powerful machine transformations.
It's only "super-powerful" considering XSLT as a markup language. Considering it as a programming language, it rather sucks. If you're writing ETL scripts to transform data around, use an actual programming language. The fact that XSLT is Turing Complete only drives home the point that it's not a "powerful markup language", it's "poorly-designed programming language". Sure, if you're literally only transforming the exact same data from one XML schema to another, as some sort of adapter step, then XSLT beats general-purpose languages; but you're never just doing that, are you? You're linking in other data sources, validating things, sending things over the wire, etc. You already need the code to save and load your XML into a format you prefer in memory; just use that format for these tasks.
> Any time a dev pushes back against XML, it's been my experience they are uneducated on the subject.
Many people who push back against XML are not uneducated, but rather jaded on it, having worked with ambiguous formats, buggy schemas, and 4000-line long configuration behemoths that should have just been code. You can use XML parsimoniously, but there's not much overlap between the people doing that and the people who love XSLT.
Generally agree here. Just wanted to throw out another variant, additional tags and attributes can be added or modified by XML DTD files as well. The example XML could be just "<Foo />" with the additional values generated by a DTD file.
My experience has been similar to the immediate parent although I think xml looks better than json here. All fun and games till you forget to turn transforms and the 10 other knobs in your parser off.
The dev will be like "okay what are transforms though?" as they watch new calculator.exe instances popping up on the screen.