Re: Proposed CG agenda changes

James wrote:

> I don't think I have seen any justification for linking SMuFL and 
> MusicXML. Did I miss something here?
> 
> Would such a link between the specifications mean that in some way 
> an application had to use a smufl-numbered font internally in order 
> to be MusicXML compliant? How would this help anybody? How would you
> even tell without access to the source code?

You can read the specific details of the proposed initial integration of 
SMuFL with MusicXML by perusing the list of issues tagged both "SMuFL" and 
"V3.1" in GitHub, here:

https://github.com/w3c/musicxml/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Asmufl+label%3AV3.1

The idea is not to make MusicXML explicitly depend on SMuFL fonts. Rather, 
it's to allow a richer semantic representation of a handful of elements, 
typically by the use of the existing "other..." elements (e.g. 
other-accidental within accidental, other-articulation within 
articulations, etc.). This is intended to help keep the interchange 
capabilities of MusicXML high as applications begin to support SMuFL more 
readily (e.g. Finale, our 

In the longer term, there are things that could be adopted from SMuFL to 
help with things like clarifying the meaning of positioning attributes, 
but those are explicitly out of scope for the proposed MusicXML 3.1 
update.

Daniel

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany
Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net
President: Andreas Stelling | Managing Director: Hiroshi Sasaki, Hirofumi Osawa
Registration Court: Hamburg HRB 86534
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -