Causing all extensible JSON-based protocols to eventually reinvent them:
* https://www.w3.org/TR/json-ld11/#compact-iris
* "If new events are added, the event type key SHOULD follow the Java package naming convention, e.g. com.example.myapp.event." https://spec.matrix.org/v1.2/client-server-api/#types-of-roo...
* https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22... (no aliases, so it's even more verbose)
* https://github.com/OAI/OpenAPI-Specification/issues/1362#iss...
By far the most widely used half-assed solution to namespaces is in the HTML5 parser to special case svgs (and maybe other curiosities? Dunno). And if I understand correctly, that happens to be a full-assed specified algorithm that all current browsers use.
That is all in order to avoid the problems that would have come with requiring the full-assed XML namespaces in that case.
If I were a political operative, I would attempt to bog down the XML apologists on this point whenever they attempt to argue that JSON gets as complicated as XML when you try to include namespaces.
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>
There's no reason for acks to specify urn:xmpp:sm:3 each time. Yes, here it at least specifies the version, but that's already negotiated when enabling acks anyway.
There's no reason why <query xmlns='urn:xmpp:mam:2' .../> can't be <mam_query .../>.
Namespaces are a choice, sometimes (e.g. in programming languages) reasonable, sometimes (in a serialization format for passing small texts around) not so much.
It is dictated by a mindset, the XML mindset in case of XMPP, and in the case you bring up apparently by the Java mindset, not to say there's much of a difference between the two
In this example, "mam_" is effectivelly a NIH namespace.
That's funny because it's true. To add to your list: JMAP (https://jmap.io/) has namespaces too.
JSON has no namespaces, even without taking that into account it's already less verbose, it maps nicely into lists and dicts, I don't know a single JSON parser that can leak the user's IP even as an option, let alone by default (not saying there aren't any at all, just no popular ones), doing a binary version of XMPP based on JSON would take as much as switching over to bencode instead of whatever the unsupported hell EXI is. So no, you can't really write a post like this about JSON. Even if you do, it's not gonna be XML that will be proposed as a better solution.
One thing where XML beats JSON is markup. But with XMPP's unholy approach to markup, it's actually JSON that beats XML.