So you couldn't just read and write a smattering of tags and attributes and expect anything to work. You needed to know what namespace each went in. There were rules about which ones required prefixes and which didn't. You needed very intimate knowledge of the data before you could ever read it, knowledge that may not have been easy to come by, given the documentation efforts were even worse back then than they are now.
And then JSON came around and said "screw all that, just overload the scripting engine itself to do parsing directly". Early JSON wasn't a standard, it was just a technique of taking a response body and calling `eval()` on it. It was wildly dangerous and--as most wildly dangerous things--incredibly freeing and intoxicating.
These days, the XML story has gotten better. Some newer versions of processing libraries are not as strict about namespacing--they will let you spit out whatever tag soup you want without being so officious. But the damage was done and now XML has a reputation.
Streaming parsers give you a stream of events like "open tag 'message'", "attribute 'from'", "open tag 'body'", "close tag 'body'" and you need to gather those and translate them back into the top-level elements of the stream. This is pretty tedious, and if you do it wrong you may end up leaking memory (if you keep the entire tree around in memory) or even introduce vulnerabilities (similar to https://bugs.chromium.org/p/project-zero/issues/detail?id=22... ).
Let's see what...
> some‡ kind‡ of observables/xpath mishmash‡ for XML streaming
which in the end still leads to:
> would‡ mostly‡ eliminate the problem
Solid programmer-think, right there!
You "just" need to magic up some stuff that in the end <<might>> solve the problem.
E A S Y - PEASY!
‡ LOL at the weasel word count.
However, it was popular during a time when C++ (not C++11) was the language to go to, CI was a very manual process for most companies, CD was something only very small companies could do, and protocols were vague. Had we had JSON during the same time period, JSON would now be considered a terrible standard we should just abandon.
Why? Marshalling is a common requirement that's not a monopoly of a single language, and there is no technical limitation on C++ that stops it from parsing any particular data interchange language.
> The moral equivalent in statically compiled language was dumping struct memory raw out to files.
If you've chosen to go the miopic path and focus on JSON's eval trick, you'd be missing the whole point of JSON.
If you're focusing on marshalling languages, you're somehow pretending that things like Apache Avro, Protocol Buffers, Apache Thrift, etc don't exist.
> And many programs did that, it just wasn't platform independent.
I don't think this is true at all. See examples above.
The human margin of error is greater in XML implementations and usage compared to say, JSON. Here's a famous 0-day in Apple devices due to inconsistencies between XML parsers: https://blog.siguza.net/psychicpaper/
I don't mind XML - for instance I really like SVG, but I've never had a good experience with SOAP.