Re: Getting Off The Ground

Dear Co-Chairs and Community:

Thank you for your welcoming and exciting introduction! Please find our 
comments below.


On 2015/09/17 10:28, Joe Berkovitz wrote:
> 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.
> 
> Now, we’re 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’s also an opportunity to
> ask the membership to supply thoughts on a number of points where your
> input will be very helpful.
> 
> SO... NOW WHAT?
> 
> Let’s begin by reviewing some of the main areas in which we hope
> this CG can make progress. Of course we can’t do everything at once,
> although we can pursue some limited set of goals in parallel. We’ve
> 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.
> 
> SHORT TERM PROJECTS
> 
> Build an initial MusicXML specification. 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.
> 
> Add support for use of SMuFL glyphs within MusicXML. 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.
> “use this SMuFL notehead for this note”). 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.
> 
> Identify and fix any remaining gaps or adoption barriers in SMuFL. 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.
> 
> Document music notation use cases. We need to begin to develop a
> separate document that covers and prioritizes the use cases that the
> CG’s work will support, to aid in evaluating the many alternative
> proposals and solutions that will come up.
> 
> LONGER TERM PROJECTS
> 
> Improving formatting support in MusicXML. 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?
> 
> Build a complete MusicXML specification document. A long-standing
> MusicXML community request has been  to 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.
> 
> Adding Document Object Model (DOM) manipulation and interactivity to
> MusicXML. 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  require a more structural solution such as
> revisiting the MusicXML element hierarchy?
> 
> WHAT’S NEXT?
> 
> This is where the co-chairs can use your help. We’d like to ask you
> to answer the following questions:
> 
> - Are these the right major goals? What’s missing? What should go?
> 
> - Are we picking the correct short-term projects to start with?
> 
> - Have we defined the short-term projects properly?
> 
> - What would you most like to see done with MusicXML right away?
> 
> - What would you most like to see done with SMuFL right away?
> 
> At this point we are looking for input from the membership. It’s
> tempting to indulge in a wide-ranging debate, but at this stage it’s
> going to be difficult to reach a conclusion through a large email
> discussion. So we want to begin by hearing people’s thoughts. Please
> send your thoughts to this list at
> public-music-notation-contrib@w3.org.
> 
> Thank you again for your interest in the Music Notation Community
> Group. We are looking forward to hearing your thoughts as to how you
> would like the group to proceed.


- Are these the right major goals? What’s missing? What should go?

Regarding MusicXML-related goals:

As the name of the group is the “Music Notation Community Group,” not 
the “MusicXML Community group,” we should question together whether 
MusicXML is the most appropriate foundation for a web-friendly standard 
for music notation.

We acknowledge the influence and benefits that MusicXML has brought to 
the music notation community as a common language shared between 
applications. Furthermore, we endorse the format’s continued 
development, and we are very pleased to see it taking place in an open 
and transparent way. We question, however, whether or not MusicXML is 
the right basis for a web-friendly music notation standard.

Given the diversity of music documents and their applications -- for 
composition, online critical editions, arrangement, music pedagogy, etc. 
-- we find that MusicXML falls short in several fundamental ways:

1.) MusicXML is tied to the MIDI standard in a historically accidental 
and cumbersome way, meaning such basic characteristics as duration are 
difficult for beginners to understand.
2.) MusicXML assumes a unitary rather than manifold model of a musical 
work, which makes basic online functionalities such as version control 
and collaboration cumbersome or impossible. Such a unitary model also 
prohibits creation of online scholarly editions that correlate multiple 
sketched versions of the same musical ideas or passages.
3.) MusicXML was designed as an interchange format between music 
applications and, by design, does not encode all document information 
required by a fully-featured music notation system. The goal of the 
group, as we understand it, is to choose an online representation 
standard for music documents.
4.) MusicXML is restricted to musical documents expressed as common 
music notation, or a small set of alternatives. This limits the format’s 
capabilities for new notation styles, for non-Western styles, and for 
unconventional uses.

Considering the aforementioned disadvantages, we note the following 
characteristics of the Music Encoding Initiative’s XML-based encoding 
format (MEI):

1.) MEI provides a comprehensive and consistent model of musical 
notation, unencumbered by legacy applications and MIDI compatibility.
2.) MEI is suitable for scholarly applications, as it provides explicit 
facilities for addressing the manifold nature of musical works, allowing 
for all manner of variants and alternatives.
3.) MEI is developed by an existing community with years of experience.
4.) MEI was developed as an extensible format from the start, and 
community members are actively working on extensions for niche 
communities that would be nearly impossible to incorporate in MusicXML 
(neumatic and mensural notation are already standardized). New and 
alternative types of musical documents and encodings could be 
incorporated over time, much as HTML5 is gradually being amended.
5.) MEI has also been used to encode characteristics of musical 
documents, musical metadata, for use in specialist databases and 
libraries. In this way, MEI provides not only a means of encoding 
notation, but of all musical data, no matter the culture or medium of 
initial creation.
6.) MEI has been developed as a free and open standard from the start.

We recognize that MEI is not a ready-to-go, ideal solution for all 
web-based music notation needs. In particular, MEI does not currently 
support a stylesheet-like separation between “content” and “appearance,” 
which is one of the most important lessons to be learned from HTML and 
CSS. In spite of this, it is our strong conviction that MEI is a more 
suitable base upon which to develop such a web-friendly format.

Regarding SMuFL goals:

Based on work presented at TENOR2015, we find the goal to support SMuFL 
much more convincing, as this will enable a flexible and extensible font 
standard to be developed as part of a web standard for music notation.

- Are we picking the correct short-term projects to start with?

The articulated short-term projects sound perfectly reasonable for the 
next six months; it’s clear that these would benefit MusicXML developers 
and, indirectly, music software developers as a whole.

- Have we defined the short-term projects properly?

We agree that it is wise to identify common difficulties faced by 
developers who use MusicXML and to work toward a MusicXML version that 
eliminates these problems. The community should also generalize this 
conversation to problems with all existing music representation systems. 
It is these problems, that plague multiple existing systems, that will 
allow a new standard to have a maximally beneficial impact.

- What would you most like to see done with MusicXML right away?

We would like to see it considered alongside other viable encoding 
schemes as the basis of a future standard that learns from the lessons 
of all schemes. This implies consideration beyond MusicXML and MEI.

- What would you most like to see done with SMuFL right away?

We would like to see SMuFL become a well-integrated component of the 
standard our community develops.

We’re pleased that our group’s co-chairs solicited the input of the 
entire group on these matters. Furthermore, we’re excited to work with 
the community in the future, regardless of the path forward chosen as a 
result of our conversation together.


Cheers,
Christopher Antila, nCoda
Jeff Treviño, nCoda

Received on Friday, 18 September 2015 08:15:31 UTC