Re: Proposed CG agenda changes

>  Build an initial MusicXML specification

Much of my "pushback" was based on my perception of large past differences
of opinion between myself and Michael Good as to what constitutes a
"specification" (and what constitutes an acceptable level of conformance to
one).  Is it intended that this initial specification of MusicXML 3.1 meet
the criteria in my earlier posting, repeated below?  Or will something less
be considered acceptable?

      * It must provide a mechanically executable, unambiguous test for
syntactic conformance that consumers can and should implement.

      * It must provide a mechanically checkable, unambiguous test for
semantic conformance that consumers can and should implement.  This
includes not only type and range specifications for all individual data
items, but clear validity criteria for all relationships between items and
structures.

      * It must define the *meaning* of every construct that passes the  
above
two tests.  If a construct does not have visual or semantic meaning, such
as a line with only one end, it must not be allowed.

      * It must not be bent to cater to implementation bugs.  However,
non-conformances in leading implementations should be documented in an
annex, to help embarrass implementors into fixing them.

While I am not thrilled at the prospect of an effort to create a
high-quality specification for a design whose subsequently repairable
defects are likely to create significant additional work in that effort, I
would be extremely disappointed if a decision were made to settle for
something less.  I believe specifying MusicXML 3.1 thoroughly will provide
invaluable experience in identifying areas for improvement, complementing
the investigation of use cases.

      L Peter Deutsch

Received on Monday, 9 November 2015 21:06:17 UTC