Agenda Discussion

From Music Notation Community Group
Jump to: navigation, search

This document summarizes and collates the feedback on the W3C Music Notation Community Group’s discussion on the group’s initial agenda from September and October 2015. Recommendations in this document are those of the individual contributor.

Consideration of the MEI format

Overall Framing

  • We would like to see MusicXML 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. [CA]
  • Will this W3C group will be the ground where the commercial and academic communities compare their notes, and establish a common language? [ZK]

Characteristics of MEI

  • MEI is more of a framework than a standard (e.g. there are four ways to encode beams, all of which operate at different levels of complexity). [JK]
  • MEI requires the encoder to construct a customization, or profile, using TEI's ODD language, which defines MEI in a modular way. [JK]
  • MEI is as interested in describing the manual additions and corrections made by the composer as it is in describing the page of music produced by the engraver. [JK]
  • Limited software support for MEI has been beneficial at times, allowing more easy reconsideration of existing design decisions without worrying about breaking compatibility. [JK]
  • MEI is well-suited to being partnered with digital facsimiles. [JK]
  • MEI is both rich and semantically well-structured, and only such a model can facilitate truly rich user experiences. [ZK, SW]

Strengths for MusicXML

  • More lightweight than MEI [BH]
  • Smaller in scope and thus easier to improve more quickly [BH]
  • MusicXML has been tremendously successful as a "first good enough" digital score representation for widespread use. [LPD]

Weaknesses for MusicXML

  • MusicXML is tied to MIDI, meaning such basic characteristics as duration are difficult for beginners to understand. [CA]
  • MusicXML assumes a unitary rather than manifold model of a musical work, making functions such as version control and collaboration cumbersome or impractical. [CA]
  • MusicXML was designed as an interchange format and does not encode all document information required by a fully-featured music notation system. [CA]
  • MusicXML is restricted to common Western music notation, limiting its capabilities for new notation styles, non-Western styles, and unconventional uses. [CA, SW]
  • Addressing the semantic issue is critical - if people want to start using very large repositories of music xml in applications it’s critical that the specification pushes for things to encoded in a common way [JG]

Strengths for MEI

  • MEI provides a comprehensive and consistent model of music notation, unencumbered by legacy of MIDI, MuseData, or requirements for interchange between existing applications. [CA]
  • MEI has explicit facilities for addressing the manifold nature of musical works. [CA]
  • MEI is extensible by design, and allows for modules for specific kinds of notation (such as neumatic and mensural notation). [CA]
  • MEI encodes musical metadata (e.g. FRBR records) in a standard way. [CA]

Weaknesses for MEI

  • Requirement to learn TEI ODD, understand which modules should be used, choose between different possible approaches to encoding, make MEI difficult for beginners. [AHn, JK]
  • MEI has limited existing software support. [AHn]
  • MEI tries to cover both comprehensive description of an existing source and prescribe how a renderer should lay out a digital score, but a single encoding normally takes one or the other approach, as they may conflict. [JK]

Learning from MEI

  • MEI's modular approach would allow the development of a "simplified" MEI customization, which could take away both the ambiguity in the model and the editorial/transcriptional additions, cf. TEI Lite. Perhaps the development of such a simplified MEI could lead to an encoding standard built on and implementing the best of both MusicXML and MEI? [JK]

Is XML the right expression for the format, or would JSON be better?

  • XML is a precise form of expression, and it is somewhat human readable, which are both useful characteristics. However, it seems unlikely from what has been said that either form of XML will be directly displayable by web browsers, as is, say HTML (which is not quite XML), or SVG. XML also required an extra layer of parsing to obtain something useful to Javascript. [GL]
  • The advantages of XML are that you get a lot of things “for free,” including validation, schema tools, and iron-clad software parsers in almost every language. [AHn]
  • JSON is web-friendly and also has iron-clad parsers, though schema support is currently more limited. [GL]
  • Should a goal for the project be that the format is sufficiently expressive that it can be transformed into a display format such as SVG by way of a transformation such as XSLT? [GL]
  • JSON can easily be stored in databases like MongoDB and works well with frameworks such as AngularJS. Having it in a database allows efficient aggregations on the data. [JG]

What about W3C ontologies and RDF?

  • Should there be discussion about creating a standard of music which uses RDF/Ontology-based definitions for musical notation? JM has started some work in this area, but has yet to complete it. [JM]

What about IEEE 1599?

  • IEEE Technical Committee on Computer released an XML standard, IEEE 1599, specifically conceived to meet the requirement of working with music notation on the web. For more information:
  • IEEE 1599 is not designed as an alternative to MusicXML or MEI or any other format; rather it is intended to integrate already existing formats. This has been done already for graphics and audio files, but it could be done with notation, too. A syntax to identify musical symbols through a shared ID within the encoding would be required to link different representations (audio, graphical, semantic, etc.) if required. [LL]

Suitability for describing extended, graphical, etc. notation

  • Consider looking at sources like Notations 21 or the samples here for examples of notation that are difficult to represent with MusicXML as it stands. [DBK]
  • MusicXML could make it easier to represent things like nested irrational rhythms, provide more granular microtonal semantics. [JM]
  • MusicXML should also provide a more standardised approach to infomatic metadata in order to relate it to other digital resources. [JM]
  • Is MusicXML adequate to describe music used in an application that combines sheet music with audio files, video, chord sheets, piano rolls, lyrics written as plain text etc.? [ER]

