XML and XSLT are ungainly because they are the products of evolutionary processes. Neither is a first-generation technology, but rather a refinement of something that had gone before. (XML was spawned from SGML; XSLT’s roots are in DSSSL with some Omnimark admixture.) You might think this should streamline them: and indeed it has, if you compare them to their progenitors. Yet they also have their histories written onto and into them: they are not pretty, but somewhat lopsided and peculiar.

(There are some smart people who try to avoid XML and XSLT completely, partly on the basis of their various oddnesses. These people may or may not be able on their own to make something work as well as XML does, but that is a separate question. Another separate question is whether they can help other people to use their thing for something just a little different from what it was designed for.)

Yet this ungainliness is also part of the strength and charm of XML/XSLT, once you learn to look past the flaws on the surface. It results from the fact that both have to address a wide range of conflicting requirements, well enough. And this, they do.

The more hidden strength — the way well-described, well-managed XML data can be kept safe away from the storms of technological change in the browser (or anywhere else) — only becomes evident over time.