Re: MNX Proposal now Available [via Music Notation Community Group]

Hi all,

Let me attempt to clear up the confusion that seems to be growing here.

The co-chairs are very firmly decided that the current *focus* (not scope!)
of the group is on supporting a semantic encoding for CWMN. This is the
main topic for Frankfurt and the area to which the MNX proposal has devoted
the most effort so far.

This does not mean that MNX is a CWMN-only standard. Via the content-typing
mechanism, MNX can support various notation approaches, including a
CWMN-focused one (the main work in front of us), an arbitrary, wide-open
graphics approach, and perhaps others. The *scope* of the standard thus
includes other notational systems and is not limited to CWMN. We do not
need to explore the characteristics of other notations in order to decide
whether the standard will embrace them or not.

For CWMN, a graphical approach does not eliminate the need for a semantic
approach, as has been underscored by others on this thread. So, we do not
need to enter into any heated debates about whether to go down the semantic
road for CWMN. Semantic CWMN markup will be one of the allowable content
types in MNX, and the one we look at in depth first.

A great deal of work remains to compare and contrast approaches to
arbitrary graphical scoring, as I've outlined in another thread. We see
this as an important but lower-priority discussion that can continue in the
background. However, we are devoting a bit of time in Frankfurt to talking
about it since it's been such a significant topic.

By way of reassurance, there is no intent to mandate that implementors
support all content types. CWMN-oriented applications interested in
semantic markup will probably only support the CWMN content type.

I've talked quite a bit with interested parties on the W3C staff about this
approach to dealing with non-Western (and Western-but-non-CWMN) notations.
They agree that different notation types will require different semantic
"modules", and that a purely graphics-based approach is *not* a viable
solution for applications that wish to work with semantic information.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Sat, Apr 1, 2017 at 9:40 AM, James Ingram <j.ingram@netcologne.de> wrote:

> Jeremy,
>
> Joe decided, for the purposes of his first draft, to concentrate on CWMN,
> but he's asking for feedback. I'm not at all sure that he has finally
> decided to go for a strictly CWMN standard. Why else would he include the
> notion of Profiles? Its something we'll surely be discussing in Frankfurt.
>
> I think that including Asian (and Arabic) notations in any future W3C
> standard will be much easier than you imagine, and that any future standard
> will be much more likely to be approved by the W3C if it can cope with as
> many of the world's writing systems as possible. The W3C has standards that
> apply to ordinary text that is written from right to left, so I imagine
> that it will expect us to follow suit.
>
> Best,
> James
>
> Am 01.04.2017 um 15:14 schrieb Jeremy Sawruk:
>
> James,
> Just because something is in the use cases doesn't necessarily mean that
> it is currently in scope. Joe has decided to just focus on CWMN at the
> moment, as it covers a lot of use cases while narrowing scope (though still
> a very wide scope!).
>
> You said: "I think there is going to have to be some mechanism in MNX to
> specify the type of the notation being encoded." Yes, that is the central
> idea of the score content type (Section 3.1). You are free to discuss other
> content types, and I think the proposal is flexible enough to describe
> medieval (neumes and mensural notations) and Asian notation that is aligned
> vertically rather than horizontally. It is my opinion that both can be
> achieved using the <sequence> and <event> element, as discussed in Section
> 5.3.6.
>
> On Sat, Apr 1, 2017 at 5:47 AM, James Ingram <j.ingram@netcologne.de>
> wrote:
>
>> Hi Rafael, Joe, all,
>>
>> Rafael said (about his speciality, Okinawan notation):
>>
>> But I understand that this tiny and infrequent use case, as medieval
>> music notation, will be out of the scope of your standard.
>>
>> I think that both Asian notations and mediaeval European notations should
>> be in scope. They are in the use cases.
>>
>> @Rafael: As I understand it, Okinawan notation reads from top to bottom,
>> with the columns being read from right to left. This is essentially a
>> simple rotation of 90 degrees from the way CMN is read. In fact, depending
>> on how MNX decides to organise its container hierarchies, and whether or
>> not you use measures, you could consider each column to be a <measure>,
>> <staff> or <system>. I don't see any problem there.
>>
>> I think there is going to have to be some mechanism in MNX to specify the
>> type of the notation being encoded. It would therefore help the group to
>> know more about the variability within Asian notations. I'm going to open
>> two new threads where we can talk about that:
>> 1. Asian notations: The directions in which they are read
>> 2. Asian event symbols
>>
>> @everyone: Please reply, if at all, to one of the above threads (not this
>> one).
>>
>> All the best,
>> James
>>
>> Am 31.03.2017 um 03:10 schrieb Rafael López García:
>>
>> I bet that MNX stands for Music Notation XML, and then what you want to
>>> save is the notation, not the music itself (otherwise you would use an
>>> approach more similar to MIDI).
>>>
>> Not bad, and you didn't even have to read the spec!  :-)
>>
>> But I read the one of MusicXML. And I wrote a MusicXML parser and a
>> Java-2-MusicXML converter in Android. And I may write another for MNX in
>> the future.
>>
>>
>> Yes, this is about saving a score, which is instructions on how to
>> perform music, as distinct from music itself.
>>
>>> And in my experience as a programmer I also think that XML is not a very
>>> good format to support "operations" (move a note to another measure, etc.),
>>> only serialize and de-serialize. I think the XML should be transformed to a
>>> object structure in memory and the operations should be performed to those
>>> objects, then saved again. And here you can choose to save all the XML
>>> again or replace only the one referred by the objects that have changed,
>>> but that is a matter to decide by every software developer (for example, my
>>> Kunkunshi Editor saves everything again as the XML parser I use is very
>>> simple).
>>>
>> From an informational point of view they are they are not completely the
>> same. A human-readable music score is more than the instructions really
>> needed to perform music. There are elements that are purely organizational
>> (e.g.: the measures) and others that are merely aesthetic. You don't really
>> need them to perform music, and they are actually introducing a certain
>> complexity that could be avoided, that is why Dr. Hörnel argued the
>> possibility of not having them.
>>
>> And actually... that is my case. When I wrote the aforementioned MusicXML
>> parser, I did it for Kunkunshi Editor, an editor of Okinawan music.
>> Okinawan music is NOT represented in the western fashion with staves and
>> measures, but with a different system called Kunkunshi (工工四). So I also
>> found all those organizational and aesthetic elements completely
>> unnecessary for my use case. And when I write the parser for MNX in the
>> future, it will happen again. But I understand that this tiny and
>> infrequent use case, as medieval music notation, will be out of the scope
>> of your standard.
>>
>> As you say, one shouldn't use XML itself to perform these operations (and
>> I hope no one does).
>>
>> Standard modern practice is to parse XML into memory using a Document
>> Object Model (DOM) parser and manipulate the in-memory structure via the
>> DOM API -- a web standard, see https://developer.mozilla.org/
>> en-US/docs/Web/API/Document_Object_Model. It can then be serialized back
>> out.
>>
>> This practice is so ubiquitous that web programmers like me will talk in
>> terms of manipulating the document, when what we really mean is
>> manipulating the DOM in memory!
>>
>> ...Joe
>>
>> Yes I know what a DOM parser is, I am tired of programming them. But when
>> I read Dr. Hörnel's email it looked like somebody was opening the door to
>> directly perform operations there. I am glad you clarified that is not the
>> case.
>>
>> Best regards,
>>
>> Rafa
>>
>>
>> --
>> https://github.com/notator
>> http://james-ingram-act-two.de
>>
>
>
> --
> https://github.com/notator
> http://james-ingram-act-two.de
>