Same symbol, different SMuFL semantics

Dear all,

I would like to get some discussion going on a topic that is currently holding up MusicXML 3.1 development on some of the remaining SMuFL issues. 

What should MusicXML 3.1 do with symbols that have the same general appearance, but depending on context can have different semantics and different SMuFL glyphs? The in-progress issue where this currently comes up is extending MusicXML 3.1 to complete its support for the SMuFL handbells range. This is issue 79 at:

https://github.com/w3c/musicxml/issues/79 <https://github.com/w3c/musicxml/issues/79>

Of all the symbols mentioned in this issue, only the belltree symbol is a new symbol with a shape that is not used anywhere else in MusicXML 3.0. Most of the rest can be represented with either the arrow or stopped elements, but that would lose the handbell-specific semantics.

SMuFL and MusicXML 3.0 have different design philosophies here. SMuFL gives different glyph values to symbols that in general may look alike but have different semantics. This allows more semantic encoding and greater typographic flexibility. MusicXML in general does not do this - for example, the various semantic uses of the + symbol are all represented with the stopped element. 

MusicXML's original design philosophy was that the semantics of symbols is context-dependent. That context is often not fully knowable or known at the time of encoding. So the thought was that it would be best to have a single element for a single symbol, even if that symbol is used in different ways. This also helped to simplify the design of the new format.

At this point I think most of us are in favor of adding more semantics to musical markup. On the other hand, MusicXML 3.1 is a release of quite restricted scope. Where should the balance fall here? Should we start introducing new elements for similar-appearing glyphs. Or is it best to wait until MNX to take a more comprehensive look at how to best resolve this issue?

My current preference, definitely subject to change, is to defer this to MNX. This is in part because I think we could get a better solution if we are less constrained to fitting into the existing MusicXML 3.0 design. It would be great to hear how others feel about this, since this is an important part of MusicXML 3.1's goal of providing better SMuFL support.

Best regards,

Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.