I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP ev

I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.