[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