Recently I've read a number of comments (some old and some new) that take issue with the use of XML for one purpose or another (in the above examples, Ant and Jelly scripts, respectively). In fact, it seems all the cool kids are XML detractors these days, although the coolness may have peaked a few months ago, when even Tim Bray was admitting that XML may not be as nifty as first thought.

Now, I'll certainly admit that XML has its drawbacks. Is it overly verbose? Often. An equivalent s-expression syntax would be more concise and (for Lisp developers at least) more useful. Is it hard to read? At times. It's certainly better suited for documents where the ratio of text to tags is high. Is XML often used for developer convenience at the expense of user convenience? Is there information that has no business being in an XML format, but that developers or vendors insist on making XML anyway? Yes, yes, of course.

(On a related note, if "executable XML" is such a bad idea, how does one explain the longevity of Lisp?)

Despite these limitations, there is some value in selecting XML over, say (as Andy Hunt suggested for Ant) some arbitrary context-free grammar.

Part of this value is the ease with which a developer can drop in an XML parser, but that's only an indirect source of value. Part of this value is the comfort that users familiar with popular SGML applications (read "HTML") have with the angle bracket notation, but that may only explain the quick adoption.

The real value of XML is in the tool chain.

Suppose Ant had been based upon some custom, non-XML grammar. What would we lose?

Well for one, nearly every programmer's editor has a syntax coloring, well-formedness-checking mode for XML (certainly emacs and vi, or at least vim, and nearly anything that calls itself an IDE). Moreover, many editors support DTD or Schema validation as well, perhaps even tag and attribute completion. Using an XML format means a host of editors can handle Ant scripts smartly. The same would probably not have been true, at least initially, with some arbitrary grammar.

How does this come about? Well in part because XML is a popular format, but also because of the ease with which a developer can drop in an XML parser and other libraries.

For another advantage, consider the plethora of XML-based or XML-extending specifications. Many commentators have looked at that dense diagram and scoffed: not everything is well suited for an XML representation. Yet few would deny that at least some of those technologies do something truly useful.

Similarly, consider the number of tools, libraries and technologies that implement those specifications or provide other XML utilities. Want a pretty printer? There's a tool for that (indeed you're probably using one right now). Want an API for processing arbitrary XML? There's several, in nearly any language you can name. Want portable validation? Want to combine dialects? Want to translate one schema to another? Want simple macro support? Want to embed or link sub-documents? Want to generate hyperlinked documentation for a script or it's syntax? There's a tool for that too.

Sometimes it's sufficient to be adequate and popular, when that means a strong tool chain comes along for the ride. Sometimes worse really is better, or at least good enough.

Matt Quail writes "We have just released (beta) an Eclipse plugin and a NetBeans plugin for Clover, allowing you to instrument your code and view coverage results all from with the those Java IDEs."

Haven't tried it yet, but the screenshots look like exactly what I was hoping for. Sweet.