3 ms·

What I appreciate compared to xml is: - generic concepts like arrays and maps - lack of opportunity to invent names Every xml schema is a potential DSL th

• halostatue 4y ago
  Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them. For this JSON: { "part_numbers": [1, 2, 3, 4, 5] } You have two main ways to represent these in XML: <!-- repetition = array --> <order> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </order> <!-- wrapped repetition --> <order> <part_numbers> <part_number>1</part_number> <part_number>2</part_number> <part_number>3</part_number> <part_number>4</part_number> <part_number>5</part_number> </part_numbers> </order> Is this better than JSON? No, not particularly. But it’s no less clear than the JSON, and it compresses pretty well (it compresses better for larger documents, obviously). The larger problem with XML is that the tooling is often lacking outside of Java and C#/.NET and none of the tooling is well-built for the sort of streaming manipulation that `jq` does (it exists, but IMO one of the least usable ideas from the XML camp is XSLT), and JSON support is pretty universal everywhere, even if the advanced things like JSONpath and JSON Schema aren’t. I also think that there’s a problem when you have to choose between SAX and DOM parsing early in your process. Most JSON usage is the equivalent of using a DOM parser because the objects are expected to be relatively small, but many XML systems are built for much larger documents, and therefore need to parse the stream because the memory use otherwise would be unacceptable. The use of a JSON streaming parser is much rarer, IME.
  • treis 4y ago
    Where XML shines is when you pass more complex data types than numbers and strings. If you repeated your example for an array of dates, as an example, strictly speaking you can't even generate the JSON. We'd first have to agree on what string representation of a date we want to use. For XML it's built into the spec.
    • dragonwriter 4y ago
      Okay, so the point at which you need to adopt a schema language in toy examples is earlier with JSON, but in most practical cases you’ll want to do that in either JSON or XML (because, even if you are only using built-in types, you’ll still want to communicate the shape), so this objection is kind of meaningless.
      • treis 4y ago
        Well, no. Because JSON & by extension OpenAPI lack a Date type you can't easily add validations about dates to those schemas. Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. The best you can do is a regex on the strings you call dates but that falls apart pretty quick.
        • Sohcahtoa82 4y ago
          > Like you can't say this particular date must be in the past in an OpenAPI spec because it has no concept of a date. I don't get these types of arguments. There's zero reason you can't write code that parses a date in an expected format (and throws an error if the date is formatted incorrectly) and then checks that the date is in the past. Yes, it does mean you'll spend time writing more code (You know, the job you're being paid to do?), and it would be nice if your data format supported such automatic checking functionality out of the box, but to say "It can't be done!" is just plain silly.
          • treis 4y ago