8 Reasons why XML Sucks

Author: Jakob Jenkov and Kasper Graversen, 15/07/08 Keywords: XML Abstract: I was once a believer in XML. Until I started working with it, that is. Now my enthusiasm has faded away - replaced by - well - bitterness or something like that.

subscribe to my RSS feed

8 Reasons why XML Sucks

I was once a believer in XML. Until I started working with it, that is. Now my enthusiasm has faded away - replaced by - well - bitterness or something like that. I just don't like it anymore. This text lists a series of problems developers encounter when working with XML. I'll expand it as more disadvantages come into mind. If you have some complaints to add, send me an email. Find the address on the About page. So, when your fellow developers start praising XML you can send them a link to this page to get their feet back on the ground.

XML has only one advantage: It is sometimes humanly readable. This is its only advantage, but this is also one of the reasons why it sucks. Most other aspects of XML are just plain lame. XML may be fine for files read and written by both humans and computers like configuration files. But, for computer-computer communication XML is terrible. This text will take you through 8 reasons why we think so.

1. Character Encoding

Additionally, you may run into problems when you need to embed character data inside the XML file that is stored in a different character set than the one the XML file is encoded in. In that case you will need to manually translate from one encoding to another.

Finally, as XML is character based, element data cannot contain characters that can confuse the XML parser. For instance, the character < must be encoded as <, the > as > etc. You must remember to do this yourself or escape the whole block using <![CDATA[ ... ]]>. I've seen projects that religiously used the CDATA escaping within all XML tags to "prevent running into problems". Needless to say, this only further fattened the size of the already bloated XML documents.

2. Embedding binary data

3. Indentation Characters Mixed With Data

When I first heard of XML it was related to discussions about separating formatting and layout from content. Interestingly XML often does exactly the opposite, by having the indentation characters mixed with the contained data.

4. Textual Representation of Numeric Data

<int>1234567890</int>

Firstly, the tag-element alone take up 5 + 6 = 11 bytes in total (this is more than the actual content!). And had longer element names been used, the tags would take up even more bytes. For no reason other than being "humanly readable". The integer value itself also take up 10 bytes, even though its value could easily fit inside a regular 4 byte integer.

Then there is the problem of decimal numbers. Should it be formatted with a . or , as divider between the integer and the fraction part?

123.666   US Style
123,666   Danish Style
123.666   UK Style
123,666   German Style

5. Unnecessarily Verbose

XML is unnecessarily verbose. I remember back in 2000 on a telco project we converted TAP 3 files (billing logs) into XML. The XML files were 16 times larger! When looking at the textual representation of tags, indentation characters, and numbers, this is not surprising, but the reality was zero gain. If data is not hierarchically structured, consider using another less verbose format such a CSV. Such formats are much easier to read, takes up less space, and are easier to export from various applications

6. Human un-readability

• A badly formatted XML document is not readily readable. It must first be reformatted..
• A document with badly chosen names, such as <A>, <B>, <C>, ... is not readable. Ironically some projects embrace the strategy of the smallest possible tag names in order to reduce document sizes. Even more ironically, such a strategy has a significant positive impact on the document size.
• A BIG XML document is unmanageble, especially if the underlying data structure is unknown. On a project I was on, we used Toplink as the ORM tool. Two developers accidently used the Toplink tool to define some database mappings without locking the file in CVS. Suddenly there was a conflict in the CVS repository. With little knowledge of the Toplink internal representation, and having a 856KB XML document, we quickly gave up rectifying the conflict and one developer had to redo all his work.

7. A single XML root element

A logging example:

     <log> ... log data... </log>
     <log> ... log data... </log>

Notice how this logfile does not have a single root element. Imagine if you had to have a single root element. Then you would also have to have the root element correctly ended with a root element end tag. Whenever appending to your log file, your logger would then have to remove the old end tag, append the new log record, and re-write the end tag. A total waste!

The single root element limitation also makes it harder to first examine what kind of XML document it is, before passing it on to the appropriate parser / processor. If an XML document could have contained a header and a body element, the header element could have been inspected before passing the body on to the appropriate processor.

Finally, many parsers have problems properly dealing with documents with no single root. Recently, in ANT I tried including one XML document in another using XSLT. The parser complained a lot. Among the errors were "file not found" and "illegal format". Little indication was given as to the missing root element, and the "file not found" turned out to be total bullocks.

8. SOAP - Oh My God!

It doesn't even make sense in my opinion to use XML for this purpose. XML's only strength is that it is "humanly readable". But web services are all about computer - computer interaction, isn't it?

On a large IT project I have been working on, the web front-end exclusively retrieved data to display using web services. One problem we had was that many screens were slugish. Some took 2-3 seconds to display. We assumed it was bad data base queries who were to blame. It turned out the data base call took 30 milli seconds! The remaining 1-2 seconds were the overhead of producing the XML, retrieving the XML in the web layer, parse it and display it.

In addition, the single root element limitation is really annoying in computer to computer communication. A SOAP request has an envelope with a header and body element inside, like this:

<envelope>
 <header>
 </header>
 <body<
 </body>
</envelope>

It would be really useful if a node in a computer to computer communication network could just parse the header and then decide what component is to process it. Or perhaps to forward the request to another computer with the body untouched and unparsed. Unfortunately, because of the way traditional XML parsers work this is not possible. Once you start parsing the XML document you parse it all!

Allowing multiple roots would have solved the problem. Like this:

 <header>
 </header>
 <header>
 </header>
 ...
 <body>
 </body>

Now each header could be parsed one by one, without having to parse anymore than that. In addition, imagine having to exchange a few int's (4-8-12 bytes or so) via SOAP. It'll expand into 1-2 KB !! A complete waste off CPU time and bandwidth!

BML

Comments

Help spread the word