Re: Same symbol, different SMuFL semantics

I think the short term solution to this is to keep the MusicXML 3.1
semantics as is and defer changing the semantic issues until MNX. Since the
same element can be used in different contexts in MusicXML, I think it
would be a lot of work to fix this in MusicXML for the 3.1 release.

However, to make it conform better with SMuFL, it might make sense to add a
glyph attribute to the element that would specify which SMuFL glyph to use.
Alternatively, the element could have an attribute that would indicate the
semantics at an attribute level rather than at the element level (or both
attributes).

Example:
MusicXML 3.0: <stopped />
MusicXML 3.1 propsoals:
- Add a glyph attribute: <stopped smufl-glyph="u+e814" />
- Add a semantic attribute: <stopped context="handbellsMalletBellSuspended"
/>
- Combination: <stopped context="handbellsMalletBellSuspended"
smufl-glyph="u+e814" />

(Attribute names are for demonstration purposes only and are not meant to
be the literal names of the attributes).

I think this approach would make the transition from MusicXML 3.0 to 3.1
simple, as these attributes would be optional. If the attributes are
missing, then the implementation would fall back to the default semantics
in MusicXML 3.0. I think that The larger issue of the proper semantics of
elements like <stopped /> should be deferred until MNX.

On Tue, Jan 31, 2017 at 9:59 PM, Glenn Linderman <v+smufl@g.nevcal.com>
wrote:

> On 1/31/2017 6:21 PM, Michael Good wrote:
>
>> 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
>>
>> 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.
>>
>
> I guess part of the question is not only about the MusicXML semantics, but
> also really raises the question of the the semantics of the various
> applications that do MusicXML encoding. If the application has the
> "semantics can only be inferred from context" philosophy, then its encoder
> to MusicXML can hardly know the semantics. But the application should know
> more about the context, if anything electronic does. If only the human
> operator of the program understands the context, then the application
> cannot invent it. However, if the application knows & uses SMuFL, then the
> repertoire of symbols available includes all the glyphs for all the
> symbols, and the human operator should be able to pick the one that is
> appropriate for the context... and that choice should be respected and
> retained.
>
>
> 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.
>>
>
>
> Well, it seems to me that if MusicXML uses the same glyph in the XYZ font
> to represent different concepts, that is OK, because the XYZ font doesn't
> have multiple separate glyphs or character codes for those different
> concepts. But when using SMuFL fonts, that do have different glyphs, that
> the use of a glyph homograph (homoglyph?) would be incorrect according to
> SMuFL.  Which of the various homoglyphs would MusicXML choose to misuse for
> the wrong purpose? How could it seem appropriate to use a non-handbell code
> & glyph for a handbell purpose, or how could it seem appropriate to use a
> handbell glyph for a non-handbell purpose?
>
> It would seem that applications that offer both SMuFL and non-SMuFL fonts
> for use would have to have a mapping of the homoglyphs. Converting from
> SMuFL to non-SMuFL sounds like it could be automated by doing a simple
> lookup, but converting from non-SMuFL to SMuFL might require interrogating
> the human operator to obtain the missing semantics, if the application
> doesn't retain the semantics in other ways.
>
> The application using a non-SMuFL font _could_ (but I have no idea how
> many do) offer symbol subsets to the user when inserting a symbol... the
> user would choose "insert symbol", then "handbell symbol" and then be
> offered a choice of appropriate symbols for handbells... and even though
> some of the symbols may overlap with the symbols for other categories of
> use, the application _could_ retain the semantics of what category of
> symbols the symbol/glyph was chosen from.  In this scenario, the
> application would then have sufficient context to do an automated
> conversion from a non-SMuFL font to a SMuFL font.
>
> If, however, the application using a non-SMuFL font simply present a huge
> collection of symbols to the user to choose from, without categorization,
> or if, after presenting categorized symbols, it retains only the character
> code of the symbols, then there would either be no context to preserve, or
> the context would be lost, and converting to a SMuFL font would require
> heuristic analysis of the encoded music, interrogation of the human user,
> or misuse of particular SMuFL homoglyphs.
>
>
>
>
>> Best regards,
>>
>> Michael Good
>> VP of MusicXML Technologies
>> MakeMusic, Inc.
>>
>>
>
>