Simon Wascher <[EMAIL PROTECTED]> writes: > Bring up formal arguments and alternatives.
Well, guess what I have been doing for the last few days? > As far as I observed the K: and V: field discussions where halted > whitout a decision on the right syntax. but for me: > > Q:3/8=69 display=allegro > Q:3/8=69 display="allegro" > > both displaying just: allegro > > or something similar would be OK to *me* (as I said I do not care much > what SEPARATOR is choosen) Great. So there's apparently some middle ground. > All the discussion just started since it was sugested (and later on > verified) that there would be more user orientated and "natural" ways to > indicate tempo specifications (which only have the disadvantage that it > needs to make use of a extended syntax in cases where a n/n=n *playback* > tempo definition is not being displayed). Yes. And in the future we will need some more extended syntax for this and even more extended syntax for that. What's wrong with at least agreeing on a method like `key=value' that will allow us to bring in more fields as they are needed, without having to worry about how programs will be able to tell where this bit of the line ends and the next one begins? At least the `key=value' specifications are trivial to parse, and the same parsing code works for all ABC headers that use this syntax. You could use the same subroutine to parse lines like K:Gm clef="bass" V:fl instrument="Flute" short="Fl." Q:3/8=69 display="Allegro" and the code for the particular header would just have to look at the `leader' and the various `options' with their values to figure out the meaning. This as opposed to having to write a special subroutine for every header to deal with that header's particular syntax. Writing `Q:3/8=69 - Allegro' may seem `user oriented and natural' at first sight but after the special syntax for the `Q:' field has been extended three more times to support other new (and at that moment certainly important and desirable) features it may not feel so `natural' after all. > You do a lot of ad hoc stuff too, if you define ad hoc stuff as syntax > that is newly introduced into the draft (do not forget: draft is not > standard). the whole keywoard=value syntax is not generally approved, > and whithin that there is no general approval for the quotes as > delimiters. I define `ad-hoc stuff' to be syntax that is used in one particular header field, such as `if there is a `-' after the metronome speed in a `Q:' field that means that the metronome speed is not supposed to be printed'. Why don't we allow a `-' after a composer name in the `C:' field so the composer name will not be printed? There are plenty of cases where one would want to have this facility -- for example, if you typeset Bach's Well-Tempered Piano you don't need to put `Johann Sebastian Bach' across the top of every prelude and fugue since the information is already on the title page of the book. Allowing such things in one place but not in another is one aspect of what I call `ad-hoc' syntax. Again: My point is that the ABC representation of a tune should not say what must be printed and what mustn't, since it is impossible to foresee in what context the ABC is going to be used. The ABC representation of a tune should give as much musical information as is reasonable but should not specify how programs will make use of it. It should not be necessary to change the ABC representation of a tune just because it is supposed to be played back at a different speed this afternoon or because the tune title should be printed flush-left in 15-point Palatino instead of centered in 12-point Times Roman. Finally, let's for the moment stipulate that your proposal goes through and that we will be able to write Q:1/4=60 - Andante ma non troppo If you define that everything from `Andante' to the end of the line -- excepting a `%' comment, of course -- is a textual tempo specification then how are you ever going to put in another data field if that should become useful at some point in the future? (The `mode="accelerando"' idea that I posted the other day, while of course meant strictly as an illustration at this point, is the sort of thing that we might run into in the future.) This sort of thinking is what Gianni would probably call `short-sighted' if he were still around. > [Musical content vs. presentation issues] > As pointed out this your argument does not stop the need of a stringent > syntax for this, since it does not much make a difference which part of > a program has to recognize a string. The idea is to keep musical stuff apart from presentation stuff. Presentation details might go into a separate file, using syntax (like CSS, if you will) that is more appropriate for the purpose than bastardized ABC. In my opinion it is a very bad idea to mix musical and typographic information like your `Q:1/4=60 -' proposal does -- even a %%abctypesetter dont-display-metronome-speeds option line would be preferable since at least this separates the concerns of musical information and presentation. > and if features are not implemented, it may also cause people to include > %%programspecific commands whithin files. Does that mean we need to put everything that could possibly occur somewhere in some kind of musical notation into ABC, just so people don't feel tempted to use `%%something'? For all of the presentation stuff we wouldn't need anything more than %%abctypesetter style urtext-edition in the ABC file. The hypothetical `abctypesetter' program might interpret this as a reference to a set of presentation instructions that are either built in or available in an external file somewhere on the system. This would prevent us from having to clutter up the actual ABC representation of the tune, which after all is used to share musical *content*, with all sorts of stylistic details that programs could support or not. (And if you are in the business of sharing musical *presentation* -- like near-facsimiles of old musical scores: If ABC works for you in this context then more power to you, but people will like you better if you put up your formatted score as a PDF file alongside a very straightforward and clear-cut ABC-notated version of the content, and the corresponding presentation style file. For even if you *could* specify most of the nitty-gritty little presentation details in your ABC file so that things worked to your satisfaction with your ABC notation program, chances are that *their* ABC notation program will do all sorts of little things differently and their output will not look like yours, anyway.) I keep going back to HTML but it really seems to me that we're about to make all the mistakes over again that the HTML crowd made a few years ago. They're now busy trying to get the world to accept the idea of separating presentation details from content (by using style sheets and the like), with little apparent success. You may or may not remember that originally HTML had tags like H1 and EM (for `emphasize') so people could mark up their pages according to the *meaning* of various items rather than in terms of what they were supposed to look like when rendered. It was only after outfits like Netscape and Microsoft came in that HTML suddenly acquired stuff like BLINK and FONT, which certainly allowed for some cool and snazzy effects that people liked to use, but made the idea of HTML as a language for `meaning-oriented' as opposed to `presentation-oriented' markup go straight out the window. The Web is still reeling from the aftershock. With ABC, we remain for now in the fortunate position of being able to prevent this from happening, and in my opinion we should take that opportunity while it still exists. Anselm -- Anselm Lingnau .......................................... [EMAIL PROTECTED] Politics is for the moment. An equation is for eternity. -- Albert Einstein To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
