Laurie Griffiths <[EMAIL PROTECTED]> writes:
> The problem is that we want something that is completely compatible with
> everything that has gone before and that can be enhanced into the future
> with minimal new kludges. There is a tension between the two.
True. It turns out that most ABC header fields are of the
x:yz
variety (I'm putting `x' here simply because it has no well-known
meaning that might be confusing), where `yz' is a magic word like `ADor'
or `1/4=120'. There is a bunch of headers like `T:' and `C:' where `yz'
is something free-form like a title or composer's name that extends up
to the end of the line or up to the spaces and '%' in front of an
in-line comment, and of course there is `N:'.
It is difficult to say things about all ABC-processing programs in
existence but chances are that when a program is looking at, e.g., a
`K:' line it will check that the first non-space characters after the
colon form one of the approved sequences for that field, and not pay too
much attention to the rest of the line. Thus the rest of the line can be
used to add stuff in a way that is likely to not be too disturbing. This
is the basic idea of the whole backwards-compatibility business -- of
course if we were to be completely backwards-compatible we would have to
either leave the line formats alone or hide all new extensions in
end-of-line comments, an idea that I personally find more than a bit
distasteful.
Having said that, the question remains of how to structure those bits
that come after the `leading' item on such an ABC header line. The most
straightforward idea -- and the one Simon promulgates in his tempo
proposal -- is to assign meaning to the following bits according to
their position in the line, with some separator (like a space) between
individual bits of information. If there is only one extra bit of
information after the `leading' item this is indeed a very enticing
idea, but the problem is that it doesn't scale well -- once three or
four additional items of information may or may not occur (according to
the situation) we get stuff like
x:yz a bc - fgh
and users must be able to remember (or look up) which item means what.
It may also force users to specify things that they would rather not,
just so the appropriate slot is taken up and something important that
occurs farther right on that line ends up in the correct place. Besides,
we run into problems if the separator character can occur within a field
value -- this is a critical issue with Simon's tempo proposal, where
x:yz a bc de fgh
^^ ^ ^^^^^^^^^ third field
| +---------- second field
+------------ first field
appears to be allowed. If a fourth field were to be added to this
specification we would have to come up with yet another (non-space)
separator to signal the end of the third field and the beginning of the
fourth. I wouldn't dare claim that this type of notation is still
`user-friendly and natural'.
The nice thing about the `key=value' approach is that the additional
bits can occur in any order and that unneeded items can easily be left
out altogether. In my examples so far I have included quotes around the
values but in fact this would only be strictly necessary if the values
were to include blanks (supposing that blanks, or, more generally,
`linear whitespace' will be used to separate individual `key=value'
items). Having to write `key=' in addition to the actual value may look
tedious at first but I think it is a small price to pay if we gain the
chance to introduce new keys as the need arises, without having to come
up with a way of rearranging the implicit-meaning fields on a line like
`x:yz a bc - fgh'.
> Regarding the "describe meaning" vs "describe action" debate, often it can
> turn into just playing with words. "This is a description of the tempo
> which is designed to be meaningful to the musicians I expect to play it" may
> be a better description but "Look, mate, just print this, OK?" results in
> the same action almost always.
This is true but the important distinction is that `Q:1/4=120' is a
bona-fide property of the piece of music being described -- this is
being emphasized by the observation that it means something completely
different to a notation program than to a playback program -- while
`This will be printed like so in that place' is a property of the
software system used to process the piece of music. I don't think the
ABC standard's business is to describe software systems; it should
describe the meaning of the ABC notation and leave it to the individual
software systems to pick that up and run with it. I'm glad to hear that
we see eye to eye in this.
Anselm
--
Anselm Lingnau .......................................... [EMAIL PROTECTED]
Jock, when ye hae naething else to do, ye may be aye sticking in a tree; it
will be growing, Jock, when ye're sleeping.
-- Sir Walter Scott, *The Heart of Midlothian*
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
