[wusspuss]

>It would be just as easy to write a post like this about JSON,

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.

[progval]

> JSON has no namespaces

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...

[InfiniteRand]

Namespaces address a real concern that inevitably comes up in protocols dealing with complex data and combining syntax from different standards or sources. That being said it is very easy to make half-assed solutions to the problem of namespaces, and the full-assed solution for namespaces is always a little complex and brittle, so it isn't surprising to me that most people end up going the half-assed route.

[jancsika]

Wait a sec.

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.

[wusspuss]

It's not the lack of namespaces that causes people to reinvent them. Using or not using namespaces is a choice you take. With XMPP it's 100% dictated by the XML mindset. There is NO reason for

  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>

to specify urn:ietf:params:xml:ns:xmpp-tls other than formalism/a yearn for bloat. There would never be a name collision without this ns and it convenes no useful info.

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

[EuAndreh]

> There's no reason why <query xmlns='urn:xmpp:mam:2' .../> can't be <mam_query .../>.

In this example, "mam_" is effectivelly a NIH namespace.

[inputmice]

> Causing all extensible JSON-based protocols to eventually reinvent them:

That's funny because it's true. To add to your list: JMAP (https://jmap.io/) has namespaces too.

[Andrew_nenakhov]

Switching to JSON over XML would solve approximately zero problems that decentralised communication protocol faces. In fact, it would only make things more complicated and less flexible.