back
3 comments
I simply don't buy this argument.

Who cares if there's a wealth of experience out there regarding XML? When you're designing software, if your primary goal is making it easy on your developers, YOU'RE DOING IT WRONG.

There is one situation, and one situation only, where XML is the right tool for the job. That situation is where a computer must produce and/or consume a file that must be read and/or written by a human. That's it. The only time. So, XHTML, ja. SOAP, nein. If a computer is consuming data another computer has produced, why would you want to encode that data in something so hard to parse, and so potentially ambiguous as XML? It's lunacy.

I have to disagree. I think that XML is better used for machine-consumable processes rather than human-edited ones. The wealth of tools available mitigate the need to roll your own data format and help ensure that your output will be usable by anyone with a (ubiquitous) XML parser. If your data will be used by an arbitrary 3rd party there are a lot of advantages to using XML.

Optimizing for ease of development is certainly a good goal too. Ease of development equates directly to lowered maintenance costs and redevelopment of poor code. In my business at least the maintenance costs far outweigh the initial expenditures when evaluating different technologies.

EDIT: I agree that SOAP is abominable. But that's due to its overall architecture rather than its use of XML.

  I think that XML is better used for machine-consumable
  processes rather than human-edited ones. The wealth of tools
  available mitigate the need to roll your own data format
  and help ensure that your output will be usable by anyone
  with a (ubiquitous) XML parser.
That's a false dichotomy. The choice is not between XML and yet another home-rolled data format, but between XML and every other data format currently in existence. When compared against JSON, YAML, or s-exps XML always seems wrong for machine->machine communication.