Re: Update on MusicXML Use Cases

Hi Zoltan,

Thanks so much for the careful reading. I'll make some changes in response;
a few comments are interspersed below. I'm looking forward to seeing you
soon in Frankfurt!

.            .       .    .  . ...Joe

On Wed, Apr 6, 2016 at 4:43 AM, Zoltan Komives <
zoltan.komives@tido-music.com> wrote:

> Hi Joe, All,
>
> 1) We don't have the most trivial use cases, such as *Composer wants to
> create notation for a composition.* True, everyone seem to have a good
> common understanding of these simple use cases, so maybe it's superfluous,
> and would bloat the document too much. Perhaps a paragraph could specify
> that the omission is intentional?
>

I think it's definitely worth adding. It's now present as MC0 -- the
numbering in this case seems appropriate, although it's also a cheap trick
to make it come first in the list :-)


> 2) *MC3: Arranger/performer wants to convert existing printed sheet music
> into digital sheet music [...] PF would like to work with the music in a
> notation application to adapt it or prepare a digital edition.*
> * I feel there's a confusion going on between roles: in the described
> example the person is basically taking up an editor/publisher role.
>

Very true. I've amended this use case to make MC3 a pure arranger/performer
case -- and it is true that many performers do exactly what is described,
although not to prepare a digital edition. usually it's to transpose a part
or rearrange it for a student ensemble.

I also added a new MP16 story to represent the true publishing angle which
is also very frequent but as you pointed out has a different purpose.


> 3) *MP5: Engraver wants detailed control over non-semantic formatting for
> printed output, while allowing for more flexible rendering on arbitrary
> devices e.g. mobile screens*
> * EN may also want detailed control of over some non-semantic formatting
> elements for for digital output as well as printed (e.g. positions of
> accidentals and dots in a chord, beam angles, etc). Furthermore, EN also
> wants _some_ control over elements that can break due to reflow, and _some_
> control over where systems can break even when it's non-semantic, e.g.
> breaking at a particular point is highly discouraged, but possible if
> that's the only option.
>

Great additional color. I just added your material directly to MP5.


> 4) According to the position that had been formed in the message of the
> W3C Community Development Team on 11 Sept 2015, the title and content of
> the document should be technology-agnostic:
> *"We believe document format discussions are best driven by use cases,
> expressed*
>
>
>
>
>
>
>
>
> *in terms of the needs and actions of different classes of users, as well
> as thenature and contents of the documents involved. Many of the
> discussions so farhave been framed in terms of technology choices
> like MusicXML vs. MEI, XML vs.JSON, or IEEE 1599 vs. SMIL. We would like to
> begin re-framing these discussionsto clearly identify user needs and
> document contents served by specificfeatures in these technologies, rather
> than on whether we should pick technologyA vs. technology B. Eventually we
> can shift to finding technical solutions thatsatisfy the use cases we deem
> worth addressing, in the context of this group’scharter."*
> Perhaps they could be called Music Notation Format Use Cases, and Music
> Notation Format Technical Requirement respectively.
>

First of all, I don't mind removing the name from the title since I do not
think it affects our work in any substantive way, so I've done that. I have
not been titling the most recent documents as MusicXML (I forget how the
original Use Cases got named that way).

We do seem to have an open question about the name that we apply to the
next iteration of a notation standard, whatever it is called. So far the
co-chairs feeling has been that the name MusicXML is reasonable, insofar as
we were trying to make this into an evolutionary step from a standard with
very broad (though certainly not universal) adoption. It is a little bit
like the debate over whether HTML5 should have been called HTML -- some
felt that it should not be, given its radical differences. In fact, HTML5
was for some time the subject of a sort of Western Schism, with conflicting
standards groups (and popes) claiming jurisdiction. Eventually -- and
fortunately -- this was resolved. But I'm just recounting history, not
taking a definite side on the naming question.  Doug Schepers of W3C had at
one point suggested MusicML, or something that would connote some
difference from MusicXML while implying some lineage as well. That's
another interesting idea.

The Technical Requirements have been completely rewritten as I will
announce momentarily. They are mostly pretty neutral in phrasing although
there are some detailed points regarding present-day MusicXML, as well as
an explicit acknowledgement of MEI.

All the best,

...Joe