<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="direction: ltr;font-family: Arial Unicode MS;color: #000000;font-size: 12pt;">
<p>Hi Raf,</p>
<p> </p>
<p>There already is a way to indicate if barlines are drawn continuously between staves -- the @barthru attribute on <staffGrp>. But that's unimportant with regard to your main point, I believe.</p>
<p> </p>
<p>The connecting line does indicate "some kind of grouping", but the issue is that sometimes we need to record two properties of the outermost group -- whether there's a connecting line and the brace, bracket, etc. used. Obviously, this can't be done with
a single attribute.</p>
<p> </p>
<p>One solution is to expand the hierarchy, placing @symbol="line" on the outer group, and @symbol="bracket" on the inner one. But this is overly complex. I think a better solution is to provide a new attribute for indicating the presence of the connecting
line. Reduced complexity makes this new approach more likely to be used and processed correctly.</p>
<p> </p>
<p>Having decided we need another attribute, where do we put it? We could allow it on <staffGrp> also, but without a schematron rule to limit its use to only the outer group, syntactically it can occur on any staff group, which could lead to confusion again.
A different approach is to allow it to occur on the parent of the outer <staffGrp>; that is, on <scoreDef>, as I explained in my previous message. If it is placed on <scoreDef>, then it is an optional visual property of the score that gets inherited by the
outermost staff group.</p>
<p> </p>
<p>No matter where the presence of the connecting line is recorded, it's still a visual property of the outermost staff group.</p>
<p> </p>
<p>--</p>
<p>p.</p>
<div>
<div class="BodyFragment"><font size="2">
<div class="PlainText"><br>
__________________________<br>
Perry Roland<br>
Music Library</div>
<div class="PlainText">University of Virginia</div>
<div class="PlainText">P. O. Box 400175</div>
<div class="PlainText">Charlottesville, VA 22904<br>
434-982-2702 (w)<br>
pdr4h (at) virginia (dot) edu</div>
</font></div>
</div>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF823863"><font color="#000000" size="2" face="Tahoma"><b>From:</b> mei-l [mei-l-bounces@lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti@gmail.com]<br>
<b>Sent:</b> Monday, December 16, 2013 5:14 PM<br>
<b>To:</b> Music Encoding Initiative<br>
<b>Subject:</b> Re: [MEI-L] ...brackets in orchestral scores: Finale shapes, etc.<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Let's assume that we add the extra attribute on scoreDef to specify the presence/absence of this line. Shouldn't we then think of a way to specify whether barlines are drawn continuously between staves or not? Or whether stems are extended through
beams or not (e.g. French beams)?
<div><br>
I still think that if the line means some sort of grouping (or if the encoder thinks so), let there be an extra staffGrp. If it's only a convention / editing house style, then it shouldn't matter for MEI, like French beams don't matter at the moment. Though
someone may want to study the evolution of beam typesetting in Alsace-Lorraine and whether local musicians switched between French and German style... I'm making things up just to point out that any mark on the page is not "semantic" until we decide it is.<br>
<div><br>
Raf</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Dec 16, 2013 at 4:28 PM, Andrew Hankinson <span dir="ltr">
<<a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">andrew.hankinson@mail.mcgill.ca</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
Two clarifying questions:<br>
<br>
1) You wouldn’t be talking about eliminating all nested <staffGrp />, would you?<br>
2) Why would you bump this up to <scoreDef />? How would that eliminate the need for schematron rules? (Keeping the symbol on <staffGrp /> seems a bit more explicit to me.)<br>
<br>
For reference, Sibelius refers to the first line as the “Initial barline”, not as a grouping symbol. You can en/disable showing this, but interestingly disabling the initial barline also hides any brackets associated with the group. If you re-enable the barline,
it will show the bracket or brace.<br>
<div class="im HOEnZb"><br>
<br>
On Dec 16, 2013, at 10:09 AM, Roland, Perry (pdr4h) <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>> wrote:<br>
<br>
><br>
> Thinking about Laurent's original question a little more, I've come to realize that my original thinking on staff grouping was, well, misguided.<br>
><br>
> I now think that instead of reserving @symbol="line" for the left-hand, staff-connecting line, another attribute should be added to <staffGrp> (or even on <scoreDef>) to capture the presence of this line. This eliminates the need for nested <staffGrp> elements
as well as the need to change any existing software.<br>
><br>
> This new attribute (I'm still casting about for a name) should take a value of true or false depending on the presence/absence of the connecting line. Of course, this attribute can only make sense when it's on the outermost <staffGrp>. This is a good argument
for pushing it up a level to <scoreDef>. Doing that eliminates the need for schematron rules or reliance on convention to enforce good practice.<br>
><br>
> The existing @symbol attribute with a value of "line" can be used (as in MusicXML) to describe the presence of a wide line used as the grouping symbol. Of course, the Guidelines will need to be changed to reflect these changes.<br>
><br>
> I'm aware that changes like this, that is, keeping the same markup but changing its meaning, are dangerous. But sometimes it's the simplest, and indeed the best, solution.<br>
><br>
> Humbly,<br>
><br>
</div>
<div class="im HOEnZb">> --<br>
> p.<br>
><br>
><br>
> __________________________<br>
> Perry Roland<br>
> Music Library<br>
> University of Virginia<br>
> P. O. Box 400175<br>
> Charlottesville, VA 22904<br>
> <a href="tel:434-982-2702" target="_blank" value="+14349822702">434-982-2702</a> (w)<br>
> pdr4h (at) virginia (dot) edu<br>
</div>
<div class="HOEnZb">
<div class="h5">> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">
https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>