The intended purpose is relevant because it tells us the conditions under which something is likely to work well.
XML was vastly overused for a long time. That doesn't make those usages correct, as there were alternatives even then. (It also doesn't make people who overused somehow bad; I think it was a reasonable and necessary mistake.) It certainly doesn't make new ones correct now given that JSON's been around 16+ years. [1]
I think the author here is slightly strong in his criticism; I think XML is great for things that are meant to be long-lived and self-documenting. That is, things that are used like documents. But if I'm passing short-lived globs of structured data back and forth, as with an API, I think JSON's a much better fit, as is Protobufs for more tightly joined code.
> The intended purpose is relevant because it tells us the conditions under which something is likely to work well.
Not really. Plenty of things suck at their original intended purpose and remain in use because they are very good for some other purpose. (Viagra is an example well-known to popular culture, but hardly unique.)
> XML was vastly overused for a long time. That doesn't make those usages correct, as there were alternatives even then.
XML is perhaps not abstractly ideal for many of the purpose it has been used for, but in many cases it was superior to other alternatives for practical reasons, particularly the tooling ecosystem. (JSON is the new XML, and virtually the same thing can be said for JSON in many of its current uses, though it does clean up XMLs two biggest warts, element/attribute distinction and verbosity—though even for human readable formats YAML does the latter even more than JSON while being easier to read, not to mention all the binary options when readability isn't a concern.)
Yes, really. I agree there are exceptions, which is why I said "likely". But by and large, fitness for purpose correlates with design intent (which generally involves a significant period of iterative use, further driving fitness for purpose).
Sure, but the enterprise sphere is mostly what Moore called late majority and laggards. The biggest driver of use is not effectiveness, but perceived safety. A good proof of that is your choice of word here: crazy. It's not that JSON would have been somehow technically wrong; it was just socially wrong.
XML was vastly overused for a long time. That doesn't make those usages correct, as there were alternatives even then. (It also doesn't make people who overused somehow bad; I think it was a reasonable and necessary mistake.) It certainly doesn't make new ones correct now given that JSON's been around 16+ years. [1]
I think the author here is slightly strong in his criticism; I think XML is great for things that are meant to be long-lived and self-documenting. That is, things that are used like documents. But if I'm passing short-lived globs of structured data back and forth, as with an API, I think JSON's a much better fit, as is Protobufs for more tightly joined code.
[1] https://web.archive.org/web/20030228034147/http://www.crockf...