4 ms·

> they recently switched to JSON Considering this data is machine-generated and machine-ingested, moving away from XML seems like a big step down.

bastawhiz 3y ago
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.
- Exoristos 3y ago
  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.
  - ctxc 3y ago
    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.
  - feoren 3y ago
    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.
    - Exoristos 3y ago
      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.
      - feoren 3y ago
        > 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.
  - bastawhiz 3y ago
    > It also benefits from much more powerful and mature tooling. JSON is over two decades old. XML is only five years older. Both have powerful and mature tooling; I'm not sure how you can suggest otherwise.

bastawhiz 3y ago

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.

Exoristos 3y ago
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.
- ctxc 3y ago
  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.
- feoren 3y ago
  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.
  - Exoristos 3y ago
    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.
    - feoren 3y ago
      > 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.
- bastawhiz 3y ago
  > It also benefits from much more powerful and mature tooling. JSON is over two decades old. XML is only five years older. Both have powerful and mature tooling; I'm not sure how you can suggest otherwise.