Responses Charter Vote Comments

Hi all,

The co-chairs have finally had a chance to review the complete results of
the recent vote on charter language. We thank everyone who responded with
their comments and thoughts, and would like to share our responses with the
group.

We have one request: please start a fresh email thread for any further
discussion of these points, so that we don't get one thread that mixes
everything together.

Comments forthwith:

James Ingram:

I'm still a bit unhappy with the GMNX definition in the current proposal,
> but like the version in Joe's latest email ("an idiom-independent encoding
> of graphics and performance information").
> This probably doesn't matter much, and I certainly don't want to slow down
> the process of re-chartering, but maybe you could use (something like) the
> following:
> "The GMNX format (working title), designed to represent instantiations of
> scores in terms of specific visual, performance and audio content and a set
> of relationships between these facets. GMNX aims to define an encoding of
> graphics and performance information that is independent of the notational
> idiom, and to supply a high degree of interoperability to client
> applications."


The co-chairs prefer the language in the revised charter, but we do agree
with James about the intent to make GMNX independent of notational idiom.

L. Peter Deutsch:

> (1) The charter is impermissibly vague with respect to the distinction
> between "semantic" and "graphical" aspects. Is beaming "semantic" or
> "grahical"? Some clarification about what aspects of CMN fall into which
> category is needed. (2) The strong commitment to some kind of compatibility
> with MusicXML ties any new format to MusicXML's hopeless muddle of semantic
> and graphical aspects, as well as its fundamental misunderstanding of what
> it means to be a standard. I cannot support any charter that takes this as
> a given.


(1) The co-chairs agree on the goal of making a clear distinction here. I
think where we differ is on how and whether the charter needs to describe
this goal. We all agree that the MNX spec must succeed in this respect,
where past efforts have failed. The CG can judge this success on its merits
as we move forward.

(2) The charter and CG aren't making any commitment to MusicXML
compatibility that is strong enough that we would stick to a "muddle",
merely to achieve some degree of compatibility. We do assert that
compatibility is desirable, but not at the expense of setting aside
semantic/graphical clarity.

Dominik Hornel:

1) Deliverables should include together with the CWMNX specification a list
> of works (scores) or extracts of them that are "representative" for the
> music notation in consideration
> 2) The group should point out how music which is nor CWMN neither visual
> GMN, like medieval music (neumes) or extensions of CWMN employed in
> contemporary music (e.g. advanced playing techniques), may be added to the
> existing CWMNX specification


The co-chairs agree with (1). It remains to be seen whether the more open
goal of (2) can be reconciled with a strong, unambiguous CWMN-specific
spec. It's something to keep in mind as we develop the CWMNX specification,
but we'd hesitate to make this a litmus test for success of the initial
deliverable -- hence its absence from the charter. If we do not make the
CWMNX spec accommodate these other repertoires, the path remains clear for
creating additional MNX specs with definite semantics that are appropriate
for those idioms.

Mogens Lunderholm:

I think that a list of musical symbols should be provided (Under
> deliverables). This should serve as a crossreference between the other
> documents. (Music symbol <-> MusicXml symbol <-> MNX symbol
> <-> Character Code in SMuFL and the meaning of it)


A concordance that ties specifications together is a good idea. Suggest
that an issue be opened to track this.

Alexander Plötz:

With the given definitions and differentiations for the two formats, as
> well as with the relevant discussion so far, it must be said that "GMNX",
> realistically, covers phantom scores. There is, in overall relation, only a
> microscopic number of scores/music matching the current "GMNX" purpose
> while reasonably not being encodable with thorough implementations of the
> general approaches that will most probably be at the heart of "CWMNX".


The co-chairs would like to make it clear that GMNX is about much more than
phantom scores. GMNX is a format that can support meaningful rendering of
music ranging from the most conservative interpretation of CWMN, to
non-Western notational idioms, to one-off experiments in notation from
history or in the future. In particular we expect GMNX to be important for
a large class of "partly CWMN" scores that incorporate CWMN concepts, but
also break the constraints required to put CWMNX on a solid foundation.

While I certainly do not want to imply this to be more than a coincidence,
> I would like to point out that the statement can be interpreted in two very
> different ways. It could either mean that any single features and idioms of
> MusicXML should be carried over if they prove to be just as useful, but
> also should readily be disposed of if it turns out to be *im*possible to
> reconcile them with any new strategies to solve over-arching problems. This
> is the approach that I personally would see as appropriate and productive.
> I suspect, though, that the more common interpretation will be a bit more
> literal: as a priority to actually make as few changes as possible to the
> existing MusicXML specification. The most obvious way to achieve this is to
> dismiss issues that would necessitate profound changes.


The chairs' intent is very much the former meaning: we want to retain what
we can, without blocking new strategies to solve the real problems that
exist with MusicXML.

Pavel Studený:

As MusicXML already is quite complex, I personally consider the idea of a
> new, incompatible MNX unfortunate. I can't think about an example where
> this has worked well, although in most cases, such as HTML5 and (abandoned)
> EcmaScript 4, breaking the compatibility has been considered and deprecated.


Pure compatible changes would be great to have. Unfortunately we don't see
this as a scenario in which pure compatibility can fix the problems that
need fixing. But it's not a given that this is a lost cause. The changes to
the initial version of Python language might be one counterexample from
recent history. Or IPv6 vs. IPv4. Overall, we realize the change is
demanding but feel it's worth it in the long run.

Thanks to all,

Joe Berkovitz
Daniel Spreadbury
Michael Good