Mark Pilgrim: “Thought Experiment“. It’s not a thought experiment, actually. It’s Jacques Distler‘s reality.
Here’s a short story for you all. My company makes a large suite of J2EE software, mostly for banks and insurance companies. Our software uses XML all over the freaking place. We use XML for our configuration files, XML to communicate from our machines to our customer’s machines, and so on. Machines happily consuming XML from other machines. It works just fine, thanks.
One example of where we are using XML is in our workflow engine. A workflow contains tasks, chained together in a kind of graph. If you change the shape of the graph or the nature of the tasks, you change the work that the end users (the customer service representatives) have to do. Tasks and workflows can be in various states, they can connect to each other in certain ways, they can branch due to logical conditions, they can contain timing information, they can be routed to specific users or groups… and on and on it goes. As you might expect, the XML that represents a workflow is rather baroque.
Fortunately, we provide a nice GUI interface that allows you to quickly create tasks and assemble them into a workflow. Like the workflow engine, the GUI interface can read our proprietary workflow XML format. But instead of running the workflow, the GUI merely displays it in graphical form. Anything you can do by editing XML files, you can do by using the GUI interface. Huzzah!
Unfortunately, one of my newly-adopted manuals both A) lists every element and attribute of our workflow XML format and B) describes how to use the XML in detail, with many code examples. By placing this information in our public documentation, we have accidentally encouraged our customer engineers to muck with the workflow XML format by hand. This has caused exactly the sort of problems you would expect. And this is why I spent a good chunk of last week stripping out all of this information from our public documentation. The information will partly move into the schema, partly be reserved for internal documentation. If our customers need this information, they can get it. But we won’t be broadcasting the message, “Look! It’s XML! Open it in vi and have at it!” quite so loudly.
The more I have to deal with XML, the more convinced I grow that XML is for machine-to-machine communication only.
> The more I have to deal with XML, the more convinced I grow that XML is for machine-to-machine communication only.
It could be alright, if people weren’t so hung up on the fact that everything must be well formed. I’ve followed a little bit of the great XML debate and the principle of well-formed-or-die seems to be religious rather than practical. By all means, in applications that need it, insit on well formedness. Insit on validity too while you’re there. For machine-machine communications these things are probably both necessary and the main difficulty is stopping humans from futzing up the system. For human-human communication (XHTML, Atom, all the stuff people care about), neither of these qualities are necessary. In these situations a well-defined error handling protocol could be expected, and would deal with some of the nightmarish compatibility problems that have arisen with HTML.
You hit the nail on the head, James. There is a big disconnect here between how machines read and write data and how people read and write data. XML was clearly designed to serve the former… to the detriment of the latter.
Naturally, I’ve read Mark’s recently-posted summary of the history involved:
http://diveintomark.org/archives/2004/01/16/draconianism
I’ve delved into the messages on that list. From today’s vantage point, the debate is absolutely *fascinating*.