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

[Raffaele Viglianti]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130622/8c746570/attachment.html>