3 ms·

First iteration of Google's APIs were atom. I do miss XML.

abustamam 5mo ago
One of the API providers I use at work returns responses in XML and we use an XML parser to parse it to JSON and even then it's not perfect. What do you like about XML? I feel like I'm missing something.
- refulgentis 5mo ago
  I don't reach for it often but I've been around the block a bit, CC processors in the iPad point of sale I built circa 2010 used it and it seemed a bit off/unnecessary. In retrospect, its useful for creating islands of sanity/enforcement in a codebase. Lightweight way to give type annotations across organizational boundaries. > we use an XML parser to parse it to JSON and even then it's not perfect I can't quite picture this: how does one parse XML to JSON? I assume there's code that's parsing XML and returning a JSON object? What would make this not perfect, other than a poor implementation of the translator? Would them using JSON help? If JSON is a less expressive format than JSON, is it possible to 100% translate their XML to JSON?
  - abustamam 5mo ago
    > useful for creating islands of sanity/enforcement in a codebase Thanks for the insight! Is this what JSDoc/Swagger is now used for? > I can't quite picture this: how does one parse XML to JSON? I'm not sure actually. I haven't personally seen the code, I just hear my coworkers always lambasting that API provider for their usage of XML. Maybe it's just their lack of documentation that sucks, but it's become a running joke whenever we get a new partner that the team integrating it jokes that their API is XML.
    - jeroenhd 5mo ago
      > I just hear my coworkers always lambasting that API provider for their usage of XML I hear this too, but often when I ask why people say things like that, it's either because XML is "outdated" or because they don't like it. It's like programs written in C or C++: very few large projects chose those languages nowadays, often for good reasons, so the projects written in those languages are usually 10 to 20 years old. Age comes with a lot of legacy cruft and obscure behaviour, but that's not the fault of those languages per se. Or for people blasting banks for using COBOL, even though COBOL is a perfectly fine high-performance language for the niches bank mainframes serve.
- deaddodo 5mo ago
  The main benefit of XML over JSON is that it is structured, and can be associated with Schema's for built in validation. Obviously, that's only a benefit if you care about and utilize those features; most teams doing JSON integrations will just build those into the consumer in lieu of them being provided by the transport. But it is something that some people (especially larger enterprise organizations) value.
  - dolmen 5mo ago
    JSON is structured (not plain text to be analyzed by an IA). JSON has JSON Schema. In addition, JSON is easier to parse and to map to common data structures of programming languages.
    - jeroenhd 5mo ago
      JSON Schema is an unofficial spec with a bunch of competitors and multiple versions, not all of which are compatible. I don't think you can compare it to XML schema validation. I'm also not so sure about JSON being easier to map to common data structures. The lack of order guarantees within objects makes things like ordered maps quite annoying (you need to either use an array of entries with key and value, or an index within the mapped objects).
    - deaddodo 5mo ago
      "Structured" in this case refers to being able to be directly mapped to a data structure. Think protobuf and other similar transport mechanisms. The recipient knows what structure to expect because it's not a valid XML document if it's breaking those constraints. JSON is not, it is closer to the PHP, JS, etc "object" type, which is an ephemeral object with arbitrary member associations. And, to be clear, this is not a value judgement. They just excel in different fields. XML tends to be easier for strongly and strictly typed languages such as C/C++, C#, Java, etc where you can use the schema to generate your structs automatically. Vanilla JSON is easier for higher level languages that don't require you to manually create a mapping/validation level. JSON Schema tries to bridge that gap to a degree, but isn't built into the standard and isn't even universal. But, ultimately, both are perfectly sufficient for either use case. It just depends on how much massaging you want to do to make them work.
- theshrike79 5mo ago
  XLM had DTDs and Schemas 20 years ago. JSON is still figuring it out.
  - abustamam 5mo ago
    Json has json schema. What are DTDs?
    - theshrike79 5mo ago
      JSON Schema has existed for maybe 6 years in theory, in practice a few years. As for DTD: https://en.wikipedia.org/wiki/Document_type_definition https://en.wikipedia.org/wiki/Document_type_definition Basically it tells the system what elements are allowed in which places and what attributes they can contain. <!ELEMENT html (head, body)> Defines a html element that can contain a head and body, nothing else. Anything extra or missing will fail the validator. It was kinda-sorta eventually superseded by XML Schema that could also define what KIND of data the attributes could contain, but did exist at the top of XML/HTML/SGML documents for years.
      - abustamam 5mo ago
        Ah interesting. Whenever I write an API I'll use Zod and whatever middlewares my framework needs to generate json schema for consumers, and whenever I consume an API I will use Zod to parse. It would be nice if it were just built into the spec though!
  - thiht 5mo ago
    If XML+DTD was so great, it would still be used.
    - abustamam 5mo ago
      I don't think that's a fair assessment. Plenty of great technologies died out for many reasons unrelated to its effectiveness.

