If it were a more compact format, it is likely both the uncompressed AND compressed sizes would be smaller.
By your logic, if you 10x'd the length of the XML tags in XMPP then it would be even better since you you would get an even further improved compression ratio.
To be clear, I don't have a problem with XML in XMPP since it is negligible overhead, but "it compresses well because it is full of redundancy" is not the argument that should be used to justify it.
That's a strawman. I am not arguing that we make the tag names longer, I am arguing that there is little benefit to a more concise format.
If you are so bandwidth constrained that deflated XML won't do, then I doubt deflated JSON would be good enough either (and that exists anyway, Matrix).
Your argument was that XML compresses really well, which indicates that compression ratio is your evaluation metric. I just suggested a simple way to improve your metric.
My position is that compression ratio is a largely meaningless metric in this instance, so using it as a method for justifying the use of XML (as inferred from "XML compresses really well") is also meaningless. That does not translate to "XML is bad for XMPP", I actually think it is fine, it means "XML compresses really well" doesn't add anything much in the way of justification.
I've spent way too much time on this thread already, so take what you will from it, it is all you from here on out, I am done here.
"By your logic" is usually a canary for strawman, and it's needlessly combative on top of that. Best to step back and reconsider if you find yourself penning that.
The only thing I was saying was exactly what I said, within the context of XMPP, XML compresses really well - I was reinforcing the parent comment. How that relates to metrics in other contexts wasn't what I was talking about at all. I generally avoid XML nowadays, and so your argument with me isn't something I would dedicate thought to in the first place. I see no point in taking anything from this nonsense.
By your logic, if you 10x'd the length of the XML tags in XMPP then it would be even better since you you would get an even further improved compression ratio.
To be clear, I don't have a problem with XML in XMPP since it is negligible overhead, but "it compresses well because it is full of redundancy" is not the argument that should be used to justify it.