<div dir="ltr"><div><div>I've suggested to Zoltan elsewhere that a good (I believe) way around this issue is to produce an ODD that documents the assumptions that the program makes when not enough information is provided.<br>

<br></div>It's possible to use <defaultVal> to express the default value of an attribute, and if the program needs a value for a missing attribute to proceed, it can default to <defaultVal>.<br><br></div>
<div>
ODD, in practice, could be used to define what Thomas is calling a "profile".<br></div><div><br></div>Zoltan's question, I think, is more general: is there room in the guidelines to cover what it means to omit an optional attribute? Most optional attributes may signify the presence/absence of a symbol or feature, but others like @barthru become meaningful as soon as there are barlines. <br>

<br>Perhaps @barthru needs a change in the ODD from optional to mandatory-when-applicable and a note in the guidelines? Are there other attributes that could benefit from the same treatment?<br><br>Raffaele<br></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Sat, Jun 22, 2013 at 9:00 AM, TW <span dir="ltr"><<a href="mailto:zupftom@googlemail.com" target="_blank">zupftom@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">Am 22.06.2013 14:41, schrieb Zoltan Komives:<br>
><br>
</div><div class="im">> However, in some cases an assumption of a default value can be implied<br>
> by the presence of the explicit information within the same (or nested,<br>
> or nesting) structure.<br>
><br>
> E.g. by<br>
> <staffGrp id="outer"><br>
>    <staffGrp id="inner" barthru="true"/><br>
>    <staffDef/><br>
>    <staffDef/><br>
> </staffGrp><br>
<br>
<br>
</div>I must agree!<br>
<div class="im"><br>
<br>
><br>
> Do I understand it right, that profiles are meant to handle these sorts<br>
> of ambiguities of encoding? It would be great if you could point me<br>
> towards further info regarding profiles.<br>
><br>
<br>
<br>
</div><div class="im">My understanding of these ideas is to create subsets of MEI with<br>
stricter rules that are required to provide more information in a more<br>
consistent way.  (I'm thinking about something similar to the Open<br>
Score Format, which is a stricter MusicXML.)  I'm not sure whether<br>
anyone has already done work on something like this, but I think<br>
*ideally* such profiles (or however you might call them) should not<br>
allow ambiguity to start with rather than giving you rules how to<br>
resolve ambiguity.<br>
<br>
Others might be more competent than me talking about this.<br>
<br>
Cheers!<br>
Thomas<br>
<br>
_______________________________________________<br>
</div>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>
</blockquote></div><br></div>