Re: Proposed CG agenda changes

>
> That being the case, however, could you say a few more words about what the
> short-term agenda item
>
> >       Build an initial MusicXML specification
>

Let me clarify -- that *was* on the short-term agenda, but now it isn't.
Michael began by recapping what the agenda had been, but offered a revised
version at the end of his post:

We therefore propose our short-term work cover three main areas:
>         - Document the use cases for music notation formats in a way that
> can help drive decisions about the structural and conceptual changes needed
> in the standard.
>         - Create a very focused, short-term MusicXML 3.1 update that
> addresses the need for broadening MusicXML’s symbol vocabulary and fixes
> some documentation bugs. This update will avoid any areas that are likely
> to be redone if structural changes are made in the future. We already have
> an initial take on what would be included in a MusicXML 3.1 update on
> Github at https://github.com/w3c/musicxml/labels/V3.1.
>         - Produce incremental SMuFL updates as needed for enhanced symbol
> coverage.


One more point you made that I'd like to speak to:

>
> * Identification, in detail, of those specificational issues that would
> have
> to be addressed if one wanted to produce a high-quality specification (one
> meeting my four criteria).  (A simple example: "Specify what elements, if
> any, can intervene between the notes in a chord.")  No effort should be
> devoted to proposing design changes that might mitigate any issue.
>

I believe that this is best done after we've identified an actionable set
of use cases. It is true that some of these issues are technicalities that
are mostly driven by a single use-case: "Developers want to create
applications based an unambiguous, testable, checkable and easily
implementable specification". But my instinct is that the nontechnical
cases will influence some of these decisions in ways not clear to us yet.
(For example, if we wish to generalize beyond CMN -- not a given, but
clearly desirable to some members -- <chord> might conceivably acquire a
more abstract meaning and the answer to this question could change.)

Regardless of when we address this problem, we're eager for your help in
doing that.

Best,

...Joe