[MEI-L] clef as milestone element

[Benjamin Wolff Bohl]

Hi everybody,

first thanks for the interesting discussion bringing some clarification 
on what the "layout" module is all about, etc.
I'd like to give some inline comments on this summary:

Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
> 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 />;
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.
> 2.<clef />  is allowed in<sb />, explicitly used as a "cautionary" clef.
On this point I agree with Raffaele (31.05.2011):

>     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.


> 3. Cautionary clefs should be removed from the "musical" flow and placed in the<layout />  section.
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.
> 4. Keep the status quo and use<staffdef>  inside<staff>  to indicate a cautionary clef.
True, this seems a bit of an overkill...

> While I personally think 2 is the most semantically useful option, I understand that 1 is perhaps the easiest in the short term.
> I'm not really comfortable with 3, since it removes a musical element from the "flow" of the staff,
> 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.
> 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?
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 ;-)


Best,
Benjamin
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110607/8e6ca7c7/attachment.htm>