I was going to let this idea die quietly... <sigh> If we were talking about creating a data interchange format, I'd agree 100%.
But we're talking about creating a general purpose front-end parser that can be linked into assorted ABC programs so they don't have to write their own parser. Having the output of that be a text format defeats the whole purpose, because each application would then need to write it's own parser for *that* format. It's been suggested that such a second-stage parser would be a trivial job to write. As a programmer who has written a number of parsers of various complexity over my career, and looking at the amount and complexity of the data we're talking about, I'd have to say that "trivial" is doubtful. It's probably not a complex task, assuming the text format is designed properly, is totally unambiguous, comprehensive, and flexible enough to do the job. But it's bound to be tedious and time consuming. I suggest anyone who thinks this is a trivial job should actually design such an intermediate text format, and then try and write a parser for that format. Let me know how long it takes. ;-) As a final thought - if anyone *really* wants to see text output from such a parser, let the parser be written to output C structures or whatever the programmers want, then they can write their own back end to the parser to convert the output into any text output format desired. It should be relatively easy to do. And everyone can be happy. -->Steve Bennett Jeff Szuhay wrote: > On Wednesday, July 28, 2004, at 03:43 pm, Bernard wrote: > [snip] >> The maximum is ascii. You can even read it without a computer. >> >> Flexibility is maximum in ascii. A new keyword is added and the old >> software doesn't understand the keyword and will ignore it. The >> problem of upgrading software is old software which won't read the new >> software's output at all. > > [snip] > > I agree completely with this. In fact, for the past 10 years, the whole > of computing has moved towards ascii-based (character-based) data > interchange standards away from binary data formats. To wit, SGML, HTML > and its variants, XML, as well as scripting languages which remain text > based and uncompiled (binary data). As an example, Perl, Python, > Javascript run on more platforms than I know. A powerful database > environment I worked in years go made every record available as text > (it lives on in Universe and > "multi-value" databases). LaTex and PostScript ... text based. > > The only (bad) reason to not use ascii for text based data IMNSHO is > when a vendor wants to maintain control of their proprietary data > format. Good for them but a real PITA for everyone else. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
