Chris, thanks for sharing your thoughts. I, too, once depended on XML (XSD, XPath/XQuery) for my daily bread when I was an architect for a BPM company and worked with BPEL. I also spent years with it as a SOA designer and developer. I agree that SOAP was designed by the Devil to torment SOA developers. Now days, REST developers tend to have a bias for JSON, but the REST architectural style is neutral on the matter (I don’t know about Spring, but the JAX-RS Jersey libraries are quite comfortable handling XML data).

I am a fan of strong data typing and primarily work with Java (drifting towards Kotlin).

I learned the pitfalls of distributed schema management when first designing to use Kafka and Protobuf. That made me reconsider what I needed from a message format and helped push me to JSON.

One) Schemas in a distributed environment incur the burden of a distributed schema management system. This can be a difficult timing problem when rolling out changes in multi-cloud environments. Self-describing messages remove that issue. (JSON and schema-less XML are both self-describing, but in practical use, JSON is more concise and presents a more precise set of data types.)

Because we use Java, within program code we work with Java objects, not JSON. When we do not have a specific Java class to use, JSON parsers can serialize/deserialize the data from/to a Java Map<String, Object>. Currently, we use the Jackson JSON libraries (augmented with custom date and time handling) to serialize objects into JSON messages and deserialize JSON messages into objects. This validates the content and format of JSON messages. If you need to work directly with the native-format messages in your programs, XML has definite advantages,

Two) GZIP compresses/decompresses JSON messages very effectively and also works well with Web browsers. JSON is also easier to use when writing JavaScript code for a browser.

Three) In our architecture, all messages travelling over LANs and WANs must be encrypted and digitally signed. We base that processing on TLS and JSON.

There is a complete ecosystem and toolset available with XML (XSD, XPath/XQuery, XSLT) that is mature, powerful, and well understood. I am simply asserting that for the use cases for which I design, JSON is a more appropriate technology.