Should GMNX have its own repo?

[joeberkovitz]

Putting GMNX in its own repository would create a separate space for discussions, notifications and other GitHub activity.

Is this a good thing for the Community Group? This issue is a place to discuss that question, which has been raised in #25 among other places.

The original motivations for a unified repository are as follows:

• GMNX can act as a publishing format for instantiations of CWMNX (and also of new semantic dialects, for other notational systems and other cultures). We want CG members whose primary interests lie in CWMN to be aware of this relationship, and not assume that GMNX is some exotic thing sitting in a corner by itself.

• CWMNX actually makes use of some of the performance-data elements of GMNX in its <interpret> element, to encode a "low-level" description of the performance interpretation of some chunk of a score. So there are some definitions in common (although this doesn't preclude separate repositories).

[notator]

For me, the answer is obviously YES! :-) GMNX should have its own repo.

Here are a couple of thoughts that might be worth considering:

• Having separate repositories for CWMNX and GMNX would not mean that CWMNX is going to get less attention. It is still up to the community to raise issues wherever they think fit. Its quite possible, that @joeberkovitz and I will be the only contributors to the GMNX repo at first, but it would, for example, be the place for specialists in non-CWMN notations to come, should they want to join us later.
• The whole point of defining standards is to allow conforming software to be written. That will be true of each semantic dialect of GMNX as soon as it has been well defined.
• I take it that the current repo will continue to be concerned with classic (legacy) CWMN. The new GMNX repo will deal with everything else. That's a clear division of responsibilities. Note that an interchange of ideas between these two worlds remains perfectly possible and is obviously desirable.
• CWMN is the most advanced music notation currently supported by commercial software. Nevertheless, I think I know how to define a semantic dialect of GMNX that would be even more efficient/useful in future. We will have to wait and see what comes of that, but my feeling is that music notation is not, after all, suddenly going to stop developing.

[EDIT 28.02.2018] Another thing that would differentiate between the two repositories, is that GMNX is clearly about instantiations while CWMNX is not. That means that the GMNX repo would be the place to discuss the synchronization of instantiations (Cursors etc.) [/EDIT]

[joeberkovitz]

I should clarify that any decision to give GMNX its own repo doesn't in itself change what GMNX is. Splitting the repositories would be a decision about process and managing conversations, not a de facto decision to take GMNX in some new direction with new responsibilities outside the existing group charter.

According to the charter -- and this is not an accident of careless wording -- GMNX doesn't have semantic dialects. From the charter: "The GMNX format (working title) is 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 supply a high degree of interoperability to applications that do not depend on particular notational systems or their semantics." This is not necessarily a forever thing -- as we know charters can change -- but it is how it's constituted now, and it was not easy to formulate it and get agreement on it.

@notator: Saying that something is outside the charter doesn't mean it's unimportant, or not worth doing. It only means that the group hasn't committed its membership to putting in the effort, as a group, which is a big commitment. In no way should this position discourage you (or anyone) from working on non-CWMN dialects. One fruitful direction you could go in, and I would personally embrace it, would be to work up a sibling to (or superset of) CWMNX, which adopts a much more general conception of events, symbols, time, sound, and so forth, while GMNX evolves in a somewhat decoupled way. While such work would be outside the charter, it would have the potential to become an extremely valuable starting point for the future and would leverage much of your specialized knowledge. The result, if adopted, would be something that could later plug into the framework as a whole, alongside CWMNX, with no loss of connections between its concepts and the graphics/audio encoded in a GMNX document. The net information would be the same, I think.

If you want to adapt GMNX into something that directly builds in semantics, you can do that too on your own steam and the results will doubtless be of interest. It's just a big step further away from the agreed direction, and sets up a conflict between the way GMNX serves CWMNX and the way GMNX serves your proposed semantic dialects. That's not going to be easily agreed to, and many of the same counterarguments voiced by the community in #25 will apply to this scenario too.

I suggest we continue the rest of this discussion elsewhere, perhaps in #28 which seems applicable, and leave some room for others to chime in on the repository question from other angles.

[joeberkovitz]

One more clarification: GMNX should be of fundamental interest to the CWMN community, because CWMN scores can be published as GMNX instantiations and thus made available to a broad new family of music apps that don’t need to internally deal with the complexities of CWMN concepts. For this reason I’d encourage CG members not to think of a potential GMNX repo as the “non-CWMN department” of this group.

[notator]

Thanks @joeberkovitz for your thoughts. I think we have all come a long way since the Charter was formulated, and that the current state of the debate may indeed mean that a revision ought to be put to the vote.

I think we can agree that GMNX is no longer just a side-issue running parallel to CWMNX. As far as I'm concerned, GMNX is now the name of a family of semantically enhanced SVG file types, whereby the family includes files containing CWMN. That is a much more powerful idea than that it should simply "supply a high degree of interoperability to applications that do not depend on particular notational systems or their semantics". "Applications that do not depend on particular notational systems or their semantics" are never going to be able to achieve very much compared to applications that do have access to meaningful semantics. So we now know much more than we did when the Charter was formulated, and the old definition of GMNX is simply obsolete.

