Hi Johannes,<div><br></div><div>Thanks for these very insightful comments! I agree with your arguments for a grouping element to help escape hierarchy (given that, one could imagine a stand-off approach to apparatus entries that might be quite interesting to work with). </div>
<div><br></div><div>Nonetheless, I still see value in having @next and @prev.<br><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 10:30 AM, Johannes Kepper <span dir="ltr"><<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't like @next / @prev on <app>. It seems like there is no order of differences between sources. </blockquote>
<div><br></div><div>Is the order of sources defined at app level? The @source attribute on rdg should allow you to list your rdgs in whatever order; information in the header dictates the relevance of each source over another.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Using @next to indicate that a separate <app> deals with the _same_ situation seems absolutely awkward.<br>
</blockquote><div><br></div><div>Although I can see why using @corresp or @sameas would be wrong, I don't see why using @next is awkward. @prev and @next don't indicate a sequence, but indicate an aggregation, which is what Thomas needed in his example.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For me, this situation is another argument to a feature request I've been talking about quite a while. In my opinion, MEI will need a generic <grp> (group) element to address issues like this. [...] A <damageGrp> would point to <damage> elements which may spread across all levels of hierarchy etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies on a linear encoding of a base text, which is just interrupted by additional, "strippable" markup. A similar solution seems not possible for MEI.<br>
</blockquote><div><br></div><div>This is true, and as I've said I like this idea. There still is value to embedded markup, though, particularly for apparatus entries. Still, I can see how it wouldn't work with damage, add, del, etc. in advanced manuscript transcription.</div>
<div><br></div><div>Best,</div><div>Raffaele </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Am 23.07.2012 um 13:14 schrieb TW:<br>
<div class="HOEnZb"><div class="h5"><br>
> 2012/7/23 Benjamin W. Bohl <<a href="mailto:bohl@edirom.de">bohl@edirom.de</a>>:<br>
>> Hi evbdy!<br>
>> Discussing the lacking possibility to aggregate multiple app elements by<br>
>> means of an attribute, which could be very handy indeed, I'd like to put<br>
>> into consideration that @prev and @next imply an order. This might exactly<br>
>> be what One is looking for, especially when thinking of genetic editions,<br>
>> but something like @corresp might be more applicable in other situations.<br>
>><br>
><br>
> @corresp would be covered by my suggestion to allow att.common.anl on<br>
> <app> and <choice>. However, @corresp always felt a bit vague to me.<br>
> I guess it could legitimately be used to point to an independent <app><br>
> element, meaning something like "Look, this is the same *kind* of<br>
> difference" rather than "This belongs to one virtual entity that has<br>
> been split because we can't break the hierarchy". @prev and @next are<br>
> a bit more definite, implying a "user-defined collection".<br>
><br>
> @sameas (also in att.common.anl) "sounds" like the most precise way of<br>
> saying everything belongs to the same logical <app>, but I see that<br>
> this meaning would be inconsistent with other uses of @sameas.<br>
><br>
> Other options I can think of:<br>
> - Having @plist on a "master" <app>, pointing to the subordinate<br>
> <app>s. This is very clear, but it's rather arbitrary what becomes<br>
> the master <app>. At first sight, a subordinate <app> can not be<br>
> distinguished from a standalone <app>.<br>
> - Some kind of stand-off markup?<br>
><br>
> In any case, I think having att.common.anl would already be a really<br>
> useful improvement.<br>
><br>
> Thomas<br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>