Well, actually:

On top of that XMPP requires you to parse these partial “XML” documents. But a partial XML document is not well-formed, heck, it’s not even a XML document! And a parser should bail out with an error. But XMPP doesn’t care, it just relies on implementation dependend behaviour of chunked parsing modes for SAX parsing. This functionality isn’t even specified by the XML recommendation in any way. The recommendation even says that it’s undefined what happens if you process not-well-formed XML documents.

ａｌｓｏ， keep in mind that if you use a non-XMPP specific XML reader, and certain kinds of data the XMPP spec terms as “restricted” are sent to you, you’ll incorrectly not ignore those parts. So of course, use an XML parser and then post-process it, but can you really still say it’s a subset of XML if you need to transform data at the representation level before it hits any application code? You might say that no XMPP-compliant remote would send you XMPP XML (we’re using an XML reader, right?) with those bits in it, but that’d only be the case if they were using an XML writer wired specifically to not do anything XMPP tells you not to, at which case it ceases to be an XML writer.

What’s with the writer? I’m basically just iterating what the link says here, but: you can’t arbitrarily assign namespaces prefixes that resolve to the correct namespaces — they needed to be assigned to specific prefixes until XEP-0044. You can’t write out unescaped > even though it’s valid XML. You must use UTF-8. So sure, maybe use an XML parser to read in XMPP-except-with-extra-bits, but good luck using a stock XML writer. Is it really still XML?

god, I never thought I’d spend so much time defending XML before. Then XMPP came along. ¯\_(ツ)_/¯

edit to add: I think the concepts behind XMPP are good and needed — a federated, extensible messaging middleware. But the XMPP implementation itself, based on XML? Yikes.