What is XML good for anyway?

XML has had a fairly successful run for almost 10 years now, shot into prominence by its “configuration” usage by Java platforms.
Sadly for XML that 10 year ride is showing signs of slowing down.

I have always disliked XML in most of its incarnations and I am extremely happy that people are now (finally) showing it the door from places where it should never even have found any foothold in the first place.

Let me recant some of what I said, XML does have some uses but for some very strange reasons it had greatness thrust upon it. Now that it is being relieved of its undeserved celebrity status, my prejudice is giving way to prudence.
So I thought of writing my honest thoughts about XML.

XML is great for hierarchical, repetitive-pattern data. It is both state and presentation clubbed into one document and that is what makes it unique. XML data is inherently de-normalized as against relational systems.

<employee>
  <name>Nasir Khan</name>
  <profession>programmer</profession>
  <address>
     <street> 235 Montgomery Street </street>
     <city> San Francisco</city>
     <country>USA</country>
  </address>
  <contact>
    <email>myemail@mydomain.com</email>
    <phone>
       <home>408-111-1111</home>
       <office>415-400-7000</office>
    </phone>
  </contact>
</employee>

<employee>
……

The above XML looks fairly standard but in a relational world this data would be constituted from several de-normalized relations (tables).

Well XMLs were never anyway designed for data storage so it’s a bad comparison. But unfortunately it was used like that in many situations.

I have tried to compile a list where XML is definitely NOT suited but unfortunately used pervasively, this is not a complete list but is based on my first hand experience.

• Information Interchange: And yes this includes Web services and SOAP. They could have designed much simpler protocols for data exchange, markup just adds unnecessary clutter and wastes bandwidth. XML for data/information exchange is neither human readable nor machine friendly. “Extensible protocols” is an oxymoron, only when both client and server “understand” the protocol is when it is usable, so what is extensible about it? Go figure. The above data snippet (the record) could well be coded in a simple delimited string “Nasir Khan, programmer, 235 Montgomery street, San Francisco, USA, myemail@mydomain.com, 408-111-1111, 415-400-7000”.
  This is 115 characters as against 313 characters in XML form! If a machine is reading the string then believe me it does not care about angled brackets, it does what you tell it to do. If you tell it that the second record in the string is my profession it will just take my word for it.
  What about readability? Take a step back and ask someone who is not a programmer about which of these make sense to them. Even a school dropout will be able to make sense out of the delimited string, while most will cringe at the sight of that ungainly XML. The context (schema) is coded in human brains.
  I know you could argue – “how could you tell the difference between home and office phone”, well just prefix a “h:” or “w:” before the number and off you go.
  Bottomline - they could always have designed simpler text protocols which could map to object oriented systems (like CORBA IDLs or other schemes) for automatic generation of protocol handlers on automatons and save millions in bandwidth, time and eye sores (the pointy arrows really hurt).



• Programming languages/DSLs: When I first saw constructs like
  
  

  
  <if>value</if>
    <then>
   …..
   <and>
    <or>
      ….
    </or>
    <or>
     …..
    </or>
  </and>
  

  
  I just asked “WHY?”
  I still do not understand why there are so many DSLs out there based on XML.
  
  

  
  <assign>
    <copy>
      <from variable="c1"/>
      <to variable="c2"/>
    </copy>
  </assign>
  

  
  This snippet above is an example of assignment in BPEL.This is equivalent to
  

  
  c2 = c1 
  

  
  in any of the “normal” programming languages.
  Now if one were paid by the lines of code they write then it is a potential goldmine for developers but other than that it is a recipe for carpal tunnel syndrome.
  
  Even though “L” in XML stands for language, it is not a language in any sense of the word. It is a document format. People have tried to patch on language constructs like conditions, iteration constructs, recursion, assignment etc on it but it doesn’t work most of the time.
  Well theoretically you could write a full blown programming language in XML syntax. It will be utterly unreadable and make you see your chiropractor but what I think will be its nemesis is the fact that XML originally was designed to format data. There is no inherent concept of data types. Everything is a string, you could again argue that you will create tags for data types and use them to wrap your variables like <int>variable</int>, well sure but then how do you deal with collections, how would you create a tree data structure in that language?
  You will say that I can create a <tree> declaration and represent the actual elements in internal data structures. Good for you but you will then represent your program state in non-XML format while your program logic in XML!
  Remember XML is a data format structure; it will be like tacking wheels to your boat while trying to make your car float.
  
  I think the reason why people started writing DSLs in XML was that they wanted some dynamic evaluation to be done in static languages of the age like C++, Java etc. XML was popular at that time and seemed like a natural choice.
  
  In those days it went like –
  
  “Hey I am not on talking terms with my grandmother; she doesn’t talk to me at all!”
  
  “Have you tried XML? It might work. It’s hip”.
  
  That they could have done dynamic evaluation in hundreds of other ways got trampled under the XML gold rush.
  An embedded Java compiler, like the JSP processor is the best solution in most cases where you want such dynamic behavior. I am surprised why that pattern was just locked up in (immensely successful) web containers.
  



