Re: Requirements Matrix and Architectural Proposals

Hello Joe, Dominik, et al,

Joe, I also applaud your recommendations to separate semantics and
visual/layout information by using CSS!

Your recommendation to use CSS for 'performance indications'
<https://www.w3.org/community/music-notation/wiki/Architectural_Proposals#Use_CSS_for_the_Performance_Facet_of_Notation>
really means '*intended (MIDI) playback*', correct?  I don't think you mean
to imply that performance indications (for example,* fortissimo*, *leggiero*)
should not be a part of the semantic encoding, but rather that their
specific rendering in playback should be controlled with a CSS style sheet
(for example, *fortissimo* should be performed at 90% of maximum volume),
yes?  If my interpretation is correct, I agree that this would be a good
use of CSS.  A clarification in the description of this recommendation
might be in order.

Some responses to Dominik:


> - Question about Multiple rendering styles: "... This requirement states
> that the semantic data for a document may be associated with multiple
> styles, both within a given document and over a span of time."
> Could you give an example?
>

An encoding of a piece might be displayed on screens of different sizes, in
print, or with certain parts eliminated (think of excerpts of music
passages in books/articles).  Each of these scenarios could benefit from
its own styles (font sizes for screen display might be too large for print
or vice versa, page breaks used in print might not be suitable for screen
display, a new encoding for an excerpt would not be necessary if the
elimination of certain parts could be specified in a style sheet).  A
single encoding could also be used both for performance editions (ex.
conductor's score) and study editions (ex. miniature score).


> - Concerning performance/visual styling: If we want to make the
> distinction between performance and visual appearance (and I think we
> should), we should also separate them in the format. The easiest but
> probably not the best way would be using a naming convention for
> distinguishing performance and visual attributes (properties).


Here's how CSS handles this.  Let's say a user wants to change the color of
all editorial notes.  An element <note>, for example, could have the class
'editorial' and a CSS document could define the visual display of all notes
with this class as red.  Here is some very simple pseudo code:

XML:

<note class="editorial" />
<note class="editorial" />
<note />

CSS:

.editorial {

color: red;

}

The first two notes will be red and the last will keep its default color.
A different user might want editorial notes displayed in gray instead of
red, and can make this change in the CSS without changing the underlying
semantic encoding.

Unique ids can also be used to define styles, like this:

XML:

<note id="37" />
<note id="38" />
<note id="39" />

CSS:

#37, #38 {

color: red;

}

The separation between semantic and visual information allows the same data
to be used for a wide variety of purposes.  Hooray for CSS!

Best,

Sienna M. Wood
PhD in Musicology
sienna.m.wood@gmail.com
http://www.siennamwood.com/


On Wed, Apr 6, 2016 at 4:00 PM, capella-software Dr. Dominik Hörnel <
d.hoernel@capella.de> wrote:

> Hello Joe,
>
> some thoughts/questions on your architectural proposals:
>
> - One of the central points of MusicXML "redesign" should be turning it
> from an exchange format into a notation standard for both storage *and*
> manipulation of musical data. This is said between the lines ("can be
> incrementally modified / styled and highlighted programmatically") but
> could be emphasized.
>
> - It is definitely the right way to go towards well-established standards,
> such as CSS and DOM. But although these are general standards, their usage
> is strongly related to the Web/Javascript world and they currently have
> less support in the native (Java, C++) world. I think browsers and native
> platforms should be well balanced in the new format.
>
> - Question about Multiple rendering styles: "... This requirement states
> that the semantic data for a document may be associated with multiple
> styles, both within a given document and over a span of time."
> Could you give an example?
>
> - Concerning performance/visual styling: If we want to make the
> distinction between performance and visual appearance (and I think we
> should), we should also separate them in the format. The easiest but
> probably not the best way would be using a naming convention for
> distinguishing performance and visual attributes (properties).
>
> Best regards,
> Dominik Hörnel
>
> --
>
> capella-software AG
> An der Söhrebahn 4
> 34320 Söhrewald
> Tel. +49 (0)5608-3923
> Fax. +49 (0)5608-4651
> E-Mail: info@capella.de
> Internet: www.capella.de
> capella ist bei Facebook! <https://www.facebook.com/capella.Musiksoftware>
>
> Registergericht: Amtsgericht Kassel, HRB 15433
> Aufsichtsrat: Dr. Jutta Bott (Vorsitzende)
> Vorstand: Dr. Dominik Hörnel
>
>
> Am 06.04.2016 um 14:52 schrieb Joe Berkovitz:
>
> Hi Group,
>
> To stimulate discussion in Frankfurt (and, of course, on this list) I have
> published a couple of documents:
>
> 1. A Requirements Matrix now sets forth a set of intermediate requirements
> in various categories, These are derived from the already-published User
> Stories and are explicitly traced back to them. This list is still in a
> rather crude state (and is not prioritized or fully scoped) but I found it
> helpful to make and to think about:
>
>     https://www.w3.org/community/music-notation/wiki/Requirements_Matrix
>
> 2. The former "Technical Requirements" document is now retitled
> "Architectural Proposals" (as there are a set of technical requirements in
> the Requirements Matrix):
>
>
> https://www.w3.org/community/music-notation/wiki/Architectural_Proposals
>
> These proposals are an expression of my present opinion. They certainly
> don't reflect a concensus viewpoint -- at least not yet! -- but are
> intended as a starting point for thinking. I've published these thoughts in
> an unsanctioned state because I believe this is a good point in time for us
> to be discussing approaches and issues that have not been addressed to date
> in MusicXML, MEI or elsewhere.
>
> In many cases, my starting point for some proposal is some idea that has
> been quite successful in other realms, notably in Web and W3C standards. I
> have this orientation not because I think everything useful happens online
> or in a browser, but because the Web has given rise to an explosion of
> document exchange, expressivity and portability. In turn, this explosion
> has forced certain important problems in document modelling and structure
> to be considered and addressed. I think the solutions can be made
> completely portable across OSs, online/offline contexts, and programming
> languages, as they have elsewhere. Of course, many problems remain, and
> some of them will be specific to music -- but not all of them.
>
> Both documents are now linked from the main Wiki page.
>
> .            .       .    .  . ...Joe
>
> Joe Berkovitz
> President
> Noteflight LLC
>
> +1 978 314 6271
>
> 49R Day Street
> Somerville MA 02144
> USA
>
> "Bring music to life"
> www.noteflight.com
>
>
> --
> Mit freundlichen Grüßen
> Dr. Dominik Hörnel
>
> capella-software AG
> An der Söhrebahn 4
> 34320 Söhrewald
> Tel. +49 (0)5608-3923
> Fax. +49 (0)5608-4651
> E-Mail: info@capella.de
> Internet: www.capella.de
> capella ist bei Facebook! <https://www.facebook.com/capella.Musiksoftware>
>
> Registergericht: Amtsgericht Kassel, HRB 15433
> Aufsichtsrat: Dr. Jutta Bott (Vorsitzende)
> Vorstand: Dr. Dominik Hörnel
>