{"id":14,"date":"2015-09-17T14:21:57","date_gmt":"2015-09-17T14:21:57","guid":{"rendered":"https:\/\/www.w3.org\/community\/music-notation\/?p=14"},"modified":"2015-09-17T14:21:57","modified_gmt":"2015-09-17T14:21:57","slug":"getting-off-the-ground","status":"publish","type":"post","link":"https:\/\/www.w3.org\/community\/music-notation\/2015\/09\/17\/getting-off-the-ground\/","title":{"rendered":"Getting Off The Ground"},"content":{"rendered":"

Hi Group Members,<\/span><\/p>\n

Thanks for your patience during the Northern-summer vacation season as things slowed down and many were out of town and offline. Even so, many new members and organizations continued to join the Music Notation CG, bringing the total count to an impressive 191.<\/p>\n

Now, we\u2019re finally at the point of getting started and actually doing something. With this post, the co-chairs hope to set a rough agenda for lots of good work to come. It\u2019s also an opportunity to ask the membership to supply thoughts on a number of points where your input will be very helpful.<\/span><\/p>\n

SO… NOW WHAT?<\/strong><\/p>\n

Let\u2019s begin by reviewing some of the main areas in which we hope this CG can make progress. Of course we can\u2019t do everything at once, although we can pursue some limited set of goals in parallel. We\u2019ve broken these up into short-term projects that we think can be completed in the coming 6 to 12 months, and longer-term projects that can begin to be addressed in parallel with the short-term work, perhaps by separate subgroups within the CG.<\/span><\/p>\n

SHORT TERM PROJECTS<\/strong><\/p>\n

Build an initial MusicXML specification.<\/b> The aim of this initial document is tactical in nature: it needs to resolve the most significant ambiguities and gaps faced by developers working with the current version of MusicXML. It should also provide a framework for later, more complete specifications, and can serve as a version-controlled container for new MusicXML features going forward. This initial spec will be incomplete by design, though, and will still coexist\/overlap with the current XSD documentation.<\/span><\/p>\n

Add support for use of SMuFL glyphs within MusicXML.<\/b> MusicXML needs to include some new constructs and documentation that allow SMuFL glyphs to be employed usefully. The symbolic vocabulary of MusicXML must grow to support some new SMuFL notations. MusicXML must also be able to specify the use of SMuFL glyphs in already-supported notations (e.g. \u201cuse this SMuFL notehead for this note\u201d). More fundamentally, MusicXML must define the manner in which SMuFL glyphs are joined to each other and registered with respect to relative or default X\/Y locations.<\/span><\/p>\n

Identify and fix any remaining gaps or adoption barriers in SMuFL.<\/b> We are at a point in this venture at which any serious problems or barriers to adoption need to be identified and fixed in SMuFL. It will be hard or impossible to fix such problems later.<\/span><\/p>\n

Document music notation use cases.<\/b> We need to begin to develop a separate document that covers and prioritizes the use cases that the CG\u2019s work will support, to aid in evaluating the many alternative proposals and solutions that will come up.<\/span><\/p>\n

LONGER TERM PROJECTS<\/strong><\/p>\n

Improving formatting support in MusicXML.<\/b> MusicXML 3.0 formatting cannot easily be shared between documents. Nor can it distinguish formatting that clarifies semantics, such as for collision avoidance, from formatting that is more a matter of house style, such as font choices and spacing preferences. Could CSS stylesheets help solve these issues and provide more powerful formatting support for a wider variety of use cases? <\/span><\/p>\n

Build a complete MusicXML specification document.<\/b> A long-standing MusicXML community request has been \u00a0to build a complete specification. This would replace the XML Schema as a specification and address holistic or cross-cutting matters that do not belong to any single schema component.<\/p>\n

<\/b>Adding Document Object Model (DOM) manipulation and interactivity to MusicXML. <\/b>What would it take to be able to create interactive music applications on top of any standard MusicXML rendering engine? MusicXML was not designed with DOM interactivity in mind. Is the current document structure sufficient, perhaps with some minor adjustments? Or does the use of a time cursor that can move forward and backward, combined with the current structure, inhibit DOM interactivity? Would this \u00a0require a more structural solution such as revisiting the MusicXML element hierarchy? <\/span><\/p>\n

WHAT\u2019S NEXT?<\/strong><\/p>\n

This is where the co-chairs can use your help. We\u2019d like to ask you to answer the following questions:<\/span><\/p>\n