Anselm Lingnau wrote:
>
> 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
please try to stay at the formal side with your postings. You kow that
this is not a fair way to speak about the hard work other people do. Its
not just "here and there" like in "silly idiots". Bring up formal
arguments and alternatives.
The problem is that the Q:field is playback active *and* display active.
It may contain a numeral definition for the programs player *and* text
string for the person who reads it (in that case it does not matter much
*where* the numeral definition is stored, in a definition field, or a
macro file or with the program or inside the actual Q:field).
The same case with the V:, K:, maybe M: .
> 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.
Yes.
> 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'.
So , do we accept the style in which the K: and V: fields are extended,
so are all those draft and program related syntax proposals using the
same style of syntax ?
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)
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).
> (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.
This keyword:value syntax *is* wordier, on long an short term, since it
wont shrink by being used. And its neither more natural nor user
orientated. But I will not object if this is common sense.
> 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.
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.
> 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.
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.
and if features are not implemented, it may also cause people to include
%%programspecific commands whithin files.
Simon Wascher - Vienna, Austria
http://members.chello.at/simon.wascher/
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
