It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine. Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
> It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine.
Absolutely with you up to here, but...
> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.
Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".
I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.
Oh sorry, I don't at all intend to say you should write your own parser! Totally agree: "Don't roll your own XML implementation"
What I was addressing is, interfacing with an XML parser and converting that into whatever your internal representation is, can be a chore. LLMs are great at that stuff.
I'm going to stand by my position there, if you're writing an application that's primary technical purpose is to communicate via an XML based protocol and feel the need to outsource the XML part to the bullshit machine, IMO you probably shouldn't be writing that application.
IM messages aren’t really documents. They are text with some very minimal formatting that could be expressed with markdown. Any media attached isn’t embedded in the document, it’s attached externally / rendered at the bottom.
The only example I can think that messages are expressed as documents is Microsoft Teams. And it’s as much an example of what not to do as anything.
I'd disagree with that for most messaging apps. If you think about Discord or Slack for example. You have a plain text message and then media attachments externally. This could be very well expressed with JSON.
Very few messaging apps let you go beyond plain text and let you start embedding media or complex layouts inside a message.
Slack messages have a ton of formatting. You could implement it with some sort of extension on markdown but you'd have to write a custom parser. XML gives you a markup structure for free.
Slack canvases have full layouts including images.
Eh, XML is a machine-readable generic markup language. Why would you prefer using a less powerful format like markdown in a context like message representation? XML with inline tags seems the perfect fit.
Less powerful also means less complex and less exploitable. You can very easily grab a markdown renderer rather than trying to decode a .docx for messages.
Pretty much no messaging apps let you create messages more complex than markdown anyway.
