begin quoting Andrew Lentvorski as of Fri, Jul 06, 2007 at 10:21:40PM -0700: > Stewart Stremler wrote: > >begin quoting Andrew Lentvorski as of Fri, Jul 06, 2007 at 05:17:23PM > >-0700: > >>I don't know why everybody complains about XML. > > > >'Cuz it sucks to work with XML. You need pretty-printers and custom > >editors and days of trying to figure out what the hell has gone wrong > >with the configuration since the parser now chokes and dies with > >"Parse Error, line 3". . . > > Huh? Emacs works for me just fine. That's the whole point of using XML > in this instance. Emacs handles the tagging and editing without needing > some bizarre custom editor. Emacs *is* a bizarre custom editor.
Now that we've got the editor insults out of the way... I really ought to dig up my XML file that won't parse without a network, and see how it looks in emacs, and see if emacs tells me if there's something wrong. I kind of doubt it, but one never knows. > Doesn't vi handle xml? By "vi" do you mean "vim"? It does syntax hilighting and suchlike. But it doesn't -- nor do I want -- make itself into an "xml editor" like XMLSpy and friends. (And I loathe the XMLSpy approach anyway.) Hm. This may be an editor-difference. Maybe the folks who like UNIXy things and vi perhaps tend not to like XML; those folks who do not like UNIXy things or vi tend to like XML. > >>You suck the whole tree into memory. You walk the tree. Done. > > > >You suck the whole tree into memory. You loop through an array of > >XPATH expressions, and store the result in a map. Done. You're right. > >It isn't that hard. > > Uh, what's this XPATH crap? You pull the tree directly into a series of > hierarchical maps directly. That's the DOM object. You still want data out... so you still need a key. And because it's in this big ugly DOM object, that key might as well be an XPath string. Key + DOM = value, done. You can also walk the DOM object and generate your own config object, but that gives you a two-step process where you end up handling every piece of data twice, and that conversion step is prone to error. Walking the DOM tree is painful, error-prone, and tedious. XPath greatly simplifies it... you work out the path to the data you want, once, and you suck it out. > >It's not the programmatic side of things that's annoying (well, it is, > >but that's because XML parsing libraries are not nice in C, C++, Java, > >and so forth -- and picking a language based on XML support seems > >backwards), > > Well, the problem with C and C++ is serialization. You effectively have > to reduce everything to strings and then laboriously transform things > into integers, floats, etc. Yup. > I don't understand why Java has such crappy XML API's, though. It > doesn't have the static limitations that C and C++ do. Yup. The Java XML APIs seem to be based off of the C++ APIs. (Or maybe vice-versa.) Maybe in languages like Lisp or Forth it's different. I've heard that some of the Smalltalk folks generate classes and populate objects at runtime, so I believe different languages handle XML quite differently. I've mostly worked with XML in Java and C++, and it's just plain nasty. In a scripting language (TCL, sh, csh, etc.) I wouldn't bother with an XML configuration either, as I have a ready-made parser on hand in the language interpreter. > >Just because *you* don't look at configuration files doesn't mean that > >*I* should suffer when I go and I look at 'em. The file format on the > >disk should /first/ be for humans. SGML and children ain't for humans. > > By that logic, we should be using English. Uh, pass. Um, no. (And I fear the day someone announces a general-purpose English NLP. We'll have REALLY impenetrable configuration files then!) You're correct when you write: > We make some concessions so that computers can cope. I agree. Emphatically. And then underline "some". Three times. In red. > The moment you > need quoting and nesting, you have something like XML. You might as > well start with it. This is a major philosophical difference between us. Bad analogy time: You end up paying a third of your money to the government anyway, you might as well just have your paychecks for january, february, and march go straight to the IRS, and get it over with. And yet... nobody that I ever heard of does that. Don't borrow trouble from the future. Plan ahead, sure. Take precautions. Make your configuration a subsystem, so you can swap it out at a moment's notice IF the need arises. Mapping from key/value to XML shouldn't be that hard -- a short perl script and an XSLT (since they're so easy and all) and lo! There's your XML configuration file ready to be used by your XML configuration subsystem. -- And they say that *I* pessimistic about future code changes. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
