Re: Proposed CG agenda changes

> Add support for use of SMuFL glyphs within MusicXML

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?

James Sutton
Dolphin Computing
http://www.dolphin-com.co.uk



> On 9 Nov 2015, at 16:46, Michael Good <mgood@makemusic.com> wrote:
> 
> Thanks to everyone for your thoughtful discussion of the agenda for the Music Notation Community Group. We have posted a summary of the discussion on the CG Wiki at https://www.w3.org/community/music-notation/wiki/Agenda_Discussion. In this post, the co-chairs would like to bring this discussion back to its effect on the short-term and long-term agenda of the group.
> 
> Our initial proposal for an agenda contained four short-term and three long-term projects:
> 
> Short Term:
> 
>  - Document music notation use cases
>  - Build an initial MusicXML specification
>  - Add support for use of SMuFL glyphs within MusicXML
>  - Identify and fix any remaining gaps or adoption barriers in SMuFL
> 
> Long Term:
> 
>  - Improve formatting support in MusicXML
>  - Build a complete MusicXML specification document
>  - Add Document Object Model (DOM) manipulation and interactivity to MusicXML.
> 
> Looking at the discussion, we saw a clear emphasis on the need for use cases, as well as the need to address foundational and structural issues in MusicXML. After reviewing all the responses, the co-chairs agree that these two areas deserve top priority, and that it makes sense to treat them sequentially. First we should focus on developing, refining and filtering a set of use cases for our notation format. After we have adopted a solid set of use cases, we can then turn to the foundational/structural issues in the standard with a much better shared understanding of our goals.
> 
> We believe document format discussions are best driven by use cases, expressed in terms of the needs and actions of different classes of users, as well as the nature and contents of the documents involved. Many of the discussions so far have been framed in terms of technology choices like MusicXML vs. MEI, XML vs. JSON, or IEEE 1599 vs. SMIL. We would like to begin re-framing these discussions to clearly identify user needs and document contents served by specific features in these technologies, rather than on whether we should pick technology A vs. technology B. Eventually we can shift to finding technical solutions that satisfy the use cases we deem worth addressing, in the context of this group’s charter.
> 
> Building an initial MusicXML specification met with some thoughtful push back. Peter Deutsch proposed that the specification effort should wait until the format is redesigned in some key areas to be more easily specifiable. Others mentioned that it may not be wise to do short-term work that would then need to be redone based on long-term goals.
> 
> People asked what adding support for use of SMuFL glyphs within MusicXML meant, and why a font standard influences a music representation standard. Our feeling is that there is an immediate practical need to add more musical symbols to the MusicXML format. A MusicXML update that includes greater support SMuFL’s expanded vocabulary of musical symbols will keep interoperability between applications high. We believe that this can be done with little risk of future rework based on long-term goals.
> 
> Identifying and fixing any remaining gaps or adoption barriers in SMuFL did not receive much feedback. There appears to be a feeling that the existing specification is in good shape, and mostly in need of incremental improvements in symbol coverage.
> 
> We therefore propose our short-term work cover three main areas:
> 
>  - Document the use cases for music notation formats in a way that can help drive decisions about the structural and conceptual changes needed in the standard.
> 
>  - Create a very focused, short-term MusicXML 3.1 update that addresses the need for broadening MusicXML’s symbol vocabulary and fixes some documentation bugs. This update will avoid any areas that are likely to be redone if structural changes are made in the future. We already have an initial take on what would be included in a MusicXML 3.1 update on Github at https://github.com/w3c/musicxml/labels/V3.1.
> 
>  - Produce incremental SMuFL updates as needed for enhanced symbol coverage.
> 
> We propose that these three items proceed in parallel. Joe will lead the use case documentation, Michael will lead the MusicXML 3.1 update, and Daniel will lead the SMuFL updates. We anticipate that the use case work will receive most of the group’s focus.
> 
> Our plan is for the co-chairs to put together an initial use case draft on the community group Wiki to illustrate what exactly we are thinking of when we talk about use cases. We plan to get that out within the next week or two.
> 
> Please let us know your thoughts on this proposed agenda update on the public-music-notation-contrib mailing list.
> 
> Michael, Joe, and Daniel
> 
> 
>

Received on Thursday, 12 November 2015 09:51:40 UTC