• Build tools/Ant: I never liked Ant, that is not to say I did not use it. I did, as it was the only option to build Java projects for a long time. Anyone who has used Ant would agree that after your project has reached a critical mass the build files look clunky and un-navigable. In his article Martin Fowler describes the Rake build tool and describes the flaws that an Ant like XML based system would have, primarily because of the choice of language, namely XML. I do not want to repeat what he said in his article, so have a look at Martin Fowler's article on Rake
  



• Configuration files: This is perhaps the most pervasive use of XML. I do not have too much problem with it except that the large configuration files are unreadable. The other problem is that since XML enforces a certain order, even for unrelated nodes, you have to be aware of the DTD or schema before you make any changes to the configuration. For most situations a simple Properties file or Java Preferences like access would have solved the problem nicely, particularly because the property names can very well be mapped to Java package scoped constants or variable for readability.
  
  e.g.
  

  
  com.mycompany.employee.name=”Nasir”
  com.mycompany.employee.phone=”415-111-1111”
  com.mycompany.threadmanager.numThreads=5
  com.mycompany.concurrency.policy=”Pessimistic”
  

  
  
  Is far more readable than
  

  
  <?xml version="1.0"?>
  <config-data>
   <employee>
     <name>Nasir</name>
     <phone>phone<phone>
   </employee>
   <thread-manager>
   …
   <num-threads>5</num-threads>
  </thread-manager>
   
  <concurrency-policy>Pessimistic</concurrency-policy>
  </config-data>
  

  
  What is more is that in the XML case you need repetitive Java code to parse the XML through some expensive parser and maintain Java objects representing the configuration. On the other hand with Properties like access you have built in Java class java.util.Properties to manage the data with as simple an API as load() and save().
  
  It was for Java’s heavy reliance on fat XML configuration files that prompted the detractors to coin the term “XML sit ups”.
  


• XSLT: The concept is pretty powerful. Have a base document and transform it according to the presentation needs. In fact this could be seen as a variation of the Builder Design pattern or Abstract Factory as the transformation could be based on the type of request or type of client etc.
  So what is wrong with it? It is the “X” in XSLT. Several years ago I wrote some XSLT scripts to convert XML to Java code, if you haven’t guessed what was I trying to do - I was converting a DSL in XML to plain (and simple) Java code for performance reasons. When I finished that project I had pulled a lot of my hair out, it was ridiculously difficult to do something simple. I added a todo note to rewrite that transformer in Java itself using a SAX parser rather than use XSLT.

So what is XML good for in real world? I would say a number of things, definitely not as many as it is used for but enough.

• Hierarchical data representation and XPath: One thing that I instantly liked in the XML world was XPath expressions. It is a powerful mechanism that actually uses the XML representation in the most intuitive form. As I said in the beginning, the most important feature of a XML document is its hierarchical representation. Xpath leverages that by using a familiar “path” syntax.
  Even to some one who doesn’t know Xpath, an expression like
  

  
  //place/coordinates/latitude/text()
  

  
  will instantly make sense.
  There is a protocol called XCAP (XML Configuration Access Protocol) Jonathan Rosenberg's page on XCAP used in the SIP/SIMPLE world that very cleverly uses Xpath in conjunction with HTTP to access and modify hierarchical data.
  