Importance of a specification

  • Work on a specification should not only document the status quo, but also create something where one can later pick up where one left off. [TW]
  • Work on a specification should not inhibit an unbiased discussion of the best starting point for an open notation standard, nor should it inhibit adoption of the results of these discussions into a new specification. [TW]
  • There is a lot of work required to turn the current standard into something robust enough not to need the sample files which are necessary currently. [JS]
  • Remove (or complement) all references to other formats (MuseData, MIDI) for explaining the purpose/use of an element. so that any MusicXML user is not forced to study other music representation systems to understand MusicXML. [CS]
  • Add examples of use, and recommended ways of encoding things. [CS]
  • Also add examples and use cases for those elements or constructs that can be difficult to understand. [CS]
  • A high-quality standard must provide a mechanically executable, unambiguous test for both syntactic and semantic conformance that consumers can and should implement. It must define the meaning of every construct that passes these two tests. [LPD]
  • The specification must define, for every construct that uses start...stop tags, exactly what the constraints are on what elements can participate in the construct and must require semantic well-formedness. [LPD]
  • All existing versions of MusicXML have issues so significant that no effort should be devoted to trying to write specifications for them, even in the short term. [LPD]

Should backwards compatibility be retained?

  • Drop backwards compatibility to fix legacy problems, but also provide XSLT-schemes or other software solutions to migrate from "old" to "new" MusicXML. [BH]
  • Redundant parts that are never used should be removed, which would by necessity break backwards-compatibility. [JS]
  • Deprecate the procedural elements <backup> / <forward> for defining voices content, in favor of a declarative "partwise" definition of voices. [CS]
  • Advocate strongly that our efforts be directed first to updating MusicXML into a design that does have the potential of meeting the criteria for a high quality standard / specification. [LPD]
  • Writing a fully automatic converter from all existing MusicXML formats to the new one, done in parallel with the design discussion, should greatly increase the chances of identifying omissions and unclarities in the existing designs. [LPD]

High priority areas for improvement in MusicXML

  • Remove backup/forward, in favour of a declarative part-wise definition of voices. [BH, CS, JS, CC]
  • Improve semantic richness, e.g. and perhaps especially for text; if semantic tags are provided, engravers will learn to use them. [BH, JS, AHy]
  • Investigate CSS-like techniques for separating content from presentation [BH]
  • Cleanup of MusicXML exported from some arbitrary source is generally required to reduce it to a predictable and consistent set of constructs [JG]
  • The most serious issue is the relationship between flowed-location and fixed-location constructs, which manifests the tension between a semantic format like HTML and a concrete format like PDF. Fixing this problem in MusicXML will require a concerted redesign to clearly separate flowed and fixed material. [LPD]
  • Nearly as serious as the mismatch of flowed and fixed elements are the two constructs that create friction between file text order and time sequence: <chord/> and <backup>/<forward>. [LPD]
  • The obvious fix for <chord/> is to replace this element with a <chord> element at the measure level whose children are the notes of the chord, and to consider carefully which of the current attributes and elements of notes should be associated only with chords, only with notes, or (in as few cases as possible) with either. [LPD]
  • Removing backup/forward requires finding another way to deal with multiple time flows (not just voices) within a part. A good simple approach would be to require every note, chord, rest, slur start/end, cresc/dim start/end, etc. to specify an explicit starting time within the measure, subject to a constraint that time cannot flow backward. [LPD]
  • There are a large number of different contexts in which text and/or symbol strings can appear in MusicXML files, and each one of them has different restrictions on what attributes can appear with the strings. [LPD]

How do we ensure software vendors will come along?

  • "Enforcing" the standard is just as important as creating it. In my experience, the primary pain of dealing with MusicXML is that each vendor (Sibelius, Finale, MuseScore, Notion) generates it differently, leading to inconsistency. [AHy, CC, CS]
  • Make it crystal clear where to report vendor-specific MusicXML-related bugs. [AHy]
  • A tool like the MusicXML Sanitizer should be a free, open-source tool. [AHy]
  • Will require some marketing towards the vendors of the major score-editing tools to encourage them to improve export [BH]
  • Have a redesign be the responsibility of a committee that includes four software developers who have implemented MusicXML import and export functions for score applications, including one from Finale, one from Sibelius, and two independent of either company/product, along with a person tasked with writing a fully automatic converter, and a person with extensive experience reading and writing high-quality specifications and standards. [LPD]
  • Change as little else as possible in a structural redesign to reduce the effort of creating updated importers and exporters. [LPD]
  • The standard must not be bent to cater to implementation bugs. [LPD]
  • Some degree of vigilance, and an independent effort to monitor producer implementation quality, are needed to keep increasingly sloppy producer implementations from gaining ground. [LPD]

How do we ensure human encoders do the right thing?

  • How can we ensure human engravers (and other users of notation software) input their notation in the most semantic way possible, so that our efforts to improve MusicXML will actually be worthwhile? [AHy]
  • MusicXML will only know something is presentational if a notation editor makes the distinction in the first place. Does the notation editor encourage you to do things the right way, or is it easy to "hack" things? In my experience, human engravers prioritize print layout instead of semantics, which leads to subpar MusicXML data. [AHy]
  • Fixing the user interface of score creators is beyond the scope of this discussion. [LPD]


  • AHn = Andrew Hankinson
  • AHy = Adrian Holovaty
  • BH = Bob Hamblok
  • CA = Christopher Antila
  • CC = Christina Cotruvo
  • CS = Cecilio Salmeron
  • DBK = Dennis Bathory-Kitsz
  • ER = Erik Ronström
  • GL = Glenn Linderman
  • JK = Johannes Kepper
  • JM = Joshan Mahmud
  • JS = James Sutton
  • LL = Luca Ludovico
  • LPD = L. Peter Deutsch
  • SW = Sienna Wood
  • TW = Thomas Weber
  • ZK = Zoltan Komives