- From: Glenn Linderman <v+smufl@g.nevcal.com>
- Date: Tue, 31 Jan 2017 18:59:07 -0800
- To: public-music-notation-contrib@w3.org
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. >
Received on Wednesday, 1 February 2017 03:00:28 UTC