Re: Revised Community Group charter – request for feedback. A list of Musical Symbols in "Deliverables"?

"It does seem to me that a list of symbols and semantics, perhaps partly by
reference to existing works, would be an extremely valuable foundation for
standards that are trying to use those symbols and semantics" - I agree
that such a document would be useful if it already existed, but it sounds
like an enormous undertaking would be required to produce this document
(i.e. a greater amount of effort would be required than would be needed for
MNX or SMuFL).

"If the character exists, but the semantics are not well-defined, it leads
to use of the existing character for the omitted semantic, instead of
defining a new character (with the same shape) for the omitted semantic." -
This is a valid point, but again, I think it is too ambitious to try to
document every single use case of a symbol before releasing the standard.

MusicXML, MNX, and SMuFL are evolving standards, and they expand as new use
cases are discovered. That being said, I think all three standards provide
a solid foundation, and MNX starting from a clean slate, can learn from
previous semantic issues in other music encodings. MusicXML does have a
history of ambiguity in semantics, but I think MusicXML 3.0 and 3.1 really
clean up the issue, and newer versions of MusicXML are always backward
compatible to earlier versions through the use of XSLTs which are included
with every version of MusicXML.



On Mon, Jul 3, 2017 at 3:12 PM, Glenn Linderman <v+smufl@g.nevcal.com>
wrote:

> The list sounds extremely useful, though. I too have found other lists of
> notation incomplete.
>
> SMuFL documentation does include names of many symbols (but in particular
> doesn't mention volta brackets, I was surprised at its omission in the past
> and wrote something about it somewhere in one of these mailing lists), and
> together with the Bravura font including the samples of what they look
> like, it is very inclusive, but not yet all inclusive.
>
> SMuFL does distinguish semantic differences of various symbols that look
> the same by giving them different names and codes. In at least these cases,
> it would be appropriate to define exactly what those semantic differences
> are; it would also be useful to have a cross-reference of symbols that look
> the same but are used with different semantics.
>
> It does seem to me that a list of symbols and semantics, perhaps partly by
> reference to existing works, would be an extremely valuable foundation for
> standards that are trying to use those symbols and semantics in
> meaningfully interchangeable formats. If there is a semantic use of a
> character that is inadvertently omitted from SMuFL, it is much easier to
> discern that if the semantic use of each SMuFL codepoint is documented. If
> the character exists, but the semantics are not well-defined, it leads to
> use of the existing character for the omitted semantic, instead of defining
> a new character (with the same shape) for the omitted semantic.
>
> I don't know what to say about English versus German versus other
> languages. Only English is directly useful to me, unfortunately, although I
> do work with multi-lingual people on multi-lingual projects, but those
> people must know some English to communicate with me. How broadly
> international standards are translated into languages other than English is
> unknown to me, but I have no issues with them being translated. I guess I
> don't see a particular benefit to translating only a fraction of such a
> document, the symbol names, without translating the rest of the document as
> well.
>
> On 7/3/2017 11:52 AM, Jeremy Sawruk wrote:
>
>> Hi Mogens,
>> I'm sorry, but I don't think such a document should be a deliverable of
>> the group for the following reasons:
>> - I think it is too open ended and broad in scope. Group members could
>> end up spending a lot of time on this when they should be focused on
>> developing our core deliverables (such as MNX standards etc.)
>>
>> - A lot of this is already covered in the SMuFL documentation. I find the
>> SMuFL documentation to be one of the most comprehensive list of musical
>> symbols. To your point, however, it is not related to MusicXML or MNX, and
>> I don't think it should be. I think it is important to keep SMuFL separate
>> from MusicXML/MNX, as it can be used in other contexts (just like Unicode
>> can be used outside of HTML).
>>
>> - I don't understand why you would want the symbol names in just English
>> and German. Music is an international language, so this decision seems
>> arbitrary.
>>
>> If you wish to pursue such a project on your own, then others in the
>> group (and elsewhere) may find this information useful. Unfortunately, I
>> feel that it detracts from the primary focus of the group.
>>
>> J. Sawruk
>>
>> On Mon, Jul 3, 2017 at 2:26 PM, mogens@lundholm.org <mailto:
>> mogens@lundholm.org> <mogens@lundholm.org <mailto:mogens@lundholm.org>>
>> wrote:
>>
>>     Thanks.
>>
>>     Another consideration: I think that the section ”Deliverables” should
>> have a document ”List of musical symbols”. Several such documents are on
>> the net but they are all incomplete and not exact in the description. And
>> not related to MusicXML/MNX.
>>
>>     Then for every symbol the corresponding MusicXML and MNX keyword
>> should also be noted. Also it would be good to have the symbol name in both
>> German and English. (The German word would normally be the same as in
>> Danish, Swedish, Norwegian etc.). Maybe also the references to SMuFL could
>> be included.
>>
>>     Examples of how a description should be like:
>>     1. Repeats: A Repeat Start shall save current repeat position and
>> repeat number. And set current repeat number to one.
>>
>>     2. Repeats: A Repeat End shall set the current position back to
>> repeat position and restore the saved repeat position and repeat number.
>> (image and translation ...)
>>
>>     3. Volta brackets (endings): A Closed Volta bracket shall be played
>> if the current repeat number is equal to the volta number.
>>     (image and translation ...)
>>
>>     4. Volta brackets (endings): An Open Volta shall be entered if the
>> current repeat number is equal to the volta number. The repeat number shall
>> be set to one. A repeat inside a volta must appear after the keyword for
>> volta (<ending …>). ...
>>     (image and translation ... )
>>
>>     This document would also be a link between the other documents. With
>> a proper tool missing links could be identified.
>>     Would this List of Musical Symbols be a good idea?
>>
>>     /Mogens
>>
>>     On 2017-06-24 12:41, Daniel Spreadbury wrote:
>>
>>>     CG does indeed stand for Community Group, but CLA stands for
>>>     Contributor License Agreement. See here:
>>>
>>>     https://www.w3.org/community/about/agreements/cla/
>>>     <https://www.w3.org/community/about/agreements/cla/>
>>>
>>>     Daniel
>>>
>>>
>>
>
>