7 ms·

On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not

On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes, just enough structure to be able to quickly pull out a couple of fields and we're set. Beautiful. But let me tell you how much I appreciated XML and schema validation when we were working with fifteen different partners all using a standardized XML format with a schema. These are cats who were putting XSDs into their IDEs, clicking generate to get a class, and then just not caring. So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy. Before you say "yes but technically you could have done the same with $OTHER_THING" -- sure it's possible, but XML is ubiquitous. Shit, our tools were in Ruby. XML can be a bear, but sometimes you need a bear.

richm31415 6y ago
"Sometimes you eat the bear, and sometimes the bear eats you."
- derision 6y ago
  You only need to serialize faster than the guy next to you, or something
lemmsjid 6y ago
Much agreement here, and from the exact same usecase. Probably the easiest B2B API integration scenario I worked with in the past was XML + XML Schema validation. And I still think XML is more readable in many cases than JSON, because while verbose the hierarchical structure is very easy to grasp, sometimes I misread an entire JSON document at first because I missed a quick "[" or "[{" (yes I have also misread XML documents because of the sheer weight of text you are presented with, so I'll call that one a wash). I do agree with the XML criticisms around writability and complexity, though I think if you made a Venn diagram of the actual complexities inherent in managing a multi-client document-exchange system and the complexities of XML+Schema, you'd find that they're similar--and that many people who start building such an exchange with JSON documents end up stumbling into the same amount of complexity except in an ad hoc fashion. It's funny, I wonder if other people have the same surreal experience: as the mass zeitgeist moved away from XML I was more or less like, okay, gotta go with it, as the driftwood goes with the currents. It's interesting how the zeitgeist functions. You can tell it's happening when people look at your functional system and are like, "Uhh, why aren't you using X...?" as though it's self-evident that you should drop everything and rewrite. Where X was, over the years (dating myself) {"Java", "PHP", "Node", "Rails", "Jquery", "REST", "Angular", "React", "Thrift", "NoSQL", "Protobuf", "Hadoop"}. Some of which I quite happily used, BTW, so the interesting part is the penetrative nature of the conversation, e.g. how the quite-functional-but-not-hot technology becomes the sick gazelle falling behind the herd, even as it is not empirically sick.
- setr 6y ago
  The problem I think is the extreme cargo-culting that exists with any popular technology -- half the arguments against the current flavor of the month really just begin with "no, this is not sent from god, and there do exist tradeoffs". Which is a fairly unreasonable starting point for a conversation between educated parties. And then the ratchet turns, and the pendelum swings in reverse, and suddenly that thing sent from god was instead discovered to be sent from satan... and you're still trying to explain that tradeoffs exist
chris_st 6y ago
XML can be a bear, but sometimes you need a bear. Phrase heard at conferences in the 90's/2000's: "XML is like violence. If it doesn't work, you're not using enough of it."
- adamc 6y ago
  Made me laugh. :-)
- jkingsbery 6y ago
  > "XML is like violence. If it doesn't work, you're not using enough of it." That same saying would also work replacing XML for soap (but not SOAP).
lostcolony 6y ago
Yes. Can't agree more. This coming from someone who hates XML, avoids it at nearly all costs - there are times it's the right tool for the job. And you list that time. If you have a 1-1 API contract, don't use XML. If you have 1-N, don't use XML. But if you have N-N API contracts? Where you're talking to half a dozen other services, and they're all talking to you? XML is an excellent choice.
fatnoah 6y ago
One of my very, very, very first jobs (1999) was at a startup that was leaning very heavily into XML for dealing with structured data. A massive amount of time was spent dealing with issues related to hand-editing XML, so I went deep into building schemas, utilities to validate XML according to the schema, and finally building an editor that was capable of providing some XSD-enabled automagic. Good times.
secondcoming 6y ago
> So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy. Fine, but with for example, Protobuf, you share a .proto file and so there's zero percentage chance of this happening.
- generalk 6y ago
  No, with Protobuf, I send my counterparts a .proto file, and they 1) Don't know what the hell to do with it, not just because they don't know Protobuf but because 2) it wasn't included in the docs/dictionaries from the standards organization that set this all up in the first place.
- splix 6y ago
  XML files are little bit easier to debug
dutchmartin 6y ago
I hate xml so much. But I had a exam at my university a year ago where they would let me type a validation schema for a xml file in notepad++ and a checker on a computer with no internet. The fail rate for that exam was high and the course was outdated, api am glad they updated the curriculum now. I just hope to never work with xml data again.
rwmj 6y ago
It's a shame the original article didn't mention XPath which is a great feature when you're in the XML ecosystem. (Obviously JSON has jq, but that's not a standard - so there's no library version - and has some weirdness compared to XPath).
- Nemo157 6y ago
  JSON has the equivalent JSON Pointer described in RFC 6901 (https://tools.ietf.org/html/rfc6901 https://tools.ietf.org/html/rfc6901).
l0b0 6y ago
Basically, use the best tool for the job. If you're working with complex data structures from many sources, having data, validation and transformation languages (XML, XSD and XSLT) which have been co-developed and refined to basically be able to validate any third-party tool is invaluable. Sometimes extra safety is worth both the extra space and time.
Seb-C 6y ago
JSON schema achieves the same result and is fairly standard actually.
beardyw 6y ago
I was asked by a company to sort out complaints which were coming from recipients of their XML. The big win was doing validation against the schema on the outgoing XML!

richm31415 6y ago

"Sometimes you eat the bear, and sometimes the bear eats you."

derision 6y ago
You only need to serialize faster than the guy next to you, or something

lemmsjid 6y ago

Much agreement here, and from the exact same usecase. Probably the easiest B2B API integration scenario I worked with in the past was XML + XML Schema validation. And I still think XML is more readable in many cases than JSON, because while verbose the hierarchical structure is very easy to grasp, sometimes I misread an entire JSON document at first because I missed a quick "[" or "[{" (yes I have also misread XML documents because of the sheer weight of text you are presented with, so I'll call that one a wash). I do agree with the XML criticisms around writability and complexity, though I think if you made a Venn diagram of the actual complexities inherent in managing a multi-client document-exchange system and the complexities of XML+Schema, you'd find that they're similar--and that many people who start building such an exchange with JSON documents end up stumbling into the same amount of complexity except in an ad hoc fashion. It's funny, I wonder if other people have the same surreal experience: as the mass zeitgeist moved away from XML I was more or less like, okay, gotta go with it, as the driftwood goes with the currents. It's interesting how the zeitgeist functions. You can tell it's happening when people look at your functional system and are like, "Uhh, why aren't you using X...?" as though it's self-evident that you should drop everything and rewrite. Where X was, over the years (dating myself) {"Java", "PHP", "Node", "Rails", "Jquery", "REST", "Angular", "React", "Thrift", "NoSQL", "Protobuf", "Hadoop"}. Some of which I quite happily used, BTW, so the interesting part is the penetrative nature of the conversation, e.g. how the quite-functional-but-not-hot technology becomes the sick gazelle falling behind the herd, even as it is not empirically sick.

setr 6y ago
The problem I think is the extreme cargo-culting that exists with any popular technology -- half the arguments against the current flavor of the month really just begin with "no, this is not sent from god, and there do exist tradeoffs". Which is a fairly unreasonable starting point for a conversation between educated parties. And then the ratchet turns, and the pendelum swings in reverse, and suddenly that thing sent from god was instead discovered to be sent from satan... and you're still trying to explain that tradeoffs exist

chris_st 6y ago

XML can be a bear, but sometimes you need a bear. Phrase heard at conferences in the 90's/2000's: "XML is like violence. If it doesn't work, you're not using enough of it."

adamc 6y ago
Made me laugh. :-)
jkingsbery 6y ago
> "XML is like violence. If it doesn't work, you're not using enough of it." That same saying would also work replacing XML for soap (but not SOAP).

lostcolony 6y ago

Yes. Can't agree more. This coming from someone who hates XML, avoids it at nearly all costs - there are times it's the right tool for the job. And you list that time. If you have a 1-1 API contract, don't use XML. If you have 1-N, don't use XML. But if you have N-N API contracts? Where you're talking to half a dozen other services, and they're all talking to you? XML is an excellent choice.

fatnoah 6y ago

One of my very, very, very first jobs (1999) was at a startup that was leaning very heavily into XML for dealing with structured data. A massive amount of time was spent dealing with issues related to hand-editing XML, so I went deep into building schemas, utilities to validate XML according to the schema, and finally building an editor that was capable of providing some XSD-enabled automagic. Good times.

secondcoming 6y ago

> So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy. Fine, but with for example, Protobuf, you share a .proto file and so there's zero percentage chance of this happening.

generalk 6y ago
No, with Protobuf, I send my counterparts a .proto file, and they 1) Don't know what the hell to do with it, not just because they don't know Protobuf but because 2) it wasn't included in the docs/dictionaries from the standards organization that set this all up in the first place.
splix 6y ago
XML files are little bit easier to debug

dutchmartin 6y ago

I hate xml so much. But I had a exam at my university a year ago where they would let me type a validation schema for a xml file in notepad++ and a checker on a computer with no internet. The fail rate for that exam was high and the course was outdated, api am glad they updated the curriculum now. I just hope to never work with xml data again.

rwmj 6y ago

It's a shame the original article didn't mention XPath which is a great feature when you're in the XML ecosystem. (Obviously JSON has jq, but that's not a standard - so there's no library version - and has some weirdness compared to XPath).

Nemo157 6y ago
JSON has the equivalent JSON Pointer described in RFC 6901 (https://tools.ietf.org/html/rfc6901 https://tools.ietf.org/html/rfc6901).

l0b0 6y ago

Basically, use the best tool for the job. If you're working with complex data structures from many sources, having data, validation and transformation languages (XML, XSD and XSLT) which have been co-developed and refined to basically be able to validate any third-party tool is invaluable. Sometimes extra safety is worth both the extra space and time.

Seb-C 6y ago

JSON schema achieves the same result and is fairly standard actually.

beardyw 6y ago

I was asked by a company to sort out complaints which were coming from recipients of their XML. The big win was doing validation against the schema on the outgoing XML!