<div dir="ltr">Hi Thomas, <div><br></div><div style>Thanks for your reply! I am very new to MEI, and your answer helps me a lot to understand some of the MEI principles!</div><div style><br></div><div style>I understand that the option for "no information is provided" is a basic MEI principle to achieve maximum flexibility. </div>
<div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">>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.</span><br>
</div><div style><font face="arial, sans-serif">I see, e.g. </font><span style="font-family:arial,sans-serif">by</span></div><div style><font face="arial, sans-serif"><staffGrp/></font></div><div style><font face="arial, sans-serif"> <staffGrp/></font></div>
<div style><font face="arial, sans-serif"> <staffDef/></font></div><div style><font face="arial, sans-serif"> <staffDef/></font></div><div style><font face="arial, sans-serif"></staffGrp></font></div>
<div style>
<span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style>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. </div>
<div style><br></div><div style>E.g. by </div><div style><staffGrp id="outer"><br></div><div style> <staffGrp id="inner" barthru="true"/></div><div style> <staffDef/></div>
<div style> <staffDef/></div><div style></staffGrp></div><div style>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". </div>
<div style><br></div><div style>Another example is</div><div style><staffGrp id="outer" barthru="true"></div><div style> <staffGrp id="inner"/></div><div style> <staffDef></div>
<div style></staffGrp></div><div style>where the inner group should surely "inherit" its parent's barthru="false" if we think about it intuitively.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>Thanks very much</div><div style>Zoltan</div><div style><br></div><div style><p style="margin-top:0pt;margin-bottom:0pt">P.S.: following <span style="font-family:arial,sans-serif;font-size:13px;white-space:nowrap">Andrew Hankinson</span>'s suggestion I am moving this discussion from mei-devel to MEI-L </p>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/21 Thomas Weber <span dir="ltr"><<a href="mailto:zupftom@web.de" target="_blank">zupftom@web.de</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Zoltan,<br>
<br>
welcome to the wonderful world of MEI! It's good to see people driving MEItoVexFlow forward.<br>
<br>
<br>
Am <a href="tel:21.06.2013%2018" value="+12106201318" target="_blank">21.06.2013 18</a>:42, schrieb Zoltan Komives:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
We will have to decide upon the default behaviour for certains<br>
attributes in case they are not present.<br>
<br>
We are going to define a customization for our particular application,<br>
but it raises the question whether there are some attributes that would<br>
benefit from a default value set by the guidelines.<br>
<br></div>
In particular, we've come across the @barthru attribute (/"indicates<div class="im"><br>
whether bar lines go across the space between staves (true) or are only<br></div>
drawn across the lines of each staff (false)."/). Its use is highly<div class="im"><br>
inconsistent across the sample encodings, and we think that maybe for<br>
this particular attribute we would gain more in consistency than the<br>
loss in flexibility.<br>
<br>
</div></blockquote>
<br>
<br>
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...<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
I wish you a successful summer and am curious what we will see after this GSOC!<span class=""><font color="#888888"><br>
Thomas<br>
</font></span></blockquote></div><br></div></div>