3 ms·
I've done both, and I regret the mini-parsers I wrote. It was for stupid stuff, like config files. The main problem is that nobody else could do anything with
by mullr 18y ago
I've done both, and I regret the mini-parsers I wrote. It was for stupid stuff, like config files. The main problem is that nobody else could do anything with the code. XML is at least a common denominator. Not the lowest, but pretty low. :)
I've found it easiest to deal with xml in a very focused way. In my case, I always define a schema and use a code generator to get things in/out of memory. From there on, I don't care about the xml anymore. This is fast and reliable. The only real downsides are (a) ugly xml syntax, and (b) having to remember how XSD works every time.
Where I really object to XML is as an internal construct in a system. It's useful for putting things on disk, and it's useful for interchange with damn near anybody because of the ubiquitous libraries. But you don't want to be keeping your core application state in a DOM. Or using it as an inter-component interface. I've seen more than one person do that, and it made me very sad.