Re: Introducing MNX

Hi Peter, All,

Your comments on automatic validation, semantic completeness and clarity
prompts me to give an update about recent developments in the MEI
community. Last week, at the Music Encoding Conference in Montreal, Tido's
recently published MEI customization
<http://tido.github.io/mei-customization/> sparked a lively discussion
about an issue the MEI community has been considering for some time: the
development of a simple MEI customization (currently under the working name
MEI Go!) to enable better data exchange through limited and well-defined
scope, constructs and semantics.

One of the perceived shortcomings of MEI in the past may have been its size
and complexity, and a sense that it was more suited to academic than
commercial application. Even though there is a legitimate difference
between academic and commercial use cases, the requirements for software
development are very similar in both environments: focused scope and well
defined specifications. One of the aims of MEI Go! is to address this
issue, and to make the framework accessible for application development,
regardless of the target market of the application. By doing this, we
believe that it may be a bridge between the academic and commercial
encoding communities.

For more information on MEI Go! please keep an eye on the MEI-L mailing list
 for updates
<https://lists.uni-paderborn.de/pipermail/mei-l/2016/001796.html> and
discussions. While it may not be the solution that the Community Group is
looking for, I would like to draw attention to this effort as point of
reference.

Zoltan Komives

On Sun, May 22, 2016 at 3:53 PM, L Peter Deutsch <lpd@major2nd.com> wrote:

> > However, the whole point of creating a new standard is to enable
> > standards-oriented application programming (i.e. the writing of *new*
> > software). ... I'm worried that the Chair might be trying to limit the
> > scope of this project to CWMN (as defined by MusicXML). That would be
> > counter-productive and, as far as I'm concerned, defeat the whole
> purpose of
> > creating a new standard.
>
> I have a very large related concern that I have expressed to the committee
> in the past and that James Ingram's comment leads me to think may not be
> receiving proper attention.
>
> In my opinion, MusicXML is not and (while remaining reasonably backward
> compatible with its present definition) cannot be the basis of a successful
> standard, because it is not defined, and in my opinion is very unlikely to
> definable (in a reasonably backward compatible form), in a way that meets
> the basic criteria for a standard -- full mechanical checkability, with
> semantic completeness and clarity.
>
> There are at least four major problems with the current MusicXML
> definition,
> three of which I do not see how to fix with reasonable effort, especially
> if
> (near-) backward compatibility is a goal.
>
> * The definition contains many constructs that are under-specified
>   syntactically.  Among the most serious are the many "start/stop"
>   constructs, which are unclear not only in their relationship to parts,
>   voices, etc., but which do not clearly state that a failure to observe
> the
>   ordering of their instances is a violation of the standard that need not
>   be tolerated by consuming software.
>
> * The definition contains many constructs that are under-specified and/or
>   under-constrained semantically, especially with respect to how they
>   interact with each other.  For example, it is unclear for the "chord"
>   construct what elements can intervene between the notes of a chord, what
>   attributes of an individual note carry over to following notes or the
>   entire chord, etc.  By far the worst of these are the "backup/forward"
>   constructs, which interact with nearly every other construct because they
>   break the otherwise implied association between file order and
>   graphical/temporal order.
>
> * The definition, unlike the native formats of *all* score editor software
>   known to me, cannot express page formatting information (other than
>   margins and spacing) that is to be carried over throughout the score,
> such
>   as page numbering, or that adapts to different page sizes -- it can only
>   represent the formatting of individual pages, and only using absolute
>   coordinates on the page.  This alone makes it unsuitable as a score
>   interchange format.
>
> * What the "selective encoding" philosophy has meant in practice is that
>   errors and omissions in producer software (e.g., Sibelius's mis-handling
>   of accidentals), and discarding of important information by consumer
>   software (e.g., Finale's discarding of margin and indentation
> information)
>   are not considered objectionable.  As a result, every application writer
>   has to wrestle with omissions and peculiarities in the output produced by
>   other applications.  Fixing this requires not only a real definition of
>   the language that can be used to validate files automatically, but a
>   mindset consistent with all other file standards, which at the very least
>   will consider publicizing reported issues in major implementations with
>   the intent of shaming the developers into fixing them.
>
> The originator of MusicXML has stated that he does not think it is possible
> to create what would I would consider a true standard for either the
> MusicXML language or for any language with its goals, because "music is so
> different from other notations and there are too many interacting elements
> to specify how they should interact with each other."  As a software
> developer, standards reviewer, and practicing composer, I believe strongly
> that this statement is simply wrong; but if we try to patch MusicXML, we
> will certainly not find out.
>
> L Peter Deutsch
>

-- 
www.tido-music.com

Tido (UK) Ltd, 2–6 Baches Street, London N1 6DN, United Kingdom. 
Disclaimer: The information in this e-mail including any attachments is 
confidential and may be legally privileged. If you have received this 
message in error, please contact the sender immediately and delete this 
message and any copies from your computer and network. The unauthorized 
use, distribution, copying or alteration of this e-mail and any attachments 
is strictly forbidden.