1) Versioning Make sure your top level element contains all the version information that you need. When you switch versions, change this number and also add version information to any nodes that change substantially enough to require. Basically what I am getting at is that the version information has to be contained at the node level in the file.
2) Proliferation of config files Good point, no way around this one. 3) Schema, DTD, or raw XML? Raw XML, perhaps using another XML file as your schema. 4) External dependency Then don't use libXML. Use expat or some really small SAX parser, and explicitly state the character format etc. that the parser needs to handle. Expat would be a good example. >>The main issue here is that the XFree86 config has simple syntax. The most complicated bits are not the >>syntax, but creating the content. Creating a modeline, setting up multiple displays, activating DRI, etc. >>are going to be the same level of pain whether the config file stays as it is or whether it moves to XML. I agree in the most part, but a well designed xml document would be much simpler, and you could view it with a number of xml viewers (useful? I don't really know but perhaps it is). What the hell does this mean? Obviously it is a modeline for 1024x480 but the rest of it is cryptic. ModeLine "1024x480" 65.00 1024 1032 1176 1344 480 488 494 563 -hsync -vsync I believe that a attributes that are well-named are great meta-data in the file. They do increase the file size but who cares? Compress the damn thing if you are that worried about it. I think the metadata in the file is the most important part of it, personally, and xml with good naming conventions seems to be the easiest file format to understand and manipulate. >>And, as a side note, calling people idiots (misspelled even) rarely helps one's case. No kidding, good call. Chris _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
