XML Descriptors, Be Gone!

Dion posted a story about Nokia’s new mobile widgets. This will be very cool if it’s as good as it sounds. However, what got me was the XML-based config – three separate files for config, skin, and widgets. The widget config:

  1. <widget name="Example widget" version="0.1">
  2.  
  3.   <info>
  4.     <creator>
  5.       <user>username</user>
  6.       <date>7.6.2006 12:00</date>
  7.     </creator>
  8.  
  9.   <!-- Configuration of servicehandlers which the widget needs to operate -->
  10.   <services>
  11.     <service type="syndication" id="feed1">
  12.       <reference from="feedurlrss" to="feedurl"/>
  13.     </service>
  14.   </services>

My comment here isn’t specifically about this project, because most APIs continue to use this convention. I don’t get why APIs continue to come out requiring complex EJB-style XML config, in three different files no less. Learn from Rails and Pico and use code for config.

The arguments for XML config are fundamentally flawed:

  • “Anyone can edit it, not just programmers”. And if you believe that, you’re still waiting for your manager to learn FORTRAN and COBOL, thus rendering programmers obsolete. Mwuhahah. Obselete, I’ll tells ya.
  • “It can be changed at runtime, no compilation required.” This might occasionally be useful if the app’s shipped off to another site, but that’s a slim minority – it will either be a hosted app which you can easily re-deploy after re-compiling (as with these widgets) or a desktop app which will hopefully offer a nice config UI rather than requiring the user to hack some XML files! We like to develop standards to serve the vast majority, not the slim minority.
  • “It’s neater.” In any modern language, you can easily develop an API that lets you perform configuration with a grammar resembling a domain-specific language. I don’t consider the above XML to be particularly neat, nor most EJB descriptors I’ve come across.
  • “It can be validated.” True, you can check the file’s grammar, but you can’t validate that a given attribute must be a class in your program, for instance. With code-based config, you can.

3 thoughts on XML Descriptors, Be Gone!

  1. Hi Marcos, I’m glad this came to your attention then! I think some of the newer Java frameworks like Spring provide a good example of how XML can be used interchangeably with code. There’s a config object and the framework simply allows for multiple ways to construct it. i.e. the starting point for thinking about config is the declarative config object rather than any particular means of building it up. Once you know that, anyone can write a library to build it with XML, YAML, CSV, code, etc.

    I realise that’s trickier for a spec like yours that’s language-independent, but still a relevant design force.

Leave a Reply