Re: Proposed CG agenda changes

Hi Peter,

As Joe mentioned, the "build an initial MusicXML specification" item is something that was on the short-term agenda that is no longer there. However, the initial proposed plan for MusicXML 3.1 does contain some of the things you suggest, such as correcting typos and other outright errors. The MusicXML GItHub issue list also has a starting point for specification issues.

Here are the relevant GItHub links:
All V3.1 issues: https://github.com/w3c/musicxml/labels/V3.1 <https://github.com/w3c/musicxml/labels/V3.1>
All documentation issues: https://github.com/w3c/musicxml/labels/Documentation <https://github.com/w3c/musicxml/labels/Documentation>
All V3.1 documentation issues: <https://github.com/w3c/musicxml/issues?utf8=%E2%9C%93&q=is%3Aopen+label%3ADocumentation+label%3AV3.1 <https://github.com/w3c/musicxml/issues?utf8=%E2%9C%93&q=is:open+label:Documentation+label:V3.1>>
The MusicXML GitHub issue list was created when we formed the group as a way to collect, document, and share the most popular suggestions and requests that I had logged over the years.

Best regards,
Michael
_________________________________

Michael Good
VP Research and Development
MakeMusic, Inc.
 

> On Nov 9, 2015, at 3:42 PM, L Peter Deutsch <aemusic@major2nd.com> wrote:
> 
> Hi Joe,
> 
> Thanks for your thoughtful reply.  I'm glad that we're all in agreement on
> the eventual goal of a future notation standard with an excellent
> specification, and now that I understand the larger context better, I can
> support not attempting a high-quality specification for MusicXML 3.1.
> 
> That being the case, however, could you say a few more words about what the
> short-term agenda item
> 
>> 	Build an initial MusicXML specification
> 
> means?  What would such a specification consist of?  What would the criteria
> for success or completion be?  What would we want to learn from the process?
> I would really like to see some discussion of those questions before
> starting, but perhaps you're already working on proposed answers and I'm
> jumping the gun.  However, if you'd like a straw man, here's one:
> 
> The "initial MusicXML specification" should just be the existing commented
> DTD, with work limited to these tasks:
> 
> * Minimal alterations required for thoughtful SMuFL integration.
> 
> * Correction of typos and other outright errors.
> 
> * Additions that do not involve any changes or additions to the existing set
> of elements or attributes -- i.e., limited to additions of new alternatives
> for attributes or CDATA values currently chosen from fixed sets.
> 
> * 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 think the last of these is worth doing because I believe it will be very,
> very helpful in identifying problematic areas for future design
> consideration, without taking positions on how to fix them.  That is the
> response to my "learning" question.
> 
> 						L Peter Deutsch
> 
>