• GUI description: I think more than anything this is where XML truly excels. The most ubiquitous usage of XML as GUI description tool is of course HTML. If you have worked with building GUIs then you will immediately realize that GUI development is so much more complicated than “faceless” non UI code, there is not just behavioral aspect as any other program but also presentation aspects.
  XML based UI design frameworks take the pain out of UI development. Again this is possible because XML is hierarchical and presentation oriented. Widgets can be placed on the screen depending upon their position in hierarchy.
  

  
  <button-group name=”mygroup”>
    <radio-button name=”b1”, onSelect=”func1()>Male </radio-button>
    <radio-button name=”b2”, onSelect=”func2()>Female </radio-button>
  </button-group>
  

  
  Is so much more intuitive than
  

  
      JRadioButton maleButton = new JRadioButton(“Male”);
      JRadioButton femaleButton = new JRadioButton(“Female”);
  
      //Group the radio buttons.
      ButtonGroup group = new ButtonGroup();
      group.add(maleButton);
      group.add(femaleButton);
  
      //Register a listener for the radio buttons.
      maleButton.addActionListener(this);
      femaleButton.addActionListener(this);
  

  
  This is not to in any way belittle the excellent work done by Java UI team. Java APIs are great for portable UI code and very exhaustive too. To make these APIs more accessible to visually oriented developers there are a number of XML to Java projects underway. I think they hold a great deal of promise for Java UI development.
  http://www.java-source.net/open-source/xml-user-interface-toolkits
  
  There are a number of other XML based UI design languages, notable amongst them are XUL from Mozilla, MXML from Adobe, LzXML from OpenLazlo and UIML which has an open source Java binding http://sourceforge.net/projects/juiml.
  



• Annotations/Sematic tagging: A lesser known but widely used feature of XML is tagging. How many times while replying an email message you have written your reply “inline” of the original message? The way you do it plain text is to enclose your replies in tags. Like I use may name as tags
  

  
  <nasir>Yes I will attend the meeting. </nasir>
  

  
  Now the resulting email response may not be a well-formed XML document but the notion of start and end tag is pretty powerful.
  On another occasion while compiling the specification ( JSR 289 EDR document) from a large number of smaller sub-documents I used simple markup tags. I inserted tags in the source documents and then had destination tags in the main documents where the text was pulled from the sources. Besides this there were a few more things like automatic linking and aliasing but overall it greatly simplified the document creation for me.
  

To summarize XML can be a great help in some situations but can be an excruciating pain in others, perhaps this is true for any technology but in this article I have focused on XML. Based upon my experience I can tell you to keep the following in mind while using XML in your projects.

1. Checkout the alternatives like YAML, which is a document format http://www.yaml.org/ that is a very simple text based format and has object bindings in several languages. Instead of truckloads of XML and heavy parsers on two sides of web services world, you could easily have YAML going between a Java and C++ process with straightforward object binding on both sides.


2. Think in terms of simple text protocols, look at existing ones like HTTP if you are writing a client server system rather than inventing an XML based protocol. If your data is hierarchical have a look at XCAP.


3. See if your need for Java configuration can be satisfied by Java Properties, Preferences or simple YAML.


4. If you are building complex Java projects have a look at JRake in place of Ant, which takes the pain out of build management process. Particularly if you are starting afresh and do not have Ant investment done already.


5. If your data is hierarchical then XML representation may make sense, but don’t get overboard, instead use builder/transformer pattern to generate XML when needed but maintain data in a format that is best suited for your requirements.


6. And last but not the least exercise good judgment in designing with XML, question established beliefs. Think objectively if XML is the best tool for this problem. Answer the questions around performance, readability, maintenance as your XML document grows, and if you have tooling to help you with your XML needs.