--- "Andrew P. Lentvorski" <[EMAIL PROTECTED]> wrote: > On Mon, 30 Sep 2002, Michael Michael wrote: > > > after 1990... Note these arguments are the > standard > > anti-xml arguments given by most idots.. > > Okay, I will assume that you are not a troll just so > I can put forth some > of the non-standard arguments: > > 1) Versioning > > XML *still* doesn't have any good mechanisms for > dealing with > forward-compatibility and backward-compatibility. > ie. reading a config > file for version 10.4 on version 10.1. The closest > you get is to use DOM > to suck the whole tree in and then query the > existing elements tree only > when you need something. However, this doesn't > address approximations to > elements, obsoleted elements, etc. If you have a > solution, I'm all ears > and you have a reasonably compelling argument for > adopting XML. And not > just for XFree86. I use XML for data interchange in > engineering and would > *love* to hear a solution to this.
You could version at the tag level this would be part of the schema. I think versioning is a generic issue you can have a version tag it thats enough. Most version systems break if a later version is loaded into and earlier parser I don't think there is a generic answer here execpt to provide XLST transform if its possible to generate and earlier format from a later one. What you mean by version seems to be xml translation not versioning the answer it to prove a generic transformation the generates a valid file. Think of the two versions as different XML languages and you need a transform its the same problem. The concept of version just clouds the issue I have to explian this often when people start talking about tag level versioning since it means nothing since this is a translation problem not a version problem. > > 2) Proliferation of config files > > We already have two incompatible config file types. > One for XFree86 v.3 > and one for XFree86 v.4. This introduces a third > type and doesn't really > obsolete the v.4 config file. So which one gets > priority? This can be > handled by fiat, but there will be lots of confusion > in users. This can be decided at install time. My opinion is if the old file is there its translated to XML and removed. > > 3) Schema, DTD, or raw XML? > > And which of these choices should be used for the > config file? DTD's are > supposedly supplanted by schemas, but schema > knowledge and handling hasn't > proliferated very well yet and even DTD handling is > sketchy (most parsers > are non-validating). So, you probably wind up with > dumb raw XML since > it's the lowest common denominator. Raw XML has > very little advantage > over the config file as it stands, and it has a big > disadvantage in that > all the tools written to deal with the current > config format have to be > rewritten. Wow this is not true at all validating parser have been around for a long time. The xserver needs only a dumb parser but the config tools are free and should use a validating parser.. a program called chkconfig or something simlar could wrap a validating parser. In short this is not true. > > 4) External dependency > > Do you want the possibility of killing your X server > when you upgrade your > libXML? That's what this kind of linkage implies. > X is a pretty > primitive/low-level/primary part of most OS's. xml > is fairly high-level > and normally optional. Creating that kind of > dependency is not a great > idea. The xserver need only contian a small simple embbeded XML parser I've seen these in a few kilobytes.The config tools would be installed with whatever parser they use. This is actually a great argument for XML since it allows one to use a complex parser where needed but fall back to a simple fast one at "runtime". > > 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. > > And, as a side note, calling people idiots > (misspelled even) rarely helps > one's case. Arrgh anti xml arguments based on the ability to write parsers are idiotic not people .... Hummm.. Looking Note these arguments are the standard anti-xml arguments given by most idots.. I mean the idiotic arguments not the people sorry... I just don't like going down this road over and over agian. The question is simple if and XML based solution is developed would it be included I don't want to argue the merits of XML. XML is proven technology its pro's and con's are well understood that should not be and issue. The issue is about including the technology. __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
