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

[TW]

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