Re: Splitting MNX-Common and MNX-Generic

Two things:
1) Could we please move this email chain to the Github issue? This way,
everyone is discussing this issue in the same place.

https://github.com/w3c/mnx/issues/98

2) Mike Cuthbert makes some very good points. I am not very familiar with
MEI, but MNX-Neumes is something that I would like to see in the future.
Given these points, I think we should really ask: what problem would MNX
solve? MNX may not be the right tool for every application, and I doubt we
could find a compromise that everyone would agree with. Per Andrew
Hankinson's message, there very well may be use cases where MEI is the
right approach and MNX just doesn't support it. I think this is worth
discussing further, but I would prefer to discuss it on the Github thread
instead.

Thanks,
J. Sawruk

On Mon, Mar 11, 2019 at 1:27 PM Andrew Hankinson <andrew.hankinson@gmail.com>
wrote:

> Or, you could just embrace MEI... We don't bite. :)
>
> -Andrew
>
> > On 11 Mar 2019, at 17:21, Michael Scott Cuthbert <cuthbert@mit.edu>
> wrote:
> >
> > One principal reason for keeping both frameworks and to keep them under
> a single name is for transition from MusicXML to MNX for researchers who
> would otherwise be considering MEI.  How will we indicate that MNX (or
> whatever the overarching name is called) is a format that can handle
> representation of the 2nd and 3rd scores in
> https://joeberkovitz.github.io/gmnx-viewer/  ?   I think that there are
> important marketing considerings for MNX for the research community to be
> considered with respect to “MEI can do X, can MNX do it?” which should be
> answered with “yes.” and not “no, MNX can’t, but Y can, and it’s by the
> same people”.  What will the other future expansions of MNX previously
> discussed (MNX-Neumes, etc.) be called?  I need to know a little more, but
> for now, I’m -1 on the idea.
> >
> > Myke
> >
> > ---                                                     ---
> > Michael Scott Cuthbert
> > Faculty Director, Digital Humanities, MIT             4-215
> > Associate Professor of Music, MIT
> >     +1.413.575.6024
> >
> > Admin Assistant: Nicole Fountain (nicolelf@mit.edu)
> >
> > cuthbert@mit.edu                    http://www.trecento.com
> >
> >
> >
> >> On Mar 11, 2019, at 04:59, Adrian Holovaty <adrian@holovaty.com> wrote:
> >>
> >> Hi all,
> >>
> >> In defining the MNX format, we've envisioned having a single format
> that contains at least two "types" of music notation data — MNX-Generic and
> MNX-Common. I've come to believe this isn't the right move.
> >>
> >> (For background, see the current spec at
> https://w3c.github.io/mnx/specification/)
> >>
> >> I believe MNX-Generic and MNX-Common are sufficiently different that
> they should just be two separate formats, rather than us trying to shoehorn
> them into a single format. Three reasons:
> >>
> >> 1. It's confusing for end users. Which one should users choose when
> importing/exporting? How would the user understand the differences in the
> level of semantics between the two similarly named formats? In my own
> experience, it's already confusing enough explaining the difference between
> a PDF and MusicXML, and those have different names!
> >>
> >> 2. It's confusing for developers. The type of development work required
> to parse something that is essentially an SVG wrapper versus a semantic
> document model is completely different. I would estimate 90% of developers
> would only want/need to parse one or the other — which strongly suggests
> they should be separate formats.
> >>
> >> 3. There's no obvious benefit in combining them, apart from some
> negligible things like having a common metadata format.
> >>
> >> With this in mind, I'm proposing we formally split this into two
> formats, with distinct names and distinct specs. (To be clear, I think
> there's clear value in both formats existing.)
> >>
> >> I brought this up with the other co-chairs in our latest meeting — you
> may have already seen the meeting minutes — and we're in broad agreement.
> Here are the meeting minutes with more details:
> https://www.w3.org/community/music-notation/2019/03/05/co-chair-meeting-minutes-march-5-2019/
> >>
> >> Can anybody articulate a reason why we shouldn't make this change? I'd
> like to make sure we aren't overlooking a benefit that a single format
> would give us. If not, I can begin the work of splitting the spec in two.
> Please make any comments on the relevant GitHub issue (
> https://github.com/w3c/mnx/issues/98), so that we keep all the feedback
> in one place.
> >>
> >> Cheers,
> >> Adrian
> >
>
>
>