Hacker News Reader

Comment by wusspuss | Hacker News Reader

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

View on HN

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

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.

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.

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

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

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

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.

Reply on news.ycombinator.com