Neil Jennings wrote:
The point about using XML is that although it is a text format, parsers already exist on all platforms which can parse the XML, and hold the data in an object structure. You can then extract whatever information your application needs.I cannot see how that would be useful for a playing/editing/displaying program which both reads and alters the file... The output here is ABC.... Once an abc file is parsed and made compliment with specifications (whichever it fits into.. 1.x or 2, or whatever), it would be super easy to write a bullheaded abc2xml routine that does no error checking because it's already been done.
The existing MusicXML provides MOST of the features necessary.
The point of an ABC editor/player/engraving program is to work with ABC files. You open the abc, you edit the abc, you save the abc. If you want to generate a MusicXML file for interchange with other software, great!
What you seem to be proposing is that we migrate abc tunes to MusicXML and discard the ABC... sure that's not what you've said, but you're stepping away from the fundamental point of abc AND this universal parser, which is to be a tiny reusable library of functions.
If I understand it, you're proposing that an abc file be:
1, referenced by a software package
2. a universal parser invoked by the package to convert the abc file into MusicXML
3. that output either buffered, or stored.
4. a second parser, a MusicXML parser invoked by the program to pull the data into an object structure.
5. editing/engraving/playing activity on the object structure.
6. time to save changes. Second parser is invoked to flatten the object structure into MusicXML
7. output is either buffered or stored.
8. universal parser is invoked to translate the MusicXML into abc AAANNNDD to figure out how to alter the file with the changes, (unless the file is just replaced en toto (Dorothy's dog), or a new file is chosen.
Perhaps you can explain it to me, but this seems a HUGE waste. You are essentially proposing that all programs created using the universal parser be absolutely unaware of ABC, and only aware of MusicXML. Why the devil would anyone want to write a program which starts with the technology they wish to promote, translate it into some other technology which, while good, is not at all suitable for the purpose the original technology is for (remember.... the ability to read music directly from ABC, and to send thousands of tunes in a tiny tiny email.) work with it... essentially, they are making a MusicXML editor/player/engraver, and then translate it back into this poor inferior format of abc.
Seems to me like you're driving a jeep into a C130, strapping it down, taking off and flying to an airstrip 30 miles away, debarking, doing your business, getting back in the jeep, strapping it into the C130 and then flying back home and again disembarking.
You could have driven the 30 miles in a fraction of the time it took to handle all the logistics, and for a fuel and personnel bill you'd actually be willing to pay. Not to mention the fact that you know perfectly well how to drive and handle a jeep.... To complete this stunt, you also have to procure and learn how to fly a C130 (They're slashing the prices at crazy Gene's used aircraft... See AirAmerica)
Now... that all having been said... there's nothing wrong with adding subroutines (perhaps inheritable ones) to the parser to read in/read out MusicXML, for those who have a C130, hundreds of hours in type, and prefer the fly the friendly skies between destinations. Just don't destroy the bridge halfway between destinations so those who prefer to drive over flying have no choice but to fly.
The biggest plus about a universal parser is that we will all be working from the same abc definition. The project will probably result in a new, better, abc definition as some of the errors and omissions will be corrected in the process.
Neil
I would agree....if it ever gets started... it would probably point out some nifty improvements to how certain things are done in the spec.... But i don't agree that we will all be working from the same abc definition... The universal parser needs to be able to handle whatever abc it can reasonably come across. This means multiple versions of the standards, and common extensions created by other developers... or if not able to handle those extensions, it should not discard that which it does not understand, and should keep that information retrievable for use/alteration/reference/etc by those who wish to add that special functionality. Jim Vint's ! forced linebreak may not be standard in some versions of abc, but as a programmer, I don't want to be kept ignorant of it's presence. I want to know it's there and choose to implement it, or not implement it in my engraving techniques.
Christian M. Cepel wrote:
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
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