One fruitful direction you could go in, and I would personally embrace it, would be to work up a sibling to (or superset of) CWMNX, which adopts a much more general conception of events, symbols, time, sound, and so forth...

I've actually been working on such a notation for about 35 years. Its a sibling of CWMN that uses slightly different semantics.

..., while GMNX evolves in a somewhat decoupled way. While such work would be outside the charter... and The result, if adopted, would be something that could later plug into the framework as a whole, alongside CWMNX, with no loss of connections between its concepts and the graphics/audio encoded in a GMNX document.

I fail to see how I can plug my work into the framework as a whole if the framework continues to treat GMNX as defined in the current charter.

Its not just for my benefit that the charter needs revising. There are all the world's other music notations to consider too. Issue #23 also needs to be debated and settled. Is the MNX container really necessary or not?

[joeberkovitz]

I'm afraid we'll have to agree to disagree on your definition of GMNX, which is not the one that the community agreed on. This is not at all my decision to make. The charter is ultimately about resources, budgets and time, and has involved decisions not only by the community but by many of our employers. We can't simply revise the charter and enlarge the focus of the group because you feel it would be best. Please kindly respect the effort that goes into making this group a shared project, and one that gets enough funding to do useful things. Please also respect the limited time that volunteers have to read the notifications they receive from the list and the repositories.

Also, please respect the effort that has gone into leaving room for the very projects that you are pursuing. I would love to open your mind to the idea that GMNX actually supports your agenda, since I believe it does. GMNX is designed as a neutral "hub" into which the notational systems of the world, including yours, can connect, even though it does not directly include them. So please do not suggest that the community must change the charter now, in order to solve the problem as you understand it. The community has clearly voiced objections to "semantically enhanced SVG" for use with CWMN, and these issues are not necessarily different for other notational systems.

As regards your 35-year project: The current direction of this group allows smart people like you to work on any semantic system you like, in parallel with work on CWMNX and GMNX. I hope you will continue to do that, in whatever form it takes, and that those contributions will flow back into the work of this group when it's ready to take them on. If your notational system puts everything into SVG, then that's up to you. This, too, can be ultimately converted into GMNX and utilized by any GMNX-compliant application, without knowing more.

[joeberkovitz]

I do want to very specifically answer @notator's concern about the ability to plug external semantic modules into GMNX as currently defined, because this explanation may be generally useful for all.

Begin by considering the Faure GMNX example. Temporarily set aside the fact that it's using CWMNX, and that everything is in a single file -- <score src="..."/> may be used to include multiple, separate files in this fashion.

The <score-mapping> elements in the GMNX portion, reference specific SVG elements and connect them to specific elements in the CWMNX portion. In this way, CWMNX remains unperturbed as a semantic dialect, and GMNX remains unperturbed as a general, semantics-free format. At the same time, any SVG element can be connected -- by element reference -- to the CWMNX concept of which it is a rendering.

Now step back and consider that instead of CWMNX, the semantic dialect is MNX-21stCentury, or MNX-Koto, or MNX-Tibet. There is nothing about GMNX that needs changing, in order to make the same connections as can presently be made for CWMNX. And applications that do not wish to make notation-specific assumptions, can work for all dialects without modification. (Those that do make assumptions, will need to follow the element back to the semantic document.)

All of this could also be done with SVG class names, or with namespaced data salted into the SVG file. None of that would change the sum total of the encoded information, and the pros and cons of doing so will yield a debate remarkably like that seen in #25. In summary, this shows that future semantic dialects do indeed have a way to "plug in" to the present GMNX approach, and that the charter doesn't need alteration to accommodate this goal.

[joeberkovitz]

The chairs discussed this question today and would like to repeat the invitation to other community members to offer their points of view on whether it makes sense to manage GMNX in a separate repository, noting that this does not automatically imply a change to its definition: it's a change to the way that the discussion takes place. Such a change could also entail a breakout of the MNX container schema.

[notator]

I have not been trying to completely re-define GMNX (=MNX-Generic) since 16th March. So, as far as I'm concerned, this issue could be closed (without creating a new repository).

@joeberkovitz said above

One fruitful direction you could go in, and I would personally embrace it, would be to work up a sibling to (or superset of) CWMNX, which adopts a much more general conception of events, symbols, time, sound, and so forth, while GMNX evolves in a somewhat decoupled way. While such work would be outside the charter, it would have the potential to become an extremely valuable starting point for the future and would leverage much of your specialized knowledge.

That seems to be the way things are going. :-)

[adrianholovaty]

(Closing this issue because MNX-Generic is no longer in scope for our community group.)