[MEI-L] More "precise" <app>s

[Andrew Hankinson, Mr]

Hi Thomas,

I think you're looking for @source on <rdg>. 

<meiHead>
....
<sourceDesc>
  <source xml:id="sourceA">
    <pubStmt/>
  </source>
  <source xml:id="sourceB">
    <pubStmt/>
  </source>
</sourceDesc>
....
</meiHead>
...
<measure n="1">
   <app>
     <rdg source="sourceA">
       <staff n="1">
         <!-- Some music -->
       </staff>
     </rdg>
     <rdg source="sourceB">
       <staff n="1">
         <!-- Some variant of the music -->
       </staff>
     </rdg>
   </app>
   <staff n="2"/>
   <staff n="3"/>
   <staff n="4"/>
   <staff n="5"/>
   <staff n="6"/>
   <staff n="7"/>
   <staff n="8"/>
   <staff n="9"/>
   <staff n="10"/>
 </measure>
 <measure n="2">
   <app>
     <rdg source="sourceA">
       <staff n="1">
         <!-- Some more music -->
       </staff>
     </rdg>
     <rdg source="sourceB">
       <staff n="1">
         <!-- Continued variant of the music -->
       </staff>
     </rdg>
   </app>
   <staff n="2"/>
   <staff n="3"/>
   <staff n="4"/>
   <staff n="5"/>
   <staff n="6"/>
   <staff n="7"/>
   <staff n="8"/>
   <staff n="9"/>
   <staff n="10"/>
 </measure>

@source can take a space-delimited list of xml:ids too.

-Andrew

On 2012-07-15, at 2:24 AM, TW wrote:

> Dear MEI family,
> 
> how does one encode variant readings that only affect a certain
> "strand" of events? For example, if we have a full orchestral score
> where there are different readings of the flute's measures 1 and 2, I
> see the following options:
> 1a) One big <app> around measure 1 and 2, containing all staffs twice, like so:
>  <app>
>    <rdg>
>      <measure n="1">
>        <staff n="1">
>          <!-- Some music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>      <measure n="2">
>        <staff n="1">
>          <!-- Some more music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>    </rdg>
>    <rdg>
>      <measure n="1">
>        <staff n="1">
>          <!-- Some variant of the music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>      <measure n="2">
>        <staff n="1">
>          <!-- Continued variant of the music -->
>        </staff>
>        <staff n="2"/>
>        <staff n="3"/>
>        <staff n="4"/>
>        <staff n="5"/>
>        <staff n="6"/>
>        <staff n="7"/>
>        <staff n="8"/>
>        <staff n="9"/>
>        <staff n="10"/>
>      </measure>
>    </rdg>
>  </app>
> This already seems like overkill, although I didn't even fill the
> staffs with music.  And facing such a monster, you'd have to look very
> closely to spot the actual variant readings, so this is certainly not
> the way to go.
> 
> 1b) To avoid filling the staffs twice, one could of course use @copyof
> the second time. But this might break ID references.
> 
> 2) Split this in two <app>s, like so:
>  <measure n="1">
>    <app>
>      <rdg>
>        <staff n="1">
>          <!-- Some music -->
>        </staff>
>      </rdg>
>      <rdg>
>        <staff n="1">
>          <!-- Some variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
>  <measure n="2">
>    <app>
>      <rdg>
>        <staff n="1">
>          <!-- Some more music -->
>        </staff>
>      </rdg>
>      <rdg>
>        <staff n="1">
>          <!-- Continued variant of the music -->
>        </staff>
>      </rdg>
>    </app>
>    <staff n="2"/>
>    <staff n="3"/>
>    <staff n="4"/>
>    <staff n="5"/>
>    <staff n="6"/>
>    <staff n="7"/>
>    <staff n="8"/>
>    <staff n="9"/>
>    <staff n="10"/>
>  </measure>
> This looks preferable to me, especially because it allows
> "overlapping" variants, e.g. when there is another phrase with variant
> readings, but this time for the basses from measure 2 to 3.
> Unfortunately, I don't see a really good way to indicate that any two
> or more <app> elements form a logical unit. I think that the
> att.common.anl family of attributes might be useful for this,
> especially the @prev and @next attributes because they imply the
> concept of a "collection".  The next best solution might be to use
> @prev and @next on the contained <lem> and <rdg> elements, but
> providing them on <app> would make things much clearer and easier.
> 
> Therefore, shouldn't att.common.anl be allowed on <app>?
> 
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> 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/20120715/9c785e5d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1054 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120715/9c785e5d/attachment.bin>