On Mon, Aug 04, 2003 at 10:40:16PM +0200, Asger Kunuk Alstrup wrote: > I have worked with XML for three years professionally now, and am > continuously monitoring the technology to do this. Most of my experience > comes from the Xerces brand of parsers, because those are ironically the > most mature, even though they are leaking, slow as hell, error-prone and > generally of low quality, because XML is so complicated.
I take it you're against moving to an XML format for the file format then. > There are no good C++ XML parsers so far. They are basically all primitive > and derived too closely from the Java DOM or the SAX APIs. The fit to > C++ is terrible and very much crammed in to kind of fit with a big I don't see what's so ugly about libxml++. Can you explain further ? > sledgehammer. The overhead of these parsers is ridiculous (due to memory > trashing) Like the actual file parsing time is at all relevant to document load time. Then you add on top our ad-hoc gzip stuff, our hand-coded use of libiconv, etc. Offloading this maintenance burden to an external library seems to make some sense to me. > and the ordinary unix text > tools have serious problems. You can't grep xml files, and no practical > substitute exists. diff does not work, patch fucks up, and you can not > even read the files, or edit them in real life. This seems a gross exaggeration ... I grep and diff daily. It's not ideal but it's not "impossible" either. > Yes, you can transform XML documents with XSLT, but that language is too > braindead to begin with, and it's faster to use regexps and a decent > language instead. And this is hardly the case here. Premature optimisation. We're not needing to stream data here. It's at worst a couple of megabytes of document text. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
