<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi everybody,<br>
<br>
first thanks for the interesting discussion bringing some
clarification on what the "layout" module is all about, etc.<br>
I'd like to give some inline comments on this summary:<br>
<br>
Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">Before moving on from the <clef /> discussion, I'd like to try and bring in a consensus. The way I've heard it there are a number of options:
1. <clef /> is allowed directly in <layer />;
</pre>
</blockquote>
As you say below, this,of course , would solve your immediate
problem but what if thinking of multiple layers on one staff; a clef
would also affect the other layers, or am I mistaken? If so it would
make no logical sense as part on a layer; it should be a direct
child of staff.<br>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
</pre>
</blockquote>
On this point I agree with Raffaele (31.05.2011):<br>
<blockquote>
<blockquote type="cite">I agree that using clefchange and staffdef
for courtesy clef repetitions is a bit cumbersome, but I would
advise against overweighting <pb/> and <sb/>. In my
opinion they should only signify the break and contain nothing.
A custos should occur *before* (or occasionally after) the
system break and not within the system break. If you think about
it, that is what happens on the page. In the same way, the clef
repetition should not be attached to sb or pb.</blockquote>
</blockquote>
<br>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">3. Cautionary clefs should be removed from the "musical" flow and placed in the <layout /> section.
</pre>
</blockquote>
Actually this would be THE solution if we stick to the opinion, that
the staff should be a virtual "endless" representation of the
musical flow. The cautionary clefs are a rendition phenomenon and do
not belong to the logic of the music but to the layout. In doing so
the layout module would somewhat encode the engraving quality of a
specific published edition.<br>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">4. Keep the status quo and use <staffdef> inside <staff> to indicate a cautionary clef.
</pre>
</blockquote>
True, this seems a bit of an overkill...<br>
<br>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">While I personally think 2 is the most semantically useful option, I understand that 1 is perhaps the easiest in the short term.</pre>
</blockquote>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">I'm not really comfortable with 3, since it removes a musical element from the "flow" of the staff,</pre>
</blockquote>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">and 4 seems a bit stilted to me, overloading <staffdef> to not really define anything new about a parent staff.
So, I will choose to implement #1 as it seems to solve our immediate issue for the time being.
</pre>
</blockquote>
<blockquote
cite="mid:A08D70F3-C9C4-498D-9232-BED1ED21DE03@mail.mcgill.ca"
type="cite">
<pre wrap="">How I propose to solve this is to create a new Incubator project ("clef-milestone") and create an ODD file that makes the change. This can then be reviewed by the Technical Group and, if it's found worthy, rolled into the mainline MEI standard at some point, likely with revisions.
Should anyone want to use this in another project they can then create their own customization based on the ODD file. That way they can at least have a reference back to the deviations from the MEI core.
In the comments of the ODD file I will reference this discussion so that there's a way to return to it to re-evaluate the positions put forward here when it comes time to review the revision.
Does this sound reasonable?
</pre>
</blockquote>
Sounds reasonable, all theoretical ideas are only theoretical,
whichever solution we opt for it has to be tested practically
(option 4 obviously failed, as it resulted in this discussion ;-)<br>
<br>
<br>
Best,<br>
Benjamin<br>
</body>
</html>