Steven Bennett wrote:
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.
This SPECIFICALLY is what has confused me regarding this whole discussion... When I proposed the idea of a universal parser, I stated with NO AMBIGUITY that it was not to generate text.
It was to have a control API which would could be asked questions and return answers.
Once the file is parsed, a possible method would be list_titles(1,10) to return the primary titles of the first 10 tunes.
This is just an example... not a well thought out API function... Anyways... an API of useful commands to glean information from the file, as well as commands to alter it.
I would not object if it had a function to generate_musicxml() or something like that, but that would not be it's primary function.
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
-- ||
Christian Marcus Cepel | And the wrens have returned & [EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of 371 Crown Point, Columbia, MO | that oak where his heart once 65203-2202 573.999.2370 | had been; And he lifts up his Computer Support Specialist, Sr. | arms in a blessing; For being University of Missouri-Columbia | born again. --Rich Mullins
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