One of the API providers I use at work returns responses in XML and we use an XML parser to parse it to JSON and even then it's not perfect. What do you like about XML? I feel like I'm missing something.

refulgentis 5mo ago
I don't reach for it often but I've been around the block a bit, CC processors in the iPad point of sale I built circa 2010 used it and it seemed a bit off/unnecessary. In retrospect, its useful for creating islands of sanity/enforcement in a codebase. Lightweight way to give type annotations across organizational boundaries. > we use an XML parser to parse it to JSON and even then it's not perfect I can't quite picture this: how does one parse XML to JSON? I assume there's code that's parsing XML and returning a JSON object? What would make this not perfect, other than a poor implementation of the translator? Would them using JSON help? If JSON is a less expressive format than JSON, is it possible to 100% translate their XML to JSON?
- abustamam 5mo ago
  > useful for creating islands of sanity/enforcement in a codebase Thanks for the insight! Is this what JSDoc/Swagger is now used for? > I can't quite picture this: how does one parse XML to JSON? I'm not sure actually. I haven't personally seen the code, I just hear my coworkers always lambasting that API provider for their usage of XML. Maybe it's just their lack of documentation that sucks, but it's become a running joke whenever we get a new partner that the team integrating it jokes that their API is XML.
  - jeroenhd 5mo ago
    > I just hear my coworkers always lambasting that API provider for their usage of XML I hear this too, but often when I ask why people say things like that, it's either because XML is "outdated" or because they don't like it. It's like programs written in C or C++: very few large projects chose those languages nowadays, often for good reasons, so the projects written in those languages are usually 10 to 20 years old. Age comes with a lot of legacy cruft and obscure behaviour, but that's not the fault of those languages per se. Or for people blasting banks for using COBOL, even though COBOL is a perfectly fine high-performance language for the niches bank mainframes serve.
deaddodo 5mo ago
The main benefit of XML over JSON is that it is structured, and can be associated with Schema's for built in validation. Obviously, that's only a benefit if you care about and utilize those features; most teams doing JSON integrations will just build those into the consumer in lieu of them being provided by the transport. But it is something that some people (especially larger enterprise organizations) value.
- dolmen 5mo ago
  JSON is structured (not plain text to be analyzed by an IA). JSON has JSON Schema. In addition, JSON is easier to parse and to map to common data structures of programming languages.
  - jeroenhd 5mo ago
    JSON Schema is an unofficial spec with a bunch of competitors and multiple versions, not all of which are compatible. I don't think you can compare it to XML schema validation. I'm also not so sure about JSON being easier to map to common data structures. The lack of order guarantees within objects makes things like ordered maps quite annoying (you need to either use an array of entries with key and value, or an index within the mapped objects).
  - deaddodo 5mo ago
    "Structured" in this case refers to being able to be directly mapped to a data structure. Think protobuf and other similar transport mechanisms. The recipient knows what structure to expect because it's not a valid XML document if it's breaking those constraints. JSON is not, it is closer to the PHP, JS, etc "object" type, which is an ephemeral object with arbitrary member associations. And, to be clear, this is not a value judgement. They just excel in different fields. XML tends to be easier for strongly and strictly typed languages such as C/C++, C#, Java, etc where you can use the schema to generate your structs automatically. Vanilla JSON is easier for higher level languages that don't require you to manually create a mapping/validation level. JSON Schema tries to bridge that gap to a degree, but isn't built into the standard and isn't even universal. But, ultimately, both are perfectly sufficient for either use case. It just depends on how much massaging you want to do to make them work.
theshrike79 5mo ago
XLM had DTDs and Schemas 20 years ago. JSON is still figuring it out.
- abustamam 5mo ago
  Json has json schema. What are DTDs?
  - theshrike79 5mo ago
    JSON Schema has existed for maybe 6 years in theory, in practice a few years. As for DTD: https://en.wikipedia.org/wiki/Document_type_definition https://en.wikipedia.org/wiki/Document_type_definition Basically it tells the system what elements are allowed in which places and what attributes they can contain. <!ELEMENT html (head, body)> Defines a html element that can contain a head and body, nothing else. Anything extra or missing will fail the validator. It was kinda-sorta eventually superseded by XML Schema that could also define what KIND of data the attributes could contain, but did exist at the top of XML/HTML/SGML documents for years.
    - abustamam 5mo ago
      Ah interesting. Whenever I write an API I'll use Zod and whatever middlewares my framework needs to generate json schema for consumers, and whenever I consume an API I will use Zod to parse. It would be nice if it were just built into the spec though!
- thiht 5mo ago
  If XML+DTD was so great, it would still be used.
  - abustamam 5mo ago
    I don't think that's a fair assessment. Plenty of great technologies died out for many reasons unrelated to its effectiveness.