[MEI-L] [mei-devel] Attribute default values

[Andrew Hankinson]

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.

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.

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.

On 2013-06-22, at 2:19 PM, Raffaele Viglianti <raffaeleviglianti at gmail.com> wrote:

> 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.
> 
> 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>.
> 
> ODD, in practice, could be used to define what Thomas is calling a "profile".
> 
> 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. 
> 
> 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?
> 
> Raffaele
> 
> 
> On Sat, Jun 22, 2013 at 9:00 AM, TW <zupftom at googlemail.com> wrote:
> Am 22.06.2013 14:41, schrieb Zoltan Komives:
> >
> > However, in some cases an assumption of a default value can be implied
> > by the presence of the explicit information within the same (or nested,
> > or nesting) structure.
> >
> > E.g. by
> > <staffGrp id="outer">
> >    <staffGrp id="inner" barthru="true"/>
> >    <staffDef/>
> >    <staffDef/>
> > </staffGrp>
> 
> 
> I must agree!
> 
> 
> >
> > Do I understand it right, that profiles are meant to handle these sorts
> > of ambiguities of encoding? It would be great if you could point me
> > towards further info regarding profiles.
> >
> 
> 
> My understanding of these ideas is to create subsets of MEI with
> stricter rules that are required to provide more information in a more
> consistent way.  (I'm thinking about something similar to the Open
> Score Format, which is a stricter MusicXML.)  I'm not sure whether
> anyone has already done work on something like this, but I think
> *ideally* such profiles (or however you might call them) should not
> allow ambiguity to start with rather than giving you rules how to
> resolve ambiguity.
> 
> Others might be more competent than me talking about this.
> 
> Cheers!
> Thomas
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> _______________________________________________
> 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/20130622/afaedf05/attachment.html>