You should be programming away from bad/worst case scenario not around assumptions about the end-user.
XML sure is terse and unweildy, no matter whether a human is used to it or not, the chances of things going wrong as a result of a "configuration error" when manually editing XML are high.
However, in the day and age of RAD, it's wise and definitely feasible to have a UI manage and maintain the configuration file(s), XML or otherwise.
| [reply] |
XML sure is terse and unweildy, no matter whether a human is used to it or not, the chances of things going wrong as a result of a "configuration error" when manually editing XML are high.
Hmmm, I think I disagree. I think with a well-written DTD, XML configs are significantly less error prone than lots of lines of name=value.
This has got me very interested. Maybe it should be a subject for a Meditation and/or some research...
| [reply] |
How many humans do you know who will adhere to the strict interpretation of a DTD when modifying a configuration file? I like to think I'm pretty good with computers, and I might glance at the DTD, but I wouldn't keep it in hand.
| [reply] |
XML might work if it was well-formed and laid out neatly as per a custom DTD, but that's just extra hassle for the sakes of getting XML to work.
Furthermore, I have seen some weird XML configuration files that go along the lines of this (forgive me if this isnt valid XML, it's only a crude example).
<xml>
<file1 perms="rxwrwxrwx" contents="invoices for the month of may">/pa
+th/to/some/file1<file1>
<file2 attributes="hidden from floor staff" expires="Mar,2007" conten
+ts="company downsizing plans">/path/to/some/file2<file2>
...
</xml>
That opposed to the micro$oft .INI fmt
[File1]
File=/path/to/file1
Perms=rwxrwxrwx
contents="invoices for the month of may"
[File2]
File=/path/to/file2
Attributes="Hidden from floor staff"
Expires="Mar.2007"
contents="company downsizing plans"
The latter not only looks neater, information is easily gleaned out of it when a human reads it. Less is likely to go wrong with it too, IMO and (Tongue in cheek) it also takes up less disk/memory space. :)
Well, I'm a fan of XML (for various reasons) if it's machine-generated and machine-read, I'd consider it in in-house config-files (as long as staff were XML-savvy), but if I wanted to save support staff the headache of dealing with an external XML-unsavvy user, I'd use .INI or something along those lines. XML is just not worth the hassle if you are going to have other people meddling about with it. | [reply]
[d/l]
[select] |
