<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">As Thomas points out, I'm not sure that we want to go down the "mandatory-when-applicable" route. It may be that the omission of the @barthru (or similar attributes) is a conscious decision in the encoding, so specifying a default value in its absence may introduce undesired assumptions.<div><br></div><div>My opinion is that the best way to deal with ambiguity is to deal with it at the application level and then document your application's behaviour. If it were me, I would default to "false-if-not-present" for boolean values but, like Thomas mentions, another application might parse this as "unimportant-if-not-present". Either way, it's up to the implementation to specify behaviour, not the spec.</div><div><br></div><div>For non-boolean values it might be a bit trickier, but again I think the best way to deal with it is to make reasonable assumptions in how your users expect your application to behave and then document it.</div><div><br><div><div>On 2013-06-22, at 2:19 PM, Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><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>
_______________________________________________<br>mei-l mailing list<br><a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>https://lists.uni-paderborn.de/mailman/listinfo/mei-l<br></blockquote></div><br></div></body></html>