Visible XML is Bad XML
by Zef Hemel- Published:September 16th, 2004
- Comments:13 Comments
- Category:General
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.
13 Commenti
Than may I ask you which tool you used to create this site? Would it be notepad?
Good one
For the lay-out (which is what you mean, I assume) I used Vim. Yes, indeed, that’s editting XHTML (which is XML) by hand and I must admit I didn’t like doing it very much. Usually when I do web design (which I rarely do) I’d prefer to use a tool like Dreamweaver to do the design and later incorporate that generated (X)HTML code into a script or application, as it has been years since I last did a static website. But currently I don’t have Dreamweaver installed, and I’m not sure if it can generate validating XHMTL strict.
tnx
Well.. editing XML for me isn’t that much of a problem.
I am used to it so it doesn’t pose such a problem to me.
The problems with editors with expacially XHTML is that it never generates perfect code (as perfect as you could get it with hand)
Dreamweaver also makes you lazy, when it looks about right you just take it, though the code could be a mess.. etc..
Editing XML files for settings indeed isnt the perfect format, but with some help (like hitting ‘>’ will also create an end tag.. etc..) it becomes acceptable
I also like Microsoft Info Path a lot (a windows office app which makes it possible to fill, and edit a XML file via a custom designed form, pretty cool), though it isn’t as flexible as I hoped.
Yes!
The worst thing, in my opinion, is when companies take advantage of their products’ use of XML (or whatever) as a centerpiece of a marketing campaign. It may be relevant, but chances are it’s not.
Developers should care about the core technology, users (should) just care that the technology works.
On a side note, Zef, your writing style is becoming more unique with every post. I actually chuckle at your humorous use of language sometimes. I look forward to reading more of your work. Keep it up.
Thanks a lot Jake.
If it ain’t dutch it ain’t much
Zef, well put.
In general this makes sense, but in some cases a GUI editor would not replace raw XML. XUL and XHTML are examples of this. While GUI editors can be made, they generally don’t produce very good code, and they limit you both creatively and technologically. That said, the argument against forced editing of raw XML _config_ files is a sound one.
Web development is pretty tedious unless done is a Object Oriented language like PHP.
Personally i would just stick to Enterprise System Development.
I actually find that hand coding XML files is not too difficult. There are great tools out there such as XMLSpy, which will complete tags and attributes.
I have hand-written some large(ish) XML files (12k lines), mostly just using emacs. I handcode DocBook. I am also familiar with a lot of XML file formats from work.
Markup is oftentimes a very good way of representing structured input. End users tend to have an intuitive grasp of XML if they have used HTML, as many have. Thus XML can provide a standardized, flexible form of user input to an application.
As far as your specific jab at XML config files, there are some nice XML-based configuration tools such as Ant , which is ubiquitous in the Java community.
I agree that there seems to be a dearth in good XML GUIs. With nice, powerful technologies such as XSD and XSLT, I am surprised that this is the case.
What really brings down XML-based projects is a nonchalant “let’s just do it in XML” attitude without locking down the data model with XSD. Without a certain level of stringency and conformance to a syntax, the parsing/handling/subscribing code in the application will likely become a structureless sphaghetti-fest with hidden bugs and gotchas, galore. This will lead to an incoherent mess on the UI side, as well.
Bottom line = “to each his own”, “use what works”, “it depends”, etc.
If handcoding markup works for you, then by all means stay away from GUI HTML editors and use vi. That’s how I roll, as well.
SGML has the end user in mind.
XML can be seen as a “simplified” version of SGML for automatic processing, with some features removed to make parsers more efficient and easier to write. But the features that have been removed happen to include all the markup minimisation. The other main difference is that XML can perform some forms of syntax checking even when no DTD is available.
Writing SGML with good markup minimisation is easy, if you don’t mind getting your hands dirty in the DTD. Far esier than fighting with fonts and formatting in MS-Word. You can even write niffty DTD’s that make the data look very similar to a simple tabulated file.
When I need XML for easy processing, but have to type in my database by hand, I just type it neetly in SGML, and let my parser turn it into XML.
Not a good idea for a configuration file, but great for a largish database. The raw SGML listing is often quite readable too (unlike XML which quickly looks cluttered).
SGML is XML for humans. SGML is not dead, it slowly integrates the good experimental findings of the XML world. And is stable, for those who wish to use their data into the distant future.
I just discovered YAML thanks to this site. If I hear of it elsewhere, I will use it for my database oriented stuff.
But I will carry on using SGML for everyday writing of technical documents.