Ah. Good. Nicely put. I have a lot of sympathy with this.
(So you now all realise that I have a lot of sympathy with *both* sides).
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.
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. However - where there is a difference, I
agree with you that abc should describe meanings rather than actions.
I'll see if I can come up with a keyword=value scheme that overcomes my
objections to Anselms scheme (in another post, with luck).
Laurie
----- Original Message -----
From: Anselm Lingnau <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 11:47 PM
Subject: Re: [abcusers] something really simple
> Laurie Griffiths <[EMAIL PROTECTED]> writes:
>
> > It's your turn to say what you find unacceptable in the proposal put
forward
> > by me and Simon (the two were pretty much identical).
>
> As far as I'm concerned, the main problem with these proposals is that
> the syntax they define is pretty much particular to the `Q:' field. So
> we get a `-' here and a mandatory space delimiter there, and in another
> field, once we get around to discussing it, maybe a magic squiggle here
> and a couple of dots there if that looks nice and useful. Now that the
> ABC standard seems about to be extended in all sorts of directions we
> should instead be aiming for a consistent style of syntax that allows us
> to express these extensions. For example if we accept the `key=value'
> style of options in fields such as `K:' or `V:' then we should define
> extensions of the `Q:' or `L:' fields in a similar fashion, for
> consistency, instead of giving these fields their own syntax because in
> the short term that seems to be the easier choice and sufficient for
> `everything that is needed'. (This is incidentally why I would prefer
> something like `L:1/8 grace="1/32"' to `L:1/8 {1/32}' as proposed in
> Ewan Macpherson's message, even though it may be wordier in the short
> term.) Chances are that it won't be. I have also tried to illustrate how
> this approach lets us easily introduce further extensions in the future
> -- something that is difficult to do if more ad-hoc stuff is heaped upon
> the layers of ad-hoc stuff introduced in earlier rounds of updates --
> but that doesn't seem to have got through.
>
> The other issue is one that I have expounded upon several times already,
> namely that the ABC standard should as far as possible stick to
> expressing musical content, and leave presentation issues like what kind
> of ancillary ABC information is and isn't printed where and in what
> style to individual ABC-processing software, which is where it belongs
> and how most of this material (such as titles, guitar chords and the
> like) is already being treated. This is a very important distinction,
> and for a famous and spectacular example of getting this wrong look at
> HTML after Netscape and Microsoft were through with it. I would hate to
> see the same thing happen to ABC.
>
> Anselm
> --
> Anselm Lingnau ..........................................
[EMAIL PROTECTED]
> I think there is a world market for about five computers.
> -- Thomas J. Watson, CEO, IBM Corporation,
1947
>
>
> 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
