Being a developer you might be all excited about XML and all the technologies around it. That’s good for you, as long as you remember that end users do not want to see it. Never. Not under any circumstance. Remember it’s just a file format. If you know how the Word file format works you’re not going to edit it in a text editor either, are you? Sure, XML is a more readable file format, but, believe it or not, it’s still not something that clears up the rainy day of the average application user. Personally I’d like to set the following as a rule: Visible XML implies bad use of XML.
Many applications use XML files to store settings in. That’s fine with me, if there’s some tool to edit those settings, other than a text editor, be it from the application itself or an external application. Why? Because editting XML by hand is no fun. If you like operating systems that store all their settings in text files, even then I’m pretty sure you don’t find XML a convenient format to edit. In case you ever configured Apache and Jakarta Tomcat (an Java servlet container), which config files do you prefer editting? The non-standard Apache configuration files or the XML files Tomcat uses? My answer would be the Apache one and I’ll tell you why: it was designed to be edited by hand. All the left and right brackets, entities and other junk in XML are not cool to type. So if you’re not going to supply tools to edit your XML files, don’t use an XML file format. Using XML just for the sake of using it is not making Peter giving you a backstage-pass to heaven.
What about consistency? Believe me, I’m not such a big fan of the inconsistent free form configuration file formats different applications use, but XML doesn’t add consistency either. Sure the syntax is the same, but that’s only on a very low level. On the higher data-scheme level all the setting files formats still are totally different. The only nice thing about using an XML-format config file is that there are plenty of parsers available for it already. But that’s just a programmer’s advantage, not an end-user one. I say, spend the time that you saved on using an XML parser instead of a custom parser on developing a tool to manipulate your configuration files.
This obviously not only goes for configuration files. There are many more XML formats that, for now, you can only use by writing it by hand. GUIs for example, Mozilla’s XUL or Microsoft’s XAML would be so much more usable if they came with a visual designer to generate those files. But I’m sure, eventually, those designers will be available.
As an off-topic note: I’m going to try to make posting updates to my website a daily event again, for as far as humanly possible that is. I’m doing this to keep thinking creative thoughts, to be able to talk about something semi-interesting every day, without ending up with what I ate for lunch that day. Let’s see if I can pull this off.