<div dir="ltr">Hi Perry,<div><br><div class="gmail_extra"><div class="gmail_quote"><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 lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">1. The position of a syllable with a word is handled by syl/@wordpos, where the value can be ‘i’, ‘m’, or ‘t’. There probably should also be a value for ‘complete word’ as well,
‘w’ perhaps?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u></span></p></div></div></blockquote><div><br></div><div>I think that a 'w' @wordpos value could be useful. Particularly if syl/@wordpos is optional. This would distinguish between cases where the word linking is unknown/undefined and where the syllable is known to be a complete word.</div>
<div> </div><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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">2. There was a typo in the elision example. It should’ve been --<u></u><u></u></span></p><div class="">
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <verse><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>Dios</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl con="elided" >que˘</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>al</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>mun-</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>do</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> </verse><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"></lyrics></span></p></div></div></div></blockquote><div><br></div><div>OK, that makes more sense. And I would then always expect the last CDATA character in syl/@con="elided" elements to be the elision character. There would be a complication if the elision consisted of more than one character for some reason...</div>
<div> </div><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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">3. Since @n is restricted to a single NMTOKEN, use verse/@label to capture multiple verse numbers:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <verse label="1.,2.,6"><u></u><u></u></span></p><div class="">
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>Dios</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl con="elided" >que˘</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>al</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>mun-</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl>do</syl><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> </verse><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"></lyrics></span></p></div></div></div></blockquote><div><br></div><div>That looks good (and you told me that before :-). Also, I in rondeaux I would need verse labels to occur multiple times, since the music is split into an A section and a B section, so there would be another one at the start of the B section, such as "3.,4.,5.". Is that possible/allowable?</div>
<div><br></div><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 lang="EN-US" link="blue" vlink="purple">
<div><p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">Now, for the real “meat”. We can’t forget that one of the functions of MEI, if not the primary one, is to represent existing documents. The reality is that real-world documents
are going to contain errors and inconsistencies that have to be dealt with. If MEI could mandate the “correct” way of doing things, as SCORE can, for example that divisions between syllables are always indicated by either a dash or an underscore, then life
would be much easier. What we need, however, is to accommodate multiple purposes -- recording what the document says, what it *ought to say*, and what it means (when we’re interested in that sort of thing).</span></p></div>
</div></blockquote><div><br></div><div>SCORE definitely does not mandate a correct way of doing things, although there are more correct and less correct ways of doing things. For example, the multiple hyphens case is typically implemented as a single dashed line. If you want to simulate a dashed line with unevenly spaced dashes, then you could either use separate little short lines, or use text hyphens instead. But as a programmer trying to parse the lyrics in the SCORE file, I would be irritated if I see a non-conventional method of displaying lyrics.</div>
<div><br></div><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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">What other [music] XML representations typically do (and what MEI does in some other places) is to record what the document says as the content of elements and any necessary annotations
of that content as embedded elements and/or attributes. My proposed changes are an attempt to do that with <syl>. In the case of the syllable “que˘” above, the elision marker is “in the text” of the document. I would prefer to leave it there and record
the fact that this syllable is elided with the next in the @con attribute. Sure, the connector can be moved to an attribute, but there are several problems with that approach:</span></p></div></div></blockquote><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 lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">a. the ability to say anything about the visual aspect of the connector, for example that it’s bold, is lost;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">b. omissions or errors can’t be explicitly indicated, for example that a connector isn’t present but ought to be or is there when it shouldn’t be;<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">c. it’s difficult (but not impossible) to handle multiple values when, for example multiple connectors are present (erroneously or not), as in ‘que-˘’. The rules of SCORE and
modern notation aren’t universally followed. </span><span style="font-family:Wingdings;color:black">J</span></p></div></div></blockquote><div><br></div><div>The important thing is that the elision marker be distinguishable from the linguistic text, so the elision marker can be manipulated independent of the text, such as to remove or replace it.</div>
<div><br></div><div>Surveying MusicXML's treatment of elision markers:</div><div> <a href="http://www.finalemusic.com/usermanuals/finale2012win/content/finale/Elisions2.htm">http://www.finalemusic.com/usermanuals/finale2012win/content/finale/Elisions2.htm</a> <br>
</div><div><br></div><div>I am having difficulty. The official method of displaying an elision marker in Finale is to use capital-I with the EngraverFontSet font as part of the syllable text. When exporting MusicXML with such an elision marker in Finale 2012, the syllable with the elision marker disappears....</div>
<div> </div><div>Here is the official MusicXML encoding method for elisions:<br></div><div><br></div><div><a href="http://www.finalemusic.com/UserManuals/MusicXML/Content/EL-MusicXML-elision.htm">http://www.finalemusic.com/UserManuals/MusicXML/Content/EL-MusicXML-elision.htm</a><br>
</div><div><br></div><div><div> <lyric number="1"></div><div> <syllabic>single</syllabic></div><div> <text>mi</text></div><div> <elision> </elision></div>
<div> <syllabic>begin</syllabic></div><div> <text>a</text></div><div> </lyric></div></div><div><br></div><div>With <lyric> being the text attached to a note, and this lyric containing two text syllables separated by an elision character. I like that it is easy to identify the elision character(s). The above example is with a space character as the elision. Here is the typical elision character, which unfortunately is not so pretty (as illustrated on the above link for the <elision> documentation):</div>
<div><br></div><div><div> <lyric number="1"></div><div> <syllabic>single</syllabic></div><div> <text>mi</text></div><div> <elision font-family="EngraverFontSet,engraved" font-size="10.25">I</elision> </div>
<div> <syllabic>begin</syllabic><br></div><div> <text>a</text></div><div> </lyric></div></div><div><br></div><div>However, when I load this example into Finale 2012, the elision marker is converted automatically into a space (and when I convert back to MusicXML, the <lyric> with the elision completely disappears).</div>
<div><br></div><div>Another interesting case: MuseData encodes elisions as spaces in the syllable text, with "\0+" used to indicate an literal space character. This is useful since most lyrics containing spaces will be intended to be joined by an elision character, which is not usually easy to type.</div>
<div><br></div><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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">In other words, the markup <syl con=”separated”>wan-</syl> contains the same data as <syl con=”d”>wan</syl>. </span><span style="color:black;font-family:Calibri,sans-serif">The difference is simply where the data is. BUT, as I indicated
in the list above, the latter is much more restrictive regarding what data can appear. Unless @con is also allowed to contain unrestricted CDATA, it will never be able to accommodate all the symbols that have been (or even could be) used to connect syllables.</span></p>
</div></div></blockquote><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 lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">I recognize that you’d like the data to be as regular as possible and so want to place the connector(s) in an attribute. But what would you do with (c)? Splitting the data by
putting ‘que’ in <syl> and ‘-˘’ in @con (if such a thing were allowed) could still result in “something [going] wrong in some obscure case”, whether the splitting is done by a human or by a software agent (Mr. OMR). In my opinion, it’s less dangerous to leave
the data together in just one place.</span></p></div></div></blockquote><div><br></div><div>(c) (<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">que-˘) would be the text "que-" followed by an elision marker, where the hyphen is part of the text and not a connector or part of the elision:</span></div>
<div><br></div><p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><lyrics xmlns="<a href="http://www.music-encoding.org/ns/mei" target="_blank">http://www.music-encoding.org/ns/mei</a>"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <verse><u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> <syl </span><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">con="elided"</span><span style="color:black;font-family:Calibri,sans-serif">>que-</span><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">˘</span><span style="color:black;font-family:Calibri,sans-serif"></syl></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> </verse><u></u><u></u></span></p><div><span style="color:black;font-family:Calibri,sans-serif"></lyrics></span></div><div><br></div>
<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 lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">I agree with you that putting "wan- - - - - - - - - - -" inside <syl> is not likely to be useful for (re-)rendering notation from the markup (and should probably be processed
to be simply “wan-“), but it does preserve information about the original document. </span></p></div></div></blockquote><div><br></div><div>If it is part of the prose text, I would allow it in the <syl> CDATA; otherwise, if it represents standard visual alignment dashes so that the singer does not sing the incorrect verse line for the next syllable, it is not directly related to the text "wan", and so should not be so closely associated with "wan".</div>
<div><br></div><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 lang="EN-US" link="blue" vlink="purple">
<div><p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"> Again, it’s less dangerous (and less work) to just leave it in place than to create the markup <syl con=”d”>wan</syl>, especially if you’re not interesting in (re-)rendering
or reconstructing the text (i.e., prose), which might be the case if the creation of the markup is done in stages.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:Calibri,sans-serif;color:black">Under no circumstances is this change (putting the connector in the character data of <syl>) meant to take the place of intelligent, dynamic rendering using SCORE or any other
processor. For example, even when a processor encounters “wan- - - - - - - - - - -" it shouldn’t render this literally. The size and number of dashes, underscores, etc. should be automagically calculated. But this data could be useful to those dealing strictly
with an image of the notation, and so shouldn’t be discarded.</span></p></div></div></blockquote><div><br></div><div>There will need to be a mechanism for a renderer to know that the dashes should be removed as computers are too stupid to figure that out by themselves. The only way I see to allow such constructs is to embed the dashes in some element:</div>
<div> wan<something>- - - - - - - - - - -</something></div><div>This might be useful for multi-character elisions as well:</div><div> que<elision>-<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">˘</elision></span></div>
<div><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">which would be different from:</span></div><div><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif"> que-<elision></span><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif">˘</elision></span></div>
<div><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif"><br></span></div><div>-=+Craig</div><div><br></div><div> </div></div>
</div>
</div></div>