A lot of things get a bad name because they are used incorrectly. Look at SQL: it's actually great if you use it for the correct problems. The same thing applies to XML: if you're actually using it for the correct problems it's somewhat irreplaceable (XMPP is a beautiful example of how XML should be used).

Putting namespaces into JSON seems to fall into that dangerous territory - rather use the tool that's designed for that job from the ground up. JSON is great at the 99% of things that XML gets abused for, but it simply can't replace the 1% of correct use-cases for XML.

For a correct use of XML, I'd more suggest looking at static datasets with lots of complex inter-references and data types - for example, public transport data.

    {"http://joepie91.com/XMPP/rtf_content content": "..."}

Further, you have to understand that the key thing about the XML namespaces is primarily social, not technical: The use of the URI in the namespace (which is otherwise just an advisory string with no meaning) is also a licence to stick things in the value that you fully expect no-one else to understand, in a way that you know is guaranteed not to cause a conflict (in the absense of hostile intent). The guaranteed lack of conflict gives you that license. If you intend to match that with JSON keys, you must either copy the XML namespace's approach or something very similar, or run the risk of stomping on each other's keys, which socially creates pressure back towards some sort of licensing mechanism/standards body where people must agree on things before they can be used. (XML namespaces are also important because URIs of domains you own are also one of the few relatively unique keys that you can get without permission from a central (XMPP) authority. It's not the only option, but it's worth observing that "just pick something!" still has problems.)

On the one hand, people have been complaining about XMPP for years and years... on the other hand, I'd point out that given that it is also surviving, one must ask the question "why?" And I'd submit that this may be a significant part of the reason why. If you want sane and correct extension on an IM protocol, XMPP is in fact the best choice.

I understand the problem. I just don't feel that the way XML solves it is the correct one.

> (XML namespaces are also important because URIs of domains you own are also one of the few relatively unique keys that you can get without permission from a central (XMPP) authority. It's not the only option, but it's worth observing that "just pick something!" still has problems.)

Right, the point is that it's over-engineered. For usecases like this, you don't need guaranteed-unique namespaces - they just need to unique enough within your application that collisions are unlikely to ever happen.

For all practical purposes and intents, a key along the lines of `joepie91:carbons` (ie. a URN-like) would be sufficient - nickname and company name reuse is already non-zero but limited, and the cumulative chance of both having a name reused and working with the same kind of data (ie. conflict-sensitive) is negligible.

Domain URIs aren't quite decentralized (socially) either, by the way - in practice, it relies very heavily on the DNS system, which is very centralized.

> On the one hand, people have been complaining about XMPP for years and years... on the other hand, I'd point out that given that it is also surviving, one must ask the question "why?" And I'd submit that this may be a significant part of the reason why. If you want sane and correct extension on an IM protocol, XMPP is in fact the best choice.

"It's still around" in no way leads to "it's the best choice", logically. There are many, many reasons why an inferior, poorly-designed or overly complex protocol might still be in active use.

Conversely, it could be asked: why is XMPP not universally used, like HTTP is, and why is the tooling so substandard?

""It's still around" in no way leads to "it's the best choice", logically."

Yes, I know. It's why I never made the claim that it's the best. I think XMPP has some serious flaws that kept it from being much more successful.

I also think XML isn't any of them. Convert XMPP naively to JSON, and it's still too difficult for people to bring up a stream and send an IM. One change I'd make, for instance, is for initiating a stream to default in one tag to a sensible initialized state, the state people expect a new IM stream to be in, and allow the user to override the defaults to be more manual, rather than what it is now. The spec is full of things like that, though, to some extent IM is a harder problem than people think.

"XML" is just a cognitively-available excuse. It's not the core problem. Personally, if I had to write a new protocol, JSON wouldn't actually be in the running; I'd either stick to XML or go to something like Protocol Buffers. I'd say JSON is actually in a really bad place for a big IM protocol, where it's still very, very verbose and has bad parsing characteristics (text-based, must parse whole message before you can do anything with it) but also fails at things XML is good at, like rich text and extensibility (JSON is bad at mixed text). And both are pretty bad at being streamed, for what it's worth.

"For all practical purposes and intents, a key along the lines of `joepie91:carbons` (ie. a URN-like) would be sufficient - nickname and company name reuse is already non-zero but limited, and the cumulative chance of both having a name reused and working with the same kind of data (ie. conflict-sensitive) is negligible."

That's not really disagreement. You just want to run the risk of using a shorter URN than everybody else, for the convenience of... uh... not sure actually, since this is all auto-generated JSON anyhow. It's not like you're saving the user typing, and choosing JSON means you've already thrown away wire-space efficiency. (Or are using gzip or something, and gzip'ed XML-XMPP and gzip'ed JSON-XMPP will be virtually identical in size on a stable stream.) You can already use that exact URN as an XML namespace today, if you so choose.