...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them.
> XML is not a good serialization format
I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON.
> and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS).
I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though.
I've never understood why XML gets so much hate outside of the context of the browser. Yes, it's verbose but fully featured parsers are everywhere and it seems far easier to include a random (base-64'd) binary blob in place if required as opposed to JSON. This is an area I know little about -- I'd love someone more knowledgeable to educate me.
I think it's partly down to being exceptionally verbose for simple tasks. Dealing with extra empty text nodes, namespacing, etc. JSON for most simple use cases is just "dump kv, load kv".
I'm not sure I understand the issue with base64 in JSON? Have I misunderstood the point there?
Additionally, XML, with its nesting and attributes, doesn't map particularly well to a specific programming construct. Also, you can represent an object in a lot of ways.
JSON, on the other hand, is dead simple: You have your list/array, dict/object and four value types. Representing JSON in your favorite language is straight-foward and how the serialized version of a hierarchy looks is immediately obvious in nearly all cases.
Depends on the language. XML maps nicely to C/C++/Java/Rust/... structures, that you can generate from a schema at compile time. Dealing with arbitrarily typed arrays and objects is painful in some languages because you need to use variants and dynamic-cast every access to the document.
That's exactly the problem I was going for - feature richness is the enemy of simplicity. The fact that you need to read a schema (and learn one of the schema languages) makes starting out with XML just much harder than JSON.
You implicitly need a schema in JSON too: it's the API documentation.
Then, every implementer in a statically typed language needs to translate the JSON format into structures in their own language. And this is impossible to automate, unless the JSON API uses a formally defined schema (eg. OpenAPI or GraphQL schemas), but then we're back to square 1.
If you don't care about that (eg. in dynamically typed languages), you can parse XML just like you parse JSON, using something like https://github.com/martinblech/xmltodict
Unbounded extensibility is a great way to get adoption of a standard, in the sense that a lot of products will say "Fully $standard Compatible!" in their marketing materials. It is a bad way to ensure that the standard actually means anything outside the marketing materials.
I don't see how it's a problem, except for:
> with too few guarantees in interoperability
...Which indeed makes life harder. As mentioned elsewhere in the discussion, there are compliance suites, and capabilities and feature discovery, but the clients are indeed quite diverse, and sometimes it's hard to know what to expect from them.
> XML is not a good serialization format
I personally find it more suitable than JSON for many purposes, including extensible IM, for a couple of reasons: namespaces help to avoid conflicts, while the data model itself is more convenient for general data encoding since it's straightforward to encode sum types in XML (where a tag corresponds to a constructor), unlike in JSON (where there's a few ways to achieve it, though with JSON-over-HTTP that part is usually only done on the top level and goes into HTTP query). Maybe I'd prefer s-expressions to XML for an IM, but not JSON.
> and some of the requirements in the protocol are pretty exotic and not trivial to implement in a lot of languages. Like setting up TLS on an existing connection (plus the absolute refusal of the XMPP WG to allow on-connect TLS).
I wouldn't call that one "exotic": STARTTLS is used by a few other common protocols, and allows for opportunistic TLS; easily usable with common libraries (OpenSSL, GnuTLS) too. There's XEP-0368: SRV records for XMPP over TLS [1] for direct TLS connections though.
[1] https://xmpp.org/extensions/xep-0368.html