Comment by mikepurvis
13 hours ago
HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:
<?xml version="1.0"?>
<methodCall>
<methodName>math.add</methodName>
<params>
<param>
<value><int>5</int></value>
</param>
<param>
<value><int>7</int></value>
</param>
</params>
</methodCall>
Compared to this, JSON had string and number types built in:
{
"jsonrpc": "2.0",
"method": "math.add",
"params": [5, 7],
"id": 1
}
I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.
To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param, this is why we ended adopting openapi for describing http interactions and iirc jsonrpc specifically can also be described with it. At least in the schema part no one would say it is ambiguous, also one does not need do heavier parses, the obj is a tree, no more checking on scaping strings, no more issues with handcoded multiline strings, it is dropped the need to separate attributes with commas as we know the end tag delimits a space and so on.
Yeah this is the issue. I spent tons of time writing code that would consume xml and turn it into something useful.
It’s a mediocre data storage language.