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

[Zoltan Komives]

Hi Thomas,

Thanks for your reply! I am very new to MEI, and your answer helps me a lot
to understand some of the MEI principles!

I understand that the option for "no information is provided" is a basic
MEI principle to achieve maximum flexibility.

>That said, assuming default values for attributes like @barthru would sort
of force projects to set this >attribute because leaving it out would have
implications that were not intended.
I see, e.g. by
<staffGrp/>
  <staffGrp/>
  <staffDef/>
  <staffDef/>
</staffGrp>
we want to mean neither "bar lines crossing across all the staves", nor
"bar lines do not cross any of the staves". Following the "no information
principle" it simply means nothing about bar lines.

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>
the editor most probably means staffGrp="false" in the outer group, rather
than "no information about whether bar lines are crossing in the outer
group or not, but bar lines definitely crossing in the inner group".

Another example is
<staffGrp id="outer" barthru="true">
  <staffGrp id="inner"/>
  <staffDef>
</staffGrp>
where the inner group should surely "inherit" its parent's barthru="false"
if we think about it intuitively.

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.

Thanks very much
Zoltan

P.S.: following Andrew Hankinson's suggestion I am moving this discussion
from mei-devel to MEI-L



2013/6/21 Thomas Weber <zupftom at web.de>

> Hi Zoltan,
>
> welcome to the wonderful world of MEI!  It's good to see people driving
> MEItoVexFlow forward.
>
>
> Am 21.06.2013 18:42, schrieb Zoltan Komives:
>
>> We will have to decide upon the default behaviour for certains
>> attributes in case they are not present.
>>
>> We are going to define a customization for our particular application,
>> but it raises the question whether there are some attributes that would
>> benefit from a default value set by the guidelines.
>>
>> In particular, we've come across the @barthru attribute (/"indicates
>>
>> whether bar lines go across the space between staves (true) or are only
>> drawn across the lines of each staff (false)."/). Its use is highly
>>
>> inconsistent across the sample encodings, and we think that maybe for
>> this particular attribute we would gain more in consistency than the
>> loss in flexibility.
>>
>>
>
> I don't think that for MEI it would make sense to define defaults for
> attributes like this.  I only fear my explanation will not really help to
> bring MEItoVexFlow forward in the short run...
>
> MEI, being designed for musicological uses, by intention allows very
> different music encoding approaches.  Musicological projects may have very
> different requirements, some concentrating on mere pitch information more
> in a MIDI like fashion, some encoding as much as possible of the layout
> information found in a specific source, some not even encoding musical
> content at all but only structural or macro-layout information.  This
> means, MEI gives you the choice to encode just the information required for
> a specific project, leaving everything else out.  That said, assuming
> default values for attributes like @barthru would sort of force projects to
> set this attribute because leaving it out would have implications that were
> not intended.
>
> A missing @barthru in my eyes should just be read as "this particular
> encoding does not record information about whether barlines cross the space
> between staffs".  If you have to deal with data that has no @barthru but
> you need it, then you unfortunately have to find your own solutions how to
> fill them in (which might be just assuming them to be false, or do some
> more clever guessing).
>
> There were plans to define MEI "profiles" that follow stricter rules to
> make MEI data more exchangeable for certain applications.  For your
> application, a profile that enforces information needed for rendering would
> of course be very useful.  As profiles don't exist yet, you could take the
> initiative and make suggestion how such a profile should look like.  Also,
> there were plans to create tools that would "iron" and "canonicalize" MEI
> so you can then work with more consistently encoded data.  I have a few
> small XSLT 2.0 stylesheets that cover some aspects of this (like converting
> attributes to elements in cases where there are both attributes and
> elements available to encode the same thing; or add @plist to spanning
> elements).  I guess we should start collecting these things.
>
> I wish you a successful summer and am curious what we will see after this
> GSOC!
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20130622/d79798a9/attachment.html>