[MEI-L] halfmRpt and @rend

Roland, Perry (pdr4h) pdr4h at eservices.virginia.edu
Mon Aug 12 17:56:53 CEST 2013


Hmmm, forgot about that!



If we proceed with plans to make @rend and @style available on more elements but with generic typographic meaning, existing @rend attributes will have to be replaced by some other attribute that carries element-specific renditional information, possibly @form.  For now, @altsym is the only other option.  Remember, however, that the value of @altsym must be a URI that points to a symbolDef element.



Considering the potential of SMuFL, I've been thinking a character-oriented method for indicating an exact or alternate rendition might be another way to go.  We could, like TEI, provide for defining a character in the header which is then pointed to using an attribute, similar to the way <symbolDef> and @altsym work), or we could allow text content of elements to contain Unicode character references to codepoints defined by SMuFL. Another possibility is to re-work <symbolDef> so that it can hold the Unicode reference (making it similar to TEI's <charDecl>) which is pointed to using @altsym as before.  This is going to take a while to discuss and implement, though.



--

p.



__________________________
Perry Roland
Music Library

University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Benjamin Wolff Bohl [bohl at edirom.de]
Sent: Monday, August 12, 2013 10:44 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] halfmRpt and @rend

I just checked on mRpt and mRpt2, both of which don't allow @rend either.
Anyhow, all of the rpt elements allow @altsym.

Considering this in combination with googlecode isuue 144 (http://code.google.com/p/music-encoding/issues/detail?id=144) "reserve @rend and @style for CSS-like renditional information", is it the right way to go, or should we stick with @altsym and maybe disallow @rend on beatRpt?

Best,
Benjamin

***********************************************************
Musikwissenschaftliches Seminar Detmold/Paderborn
BMBF-Projekt "Freischütz Digital"
Benjamin Wolff Bohl
Gartenstraße 20
D–32756 Detmold

Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668
E-Mail: bohl at edirom.de<mailto:bohl at edirom.de>

http://www.freischuetz-digital.de
***********************************************************

Am 12.08.2013 15:20, schrieb Roland, Perry (pdr4h):

Pretty sure that's an oversight.  Please submit a ticket.



Thanks,



--

p.



__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com<mailto:raffaeleviglianti at gmail.com>]
Sent: Monday, August 12, 2013 8:44 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] halfmRpt and @rend

FWIW, having looked at the same material, I also think a @rend would be very useful there.

Raf


On Mon, Aug 12, 2013 at 8:41 AM, Benjamin Wolff Bohl <bohl at edirom.de<mailto:bohl at edirom.de>> wrote:
Hi all,

proofreading our data in Freischütz-Digital I came across repeat symbols. First case I was wondering whether to go with beatRpt but then I realized there was halmRpt, as well.
As Weber writes his repeats as double slashes (not the common %) we're in eager need of @rend to indicate this circumstance. While @rend is available on beatRpt, it isn't on halfmRpt.

Is there any reason for that, am I missing something?

Best,
Benjamin
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l




_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130812/38fcec99/attachment.html>


More information about the mei-l mailing list