The culprit is XML, or eXtensible Markup Language. Before the kid working in the closet down the hall rushes in to spoil your lunch with a dry and rambling monologue on the subject, the short story about XML goes something like this: Not only does it contain text, it also contains the information about how that text exists--fonts, sizes, formats, positions, everything that defines the total structure of the document, not just the text itself.
The immediate impact, of course, is that your storage needs will go up. Along with the data you want to save, you now must also preserve all of the information about how it's presented and how it appears. How does your budget feel about the possibility of needing 10 times your current storage capacity? But wait, there's more. Where ASCII code is basically paint in a bucket waiting to be slapped on, XML is more like a Matisse, a painting of words and images that rejects traditional renderings of text and seeks a new picture space defined by the document's structure. In other words, it needs a significant amount of processing power to get from hard disk to screen. Normally, with plain text, that would be done within the confines of the CPU and memory of your server or workstation. Unfortunately, the software used to encode and decode XML has become burdensome.
Think about the transition from a text-based environment to a graphical user interface (GUI). Very simple graphics cards were needed in the beginning. As the graphics content (i.e., "structure") became more complex, these simple cards evolved into more and more complex graphical processing units (GPUs) that do most, if not all, of the graphical computations locally rather than sending them down the bus to the CPU. The time savings and reduction in system load is dramatic.
XML, currently carted about your network by software interpreters and accelerators, presents much the same situation as a GUI being force-fed to those original graphics cards. The new solution, as it was with the graphics cards, is to switch the interpretation and acceleration over to hardware--and, as with those original graphics cards, it's not the hardware you currently own. Witness the advent of XML servers. The job of these appliances is to intercept XML structure, handle it, and then send it on its merry way in finished form so it has a very low impact on your current hardware. (This is a slight over-simplification but the general process is accurate.)
Guess what? While the desktop crowd paid US$100 for vanilla graphics cards, more powerful ones with GPUs tended to cost four to five times as much. The same holds true for XML servers--a reasonably priced one can cost upwards of US$55,000. Depending on the size of your server farm, that can take a moderate to huge bite out of your budget--and for what, pretty text? You're not going to be able to avoid it. Eventually you will add an XML server or, at the very least, some form of XML interpreting card to your workstations. But don't let anyone fool you into thinking this is just part of the cost associated with the progress of technology. XML is just another instance of, "Gee, look what we've done just because we can."
What a load of absolute rubbish! This guy has no idea what he's talking about... For a start the primary use of XML will be for the purpose of information exchange. This means that the bloat is only present in the transfer process, where at the other end it will be stored in a traditional database for example. Even if documents are stored on disk in XML format, there is little difference between having the formatting information stored using XML to having a Word document, where the formatting information must also be stored, only in a proprietry format. The ONLY place XML makes a significant difference is in the bandwidth required to exchange the information, but even there the benefits far outweigh the problems.