begin quoting Andrew Lentvorski as of Tue, Oct 25, 2005 at 08:08:50PM -0700: > Christopher Smith wrote: > >I would argue you can cope with the idiocy regardless. However, it is > >fair to say that XML does provide some buffers against certain types of > >idiocy. That said, there are several other approaches which do a much > >better job of buffering idiocy. > > Maybe. But writing a program to eat "HSPICE Data Output File" format is > a lot easier when it is in undocumented XML that when it is in > undocumented binary. The simple addition of knowing where the > delimiters are helps tremendously.
Ease of reverse-engineering someone else's format isn't a good justification in my book -- it would be better to get the format published/opened up instead. [snip] > >If done properly, it's possible to have a sufficiently large data set > >that can't be rendered into a DOM on a 32-bit machine, but can be > >rendered in a parse tree for a much more well defined format. > > Polygon information normally can't be rendered into a DOM format anyway. > Accessing polygons hierarchically rather than spatially makes very > little sense. So you store it in psuedo-XML or something? > >Again, I think you give XML too much credit. If you want to design a > >format that is extensible, it's not hard to do it. > > Actually, it is. Your parser has to parse generally. Somewhat. But then, I'm a fan of IFF. > Most people who > design a format invariably create a parser with specific assumptions > because "it's easier". Later, they can't change that because "we have > all this existing data". As if they wouldn't do that in XML? > Using XML forces the use of general parsing early on. Especially since > small parsing jobs tend to use DOM to start since it can normally be > rendered directly into an in-memory, tree data structure. ...that you have to then walk to get out the data you want, and if it's the sort of person that would have made a crappy custom format, you now have a brittle tree. (Data is in the third element from the fourth foo tag , unless the second tag has the bar attribute set...) [snip] > The main problem there is the fact that the vendors try to actively > sabotage interchange because dumping your data allows you to change > vendors. In the VLSI design industry, the vendors subotaged EDIF > generators just like they now sabotage their XML generators. Sounds like it's a vendor problem. No need to inflict XML on the rest of the world for *that*. Go beat up your vendors with a stick... -Stewart -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
