Draft MNX Specification

Hi all,

The co-chairs are pleased to announce the availability of the first draft
of the MNX specification. Thank you everyone for your forbearance, as it
took quite a while to write. It can be viewed online at this new URL:

   https://w3c.github.io/mnx/specification/

We believe this draft is an important milestone for the group, and hope it
can serve to move our work to a new level.  Let me try to summarize what's
been done, what has not, and what we can do next.

Accomplishments:

- We now have a draft document that tries to supply a definitive
specification for MNX, and can serve as the basis for a more formal and
careful discussion. This replaces the former loose narrative describing
what MNX is like (the now-obsolete "MNX Overview").

- Most of the main structural elements and core notation features for CWMNX
are present.
- Many of the ideas in the former Overview have been re-thought and
improved or simplified, often in response to early feedback.
- Existing examples have been recoded to track the new specification.
- GMNX has been defined to a point where experimental implementations are
viable (see separate email follow-up).

Major Gaps:

- Many CWMN elements that exist in MusicXML have not been addressed yet.
While most should fit into one or another of the categories that exist in
the draft spec, some will not.
- Many previously existing issues raised by the CG remain to be resolved.
- The set of examples is very small.
- We don't yet have a roadmap for a CWMNX reference implementation.
- There is not yet a normative model for the visual rendering of MNX, nor
for its musical performance.

So what's next?

As a next step our plan is to collectively take up the work of improving
this draft, and that means a lot of activity on our issues list at
https://github.com/w3c/mnx/issues. We have no expectation that this will be
a fast process, as there's a lot to mull over and discuss.

In order to keep the discussion focused, let's use the issues to propose
and respond to ideas. Regular mailing list traffic should be reserved for
matters of process, or which rise above the content of the specification.
Here is a quick reminder on some practices that can help us keep our
exchanges clear and focused:

1. Please break problems apart and file an individual issue for each
separate concern. It's hard for the group to work with issues that roll up
many problems under one heading.
2. Please explain exactly how your issue negatively affects a user of the
current specification, in some concrete use case.
3. Wherever possible, please propose a concrete improvement to the
specification. Explain how this change will positively affect the same use
case.

The set of examples also needs much work, and we hope that the CG
membership will supply a lot of good material. The chairs are working on
defining how we can best absorb and organize examples in the repository.

Finally, some means of moving ahead on trial implementations would be a
great benefit. We'll save that for a later thread.

That's all for now. I look forward to a vigorous and constructive
discussion on this list!

Best regards,

.            .       .    .  . ...Joe