extend data.ARTICULATION, data.ACCIDENTAL, etc. to include SMuFL code points

[ahankinson]

From pd...@virginia.edu on January 27, 2015 17:56:57

While it's not necessary to allow all the possibilities of SMuFL, adding some additional values (additional quarter-tone and just intonation accidentals and additional articulations, for example)

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=214

[ahankinson]

From pd...@virginia.edu on January 27, 2015 14:59:51

Labels: Milestone-ReleaseNext

[raffazizzi]

I wonder if it is a good idea to add the code points as a value? It could be problematic when there are compound glyphs. And SMuFL is not very semantic and may have different symbols to indicate an accent, but for MEI it should be an accent with different rendering.

Wouldn't it be better to allow @altsym to be used more generally and have it point to a symbolTable of SMuFL codepoints? We could provide this table as a downloadable file that can be xincluded when one wants to use SMuFL codepoints.

<symbolTable>
      <symbolDef xml:id="smufl_someStrangeAccentForm">
          <anchoredText>&#xCODE;</anchoredText>
      </symbolDef>
      <!-- etc -->
</symbolTable>
<!-- elsewhere -->
<artic artic="acc" altsym="#smufl_someStrangeAccentForm"/>

[pe-ro]

Allowing code points as the value of artic is a bad idea. altsym should already point to a symbolDef element (not symbolTable). symbolDef must be redefined along the lines of TEI's char element (in pseudo DTD syntax) --

symbolDef (symName?, symProp*, mapping*, model.graphicLike*, annotLike*)
symName (#PCDATA)
symProp ((unicodeName | localName), value)
mapping (#PCDATA | symbol)* -- this is expressed as a mixed content model but it really should be one or the other, not mixed

The indirection provided by this methodology insulates one from future changes, such as the adoption of SMuFL into Unicode or the creation of a SMuFL competitor.

But this may be too "heavy" a solution for some, so there could be a "quick and dirty" alternative -- add stdval (or code, and perhaps authURI and authority) attributes to elements that we expect to point to SMuFL via a codepoint value. Schematron can be added to insure that stdval attributes where we expect SMuFL (this is not universal) conform to a standard syntax, such as '#xE0000'. The only problem I see with this is that it is the SMuFL names that are persistent, not the codepoints. Another possibility is to add a codepoint attribute that must conform to the standard syntax. In either case, the trick is to support SMuFL without making MEI SMuFL-centric.

Comments? @lpugin, @kepper?

Quick question -- How does one insert code as Raff has done above?

[ahankinson]

You can do that by enclosing your code with three backticks. Optionally, you can set the language by adding it to the end of the opening backticks, so:

```xml
<foo>
   <bar></bar>
</foo>
```

becomes

<foo>
   <bar></bar>
</foo>

[raffazizzi]

altsym should already point to a symbolDef

I know that, and my example complies. What I meant is that I think @altsym should be more widely available, for example it is not on <artic> at the moment. That would be needed even with with what you're suggesting right? Or would you want an entirely new attribute for the codepoints or names?

[pe-ro]

Sorry, I misunderstood your suggestion. Yes, @altsym should be more widely available. But it should be used only to point internally; that is, to the ID of a <symbolDef> element. One or more new attributes have to be added to support the "quick and dirty" method.

[pe-ro]

The "quick and dirty" method I now think would be best accomplished by adding @smuflname and @smuflcode in a new MEI.smufl module. This would make it possible to "short circuit" the @altsym / <symbolDef> methodology in a very intuitive way. If SMuFL is eclipsed someday by some other system, then it would be very easy to ignore the SMuFL module and create another for the new thing. But, I want to keep the more abstract @altsym approach too.

Supporting SMuFL is more than just adding these attributes, however. It also means making sure that MEI and SMuFL have the same level of granularity; that is, there are some things in MEI that are currently expressed in attributes (notehead shape and stems, for instance) that would be better treated as elements, so that they can bear the new attributes mentioned above. This is also related to the changes sought by the black mensural notation folks.

@lpugin and I already had some discussion along these lines, but I'd like to hear from others. @kepper ?

[kepper]

Am 06.07.2015 um 20:18 schrieb pe-ro notifications@github.com:

The "quick and dirty" method I now think would be best accomplished by adding @smuflname and @smuflcode in a new MEI.smufl module. This would make it possible to "short circuit" the @altsym / methodology in a very intuitive way. If SMuFL is eclipsed someday by some other system, then it would be very easy to ignore the SMuFL module and create another for the new thing. But, I want to keep the more abstract @altsym approach too.

I'd like to see some real-world examples, ideally some that illustrate the problems where MEI and SMuFL implement a different level of granularity…

Supporting SMuFL is more than just adding these attributes, however. It also means making sure that MEI and SMuFL have the same level of granularity; that is, there are some things in MEI that are currently expressed in attributes (notehead shape and stems, for instance) that would be better treated as elements, so that they can bear the new attributes mentioned above. This is also related to the changes sought by the black mensural notation folks.

Just the other day, I encountered yet another problem with Beethoven, or better with expectations about the encoding of his scores. To make a long story short, it was about the expectation that a note would be more or less still the same thing, even after he added a flag to turn a quarter into eighth. Right now, I have to delete the original 4, and add another 8. It is left to things like @sameas, @corresp or (certainly less accessible) the reference to the same svg:shapes in @FACS to indicate the close relationship between these two notes. With , and similar child elements of notes, this could be encoded in a more accessible way. However, at this point I would probably refuse to use it in our project, as it results in an extremely verbose encoding, which is hardly maintainable. So yes, I see a benefit in having it, even in a quite different context. At the same time, I'm afraid of the consequences it might have. We should clearly discourage to use these elements unless people really know what they're doing…

Just my first thoughts…
jo

@lpugin and I already had some discussion along these lines, but I'd like to hear from others. @kepper ?

—
Reply to this email directly or view it on GitHub.

[pe-ro]

I think you've just provided a very good example (better than any I can conjure at the moment). Note heads, stems, and flags are the only examples I have found so far that require "elevation" to element status, since we already provide accid, artic, and dot elements inside <note>. BTW, <notestem> would be best expressed as simply <stem> as it must be allowed within <chord> too.

I share some of your reluctance to go too far in this direction, not so much because of the verbosity it adds, but because of the added complexity as it relates to editorial intervention (soon <rdg> will allow just about everything in MEI). But, if we're going to address more visual characteristics (which is necessary to deal with medieval; i.e., black mensural, and modern notation), then it's a fait accompli. And we've already entered this territory with <accid>, etc.

This is not to say that the "shorthand" method of using attributes should go away. On the contrary, it should be preserved not only for its terseness, but I would argue that in most cases it is entirely correct to see a set of alterations as one editorial act, for example turning a quarter note into an 8th, which is best represented in a simple way; that is, as the deletion of the quarter note and the addition of an 8th even though what Ludwig did was add a flag. It depends on what the object of the representation is -- the text alteration or the writing acts. Again, it's a matter of granularity. Of course it's up to the project to define where it wants to draw the line. I suspect that most people aren't going to be interested in the kind of stuff that Beethovenswerkstatt is. But they shouldn't be denied the means to use SMuFL.

I wouldn't discourage the use of these elements, just caution that they be used intelligently. But intelligently can have different meanings.

[pe-ro]

I'm wondering (assuming the addition of <notehead>, <stem> and <flags> as children of <note>) if we can exclude these from <app>. It seems to me that since these things (along with <accid> and <dot>) influence the fundamental "character" of a note (as opposed to <artic> which affects only its performance), a change in their presence or value imply a completely different note, not the same note with a different rendering. Referring to Jo's Beethoven example, the addition of a flag may be seen (and perhaps, encoded) as a simple graphical change. BUT, there's a more fundamental change going on that should be represented by two different note elements. If the proposed elements are excluded from <app> (and maybe from <add>, <del>, etc.), then the encoder is guided toward this world view. If not, then we open up the possibility of confusion between the purely graphical and the "meaningful". I think this is what frightens Jo (as it does me too).

Does anyone have strong objections to

<app>
  <rdg>
    <note dur="4">
      <!-- with descriptions of notehead, stem, flags, etc. -->
    </note>
   </rdg>
    <rdg>
      <note dur="8">
        <!-- with descriptions of notehead, stem, flags, etc. -->
      </note>
    </rdg>
</app>

as opposed to

<note>
  <app>
    <rdg>
      <!-- description of notehead, stem, flags, etc. -->
    </rdg>
    <rdg>
      <!-- description of notehead, stem, flags, etc. -->
    </rdg>
  </app>
</note>

or a similar approach using <add>, <del>, etc.?

Since all the attributes of <note> are optional, this latter encoding is possible. BUT, it gives the visual rendition of the note precedence over its logical qualities and leaves too much implicit in the encoding, therefore making the encoding less useful. I just haven't figured out a remedy that doesn't create other aches and pains.

[kepper]

Well, let me contradict myself. I agree that adding a flag significantly changes the character of a note. However, this is already a conceptual approach that may not be appropriate for every project under the sun. I know you'd like to restrict the possibilities for abusing edit.trans markup (app/rdg, add, etc.), but I don't think that's feasible. Probably, the best we can do is to add a whole lot of Schematron rules to prevent "false" nesting. I can see good arguments for something like

and I don't think we can really determine a reasonable point where this stops making sense. Again, I would suggest to use Schematron to prevent the use of attributes and elements, but the reason to have those extra child elements (at least for CMN) is the additional flexibility to address complicated situations. Restricting the possibilities thus seems counter-productive. Channeling them, or better: providing guidance through Schematron seems more worthwhile to me.

In some sense, this all comes down to the problematic preference for mei-all.rng by many people. We need to improve our communication that mei-all really shouldn't be people's starting point to work with MEI. If we could make them use a mei-cmn-standard.rng versus a mei-cmn-advanced.rng (other repertoires following the same model) instead, the situation might be much better. We could even think about a system similar to the CC licenses for labeling schemas: two letters for the repertoire, another two letters indicating advanced encoding ( = much more elements allowed), two letters for inclusion of editorial markup, two for facsimiles etc. Such an approach could give a general sense of what can be expected from that particular schema. Even when people start to customize from one of those, it could be indicated accordingly. If we could come up with a obvious labeling system, it could help to better manage expectations, but also to prevent misuse / misunderstandings of how to use MEI appropriately.

Am 07.07.2015 um 00:16 schrieb pe-ro notifications@github.com:

I'm wondering (assuming the addition of , and as children of ) if we can exclude these from . It seems to me that since these things (along with and ) influence the fundamental "character" of a note (as opposed to which affects only its performance), a change in their presence or value imply a completely different note, not the same note with a different rendering. Referring to Jo's Beethoven example, the addition of a flag may be seen (and perhaps, encoded) as a simple graphical change. BUT, there's a more fundamental change going on that should be represented by two different note elements. If the proposed elements are excluded from (and maybe from , , etc.), then the encoder is gui ded toward this world view. If not, then we open up the possibility of confusion between the purely graphical and the "meaningful". I think this is what frightens Jo (as it does me too).

Does anyone have strong objections to

<app

<
rdg

<

note dur="4"

</

note

</
rdg

<

rdg

  <

note dur="8"

  </

note

</

rdg

</
app>
as opposed to

<note

<
app

<

rdg

</

rdg

<

rdg

</

rdg

</
app

</
note>
or a similar approach using , , etc.?

Since all the attributes of are optional, this latter encoding is possible. BUT, it gives the visual rendition of the note precedence over its logical qualities and leaves too much implicit in the encoding, therefore making the encoding less useful. I just haven't figured out a remedy that doesn't create other aches and pains.

—
Reply to this email directly or view it on GitHub.

[pe-ro]

I think we're in agreement: additional elements inside <note> for head, stem, and flags provide a great deal of encoding power, but power in the hands of the uninitiated they're problematic. So, encoders need guidance -- via Schematron, documentation, etc.

I also agree that mei.all is over-used and that it would be good to make some "pre-cooked" customizations available, but this is not a complete solution to the issue. (I hesitate to call it a problem as it's part of the design of profile-based systems like MEI and TEI.)

When the customization service is back up, it will be technically easy to create sub-set schemas. The major question is where to put them and how to maintain them. Should creating these be part of the build system the way MEI-cmn, -neumes, and -mensural are now? Which customizations should we make? What gets left out?

[kepper]

You're right, we're in agreement. It seems we've gone a long way in this ticket, and I hardly remember what actually started this discussion. Maybe someone who's more familiar with all these possibilities can move this into a separate ticket, with a more appropriate title?

What I would hope to get is a simplified version of roma, that is, a website where the user gets a very brief explanation of the purpose of each module, and a toggle button to turn on or off that module. Some presets can be provided (and explained), but this should be rather simple to implement – both the user interface and the "backside preparation" of the corresponding scheme. However, we don't need to rush this, I'd say. Let's get straight with the next release first…

Am 07.07.2015 um 17:27 schrieb pe-ro notifications@github.com:

I think we're in agreement: additional elements inside for head, stem, and flags provide a great deal of encoding power, but power in the hands of the uninitiated they're problematic. So, encoders need guidance -- via Schematron, documentation, etc.

I also agree that mei.all is over-used and that it would be good to make some "pre-cooked" customizations available, but this is not a complete solution to the issue. (I hesitate to call it a problem as it's part of the design of profile-based systems like MEI and TEI.)

When the customization service is back up, it will be technically easy to create sub-set schemas. The major question is where to put them and how to maintain them. Should creating these be part of the build system the way MEI-cmn, -neumes, and -mensural are now? Which customizations should we make? What gets left out?

—
Reply to this email directly or view it on GitHub.

[ahankinson]

I have thought about a customization service where you can turn on/off modules. It would be a bit tricky since you would have to generate the ODD customization file, which would mean likely starting with the MEI-all template and then automatically commenting the disabled modules via an XSLT.

However, for this I would suggest just quickly filing an issue on the customeization repository as a feature request.

[pe-ro]

Yeah, I figure that’s how it has to work. Having a look at the TEI process probably wouldn’t hurt, too.

[kepper]

I'm happy to write that XSLT. It would require some parameters from the website, indicating which modules to drop. You just need to specify in which way it is most comfortable for you to pass along that info. The task should be simple enough to be doable with XSLT1.0, if that helps for the workflow�

Am 07.07.2015 um 17:48 schrieb Andrew Hankinson notifications@github.com:

I have thought about a customization service where you can turn on/off modules. It would be a bit tricky since you would have to generate the ODD customization file, which would mean likely starting with the MEI-all template and then automatically commenting the disabled modules via an XSLT.

�
Reply to this email directly or view it on GitHub.

[pe-ro]

I’m not sure what you mean by starting “with the MEI-all template”. As long as the modification is limited to turning off modules, I think it could be as simple as creating an ODD customization file that contains nothing but elements for the desired modules. This could be generated by applying an XSLT to the mei-source.xml file.

[raffazizzi]

Hi, I'm just catching up with this discussion.

I wonder if the proposed @smuflname and/or @smuflcode should allow multiple values for combining glyphs. This may help avoiding having to match SMuFL's granularity. And it would certainly be useful for ornaments (see #241). SMuFL is uniquely concerned with the graphemic domain. We shouldn't jeopardize MEI's modelling of music notation to match SMuFL's.

I enjoyed your exchange about expressing some note properties as elements and I think I am in agreement too. Besides worrying about the uninitiated user, we should probably also keep in mind tools that read and write MEI as well. The more we add multiple ways of encoding the same thing, the more generic tools will have to either support all, or be specific about what they do or do not support. There is always ODD to the rescue, I suppose...

If new elements like <notehead>, <flag>, etc. are added to a new module, we should be specific about the module's role. Will it exist specifically to allow descriptive (probably mostly editorial) markup for these note components? Or do we imagine that it could be used for other less descriptive reasons? For example it could be used to map specific SMuFL code-points to these components (which is what I supposed got the conversation started...). Is that something that we really want? It may result in multiple ways of modelling a note without any specific descriptive reason for doing so...

[pe-ro]

Allowing multiple values in @smuflname and @smuflcode would, as you say, support combining glyphs. I see how could work for <trill> or a generic <ornam> element, but I'm not so sure about using it on something like <note>. Doing so could provide a "stop gap" solution, but I think we'd eventually have to deal with the cognitive dissonance it would create anyway. In the proposals / discussion of the mensural IG, we're already seeing the need for increased granularity. Why not allow in CMN (and beyond) as well?

Adding some new elements for the components of <note> and <chord> is not a drastically different thing -- we've already done this by allowing <accid>, <artic>, and <dot>. The element vs. attribute issue remains the same -- each one is appropriate for some uses. I think the new <notehead>, etc. elements will/should eventually "win out" mostly because they provide a higher level of granularity; that is, it becomes possible to assign attributes to them. They also provide the added benefit of being easier to handle in terms of editorial intervention -- we just have to be careful about how we deal with them. I believe, for example, that by continuing to treat duration as an attribute, we're effectively restricting the use of <headshape> to the visual domain, especially when it's inside one of the editorial or transcriptional elements like <supplied> or <rdg>.

I don't think these new elements belong in a new module -- in fact, I believe they're revisions to the core. With the addition of these new elements, I think we should re-think the need for and the domain assignments of many attributes. Moving @accid, @artic, @slur, etc. to the analytical domain would encourage the use of elements over attributes and begin to eliminate the need to support 2 ways of dealing with these things (and others). The attributes wouldn't go away; they'd just be de-emphasized.

Just to clear up any potential misunderstanding, I'm suggesting the addition of an element called <flags> (with an 'S'), not <flag>. In other words, the element would describe the number, shape, etc. of all flags as a group. There would not be an individual element for each flag. Also, <flags> might be better situated as a child of <stem>, rather than directly in <note>.

[pe-ro]

@lpugin, you want to jump in here?

[lpugin]

It seems to me that the SMuFL codepoints and the introduction of new elements are two different things (even though not completely unrelated, I agree). I don't think we need to rush for the SMuFL addition. Maybe we should wait until we have a clearer idea on what to do with it. By introducing the topic at MEC we wanted to make sure we do not duplicate things that are already defined in SMuFL. The noteheads example is a good one.

Concerning the introduction of new elements, my view on this is that I would introduce them only when they are needed to represent something that cannot be done with attributes. When it comes to encode different "version" (e.g., different noteheads), I would prefer to just move up the split to a higher level as suggested by @pe-ro . That is,

<app>
  <rdg>
    <note dur="4" headshape="circle" />
  </rdg>
  <rdg>
    <note dur="4" headshape="diammond" />
  </rdg>
</app>

Instead of

<note dur="4">
  <app>
    <rdg>
      <headshape value="circle" />
    </rdg>
    <rdg>
      <headshape value="diammond" />
    </rdg>
  </app>
</note

[pe-ro]

I get where you're coming from, Laurent, but (and here we go with the interconnectedness of all these things), if we consider the needs of the black mensural notation crowd (and the not-yet-created postmodern notation IG), there will either have to be an increase in the number of elements or an explosion in the number of attributes for visual qualities. My thinking is that a small increase in the number of elements (with added attributes) is better than a large increase in the number of attributes on existing elements. The fact that it makes MEI and SMuFL mesh better is another point in its favor.

[ahankinson]

I'll chime in to say I feel a bit uneasy about favouring sub-element encoding over attribute encoding. One of the best design features of MEI is, in my mind, the clear separation between the object and an object's properties via the use of elements/attributes where appropriate. This makes MEI much more human-readable and easy to understand.

I do undertand the need to talk about certain features as their own object (stems, flags, accidentals, etc.). However, I would really stress the need for caution here -- as I understand it, the use of attributes was purposefully chosen for specific reasons, and making them second-class citizens would be a step backwards in many ways.

[kepper]

I whole-heartedly agree. We are in a dilemma here, having to balance quite different expectations and requirements. We probably all agree that in most cases, attributes will be absolutely sufficient, but we also recognize that there are cases where additional granularity is needed. At the same time, it seems like a good idea to use one approach (either attributes or elements) consistently throughout one project, since this makes it much easier to chew these files with an application. However, my experience is that this sometimes just doesn't work, at least not in projects that do more or less manual encodings of sources instead of generating the encodings by OMR or from an existing dataset. The problem there is that you ultimately know your encoding guidelines when you're done, not when you start. Part of the deal is that you revise your guidelines, and adjust them to the issues you encounter while working with the sources. In this scenario, you go back and forth between different encoding concepts anyway, and sometimes just for one processing step in the middle.

I don't believe that this is a solution for every project, but MEI allows to combine encoding concepts (i.e. "let's do ties as attributes as often as possible, but use an element when there is something to be said about a particular tie"). It is not upon MEI to prioritize any of the existing encoding models � we can only provide arguments for their applicability in specific situations, i.e. provide guidance. If people decide to use MEI like MusicXML (with all these elements, we're getting there�) for a simple "Mary had a little lamb", it's their decision � even if (or if not?) we all clearly prefer the attributes we had so far. We can provide some arguments, but the decision is ultimately not ours � given we decide that there's a general need for those elements in all MEI, not just in the mensural part.

Some more thoughts on the model:

From my Beethoven perspective, it seems half-hearted to do only instead a . If we encounter a situation where one flag is added to an 8th, potentially in a different medium, attributes on one combined element don't help much. If this requires to replace one with another , I could equally well go up another level and replace the .

Putting the / on a stem seems reasonable. In case we decide to do , we could require them to be in order (from the closest to the note head to the most distant or vice versa). However: Could we imagine a situation where a composer just wrote some flags, without a stem? Where would it appear then � in , or in a with no other information provided?

The same problem of placement arises for stems. Mr. Beethoven often wrote nothing but stems � no notehead on either end. I'm sure other composers did that as well. While in our project, we decided to not mimic this level of openness in the MEI (but instead provide our interpretations, linked back to the shapes traced with SVG), others may want to do that. What scares me is that we're starting to decompose MEI as "music encoding" format, turning it more and more into a "graphics encoding" format. Like I said earlier, in Beethoven, we're effectively replacing the complete when the duration changes. This is something we've been discussing for quite some time (and still question now and then), but I believe it's just a matter of perspective: Do we try to transcribe the source as it stands, or do we provide an interpretation of it? At the level of complexity that many of Beethoven's manuscript offer, these things turn out to be different, and we clearly decided to do only the latter with MEI, and delegate the first to SVG. While the scriptural intervention might have been minimal, our interpretation is something quite different � an 8th instead of a quarter. However, they still refer to the same graphical object(s) on the page, and I could retrieve them from our encoding.

To make a long story short � while I see great benefits in having those additional elements also in CMN, I still hesitate to include them. In our project, we considered the addition of such elements, and clearly decided against them, because they would bloat our data model very drastically. However, I don't want to restrict others to a decision that was made for one very specific project. All I can say is that at this point we would probably not use the proposed elements�

jo

Am 09.07.2015 um 09:57 schrieb Andrew Hankinson notifications@github.com:

I'll chime in to say I feel a bit uneasy about favouring sub-element encoding over attribute encoding. One of the best design features of MEI is, in my mind, the clear separation between the object and an object's properties via the use of elements/attributes where appropriate. This makes MEI much more human-readable and easy to understand.

I do undertand the need to talk about certain features as their own object (stems, flags, accidentals, etc.). However, I would really stress the need for caution here -- as I understand it, the use of attributes was purposefully chosen for specific reasons, and making them second-class citizens would be a step backwards in many ways.

�
Reply to this email directly or view it on GitHub.

[zolaemil]

Jo

Do we try to transcribe the source as it stands, or do we provide an interpretation of it?

Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter. On the other hand, the question is where is the border line between the two? I always wondered about the post-CMN notation in MEI, and I am glad that Perry mentioned "the not-yet-created postmodern notation IG". The further we go from CMN, the more important the graphical nature of the score becomes - think of graphical scores at the extreme!

These are just thoughts though, with admittedly little argumentative value regarding the debate whether it's useful introduce stem elements in the CMN module.

My gut feeling is that they would be useful. Re vs. debate, would you think a structure like:

<flags>
  <flag/>
  <flag/>
</flags>

would be an overkill? (Child elements obviously optional, and attributes on flags could also be used instead)

[kepper]

Am 09.07.2015 um 11:42 schrieb Zoltan Komives notifications@github.com:

Jo

Do we try to transcribe the source as it stands, or do we provide an interpretation of it?

Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter. On the other hand, the question is where is the border line between the two?

I strongly believe there is no natural border, and it is upon us to draw the one we want – which makes it so hard to decide…

I always wondered about the post-CMN notation in MEI, and I am glad that Perry mentioned "the not-yet-created postmodern notation IG". The further we go from CMN, the more important the graphical nature of the score becomes - think of graphical scores at the extreme!

Well, there is certainly room in MEI to cover parts of that, but I doubt that we can come up with an encoding standard for non-recurring notational systems, made up for just one score. I believe that if we want to do so, it becomes even more important to work with abstractions, that is, not encode the appearance (at least not with MEI), but instead its "meaning" (whatever that means…). However, drawing a border between semantics and graphics in this area isn't simple either…

These are just thoughts though, with admittedly little argumentative value regarding the debate whether it's useful introduce stem elements in the CMN module.

My gut feeling is that they would be useful.

same for me – I'm just concerned about the potential (bad) consequences, and if they justify to take this approach in areas where we seem to have no real-world use-case yet. We could introduce it for mensural, but wait for other repertoires…

Re vs. debate, would you think a structure like:

would be an overkill? (Child elements obviously optional, and attributes on flags could also be used instead)

fine with me.

—
Reply to this email directly or view it on GitHub.

[raffazizzi]

Your question reminds me to Elena's keynote at MEC, where she clearly put her penny down beside the latter [rv: to provide an interpretation]. On the other hand, the question is where is the border line between the two?

Perhaps unsurprisingly, given that Elena is my teacher, but I argue that text encoding is always a tool for formalizing interpretation. The encoding always crystallizes an interpretation, regardless of whether the intention is transcribing the source as it stands (rather: as you think it stands) or to provide a more hands on interpretation of it. It is impossible to create an unbiased model of a cultural object, even more than it is impossible to take an unbiased facsimile photo of it.

A stem is a stem because we decide it is a stem and not a random mark on the page. You have to argue for that interpretation even if it's obvious. Your encoding formalizes your conscious choice.

I'm not opposed to adding elements in principle, but there's plenty more to consider. A couple of things that come to mind:

• note property attributes should really be encouraged over elements, so they should probably be in a module that is turned off by default. I agree that MEI wants to be agnostic about which structures to use and in what combination, but this may be the one case where we can't be. These elements should be used if they're truly needed. Maybe a primary source encoding module?
• this will be a change that messes up backwards compatibility. Now we have <dot/> for very similar reasons and dots can be mixed with articulations, etc. in the body of <note/>. So to be consistent, we should model <flag/> after <dot/>. But that would result in a disorganized body. Or we'll have to at least have <dots/> if we go with <flags/>. Or we'll have to create new elements for organizing the different components of the note. Either way, the current status of <dot/> will have to change in a non-backwards compatible manner. Or is there another way that I'm not seeing here?

[pe-ro]

Raff, I see your reasoning here re: <flag> vs. <flags>, but I still think that may be a step too far.

I agree that we should investigate the possibility of putting these new "granularity" elements in some kind of module so that they can be isolated from "core" MEI.

I'm not in a great rush to take this path; i.e., going toward a more element-centric encoding, but in light of the fact that MusicXML and SMuFL are "teaming up" so to speak, we have to react if we expect to play nice with the commercial sector. And as I stated earlier, addressing the needs of additional uses; e.g., black mensural and lute tablature, is a significant factor.

We can talk this thing to death or we can start doing something about it -- I suggest the latter. But, I for one am "dead in the water" when it comes to creating test customizations without a working customization service. Let's table this discussion until that's working again and move on to other issues.

[lpugin]

We can open it again if necessary

[pe-ro]

Now that the customization service is humming along again (thanks to Andrew and Raffaele), I'd like to reopen this issue and provide a customization that supports SMuFL. Can I attach files here?

[pe-ro]

The markup below demonstrates the SMuFL capabilities I've been talking about. <note> now allows <notehead> and <stem> children. Schematron is used to constrain the use of <notehead> to a single occurrence. Also, while <stem> can occur as a descendant of <app>, <notehead> cannot. In addition, <stem> can only be used when it is a descendant of <note>, meaning that it can occur within <app>, but only if the <app> is within <note>. <flags> is only allowed as a child of <stem>, making it impossible to describe the difference between readings as one involving only stems, in the same way that one can't describe the difference between readings as one between noteheads alone. In both these cases, one is forced to utilize <note> elements, the basic idea being that if notes differ with respect to their noteheads (where there is potential for difference in semantic meaning), they are different beasts.

In addition to the changes to support SMuFL, @headshape on <note> has been pulled apart into multiple attributes -- @head.shape, @head.fill, @head.fillcolor, @head.mod, @head.visible, and @head.color (in keeping with the issue that addresses a revamping of data.HEADSHAPE). With respect to color, the idea is that @color affects the color of all parts of the note, unless a more specific attribute is used. So, @head.fillcolor would change the color of the inside of the note, leaving the outline and the stem in the original color. If @head.fillcolor is used in the absence of @color then a default color is presumed.

Not every attribute available on <notehead> and <stem> is available on <note> and <chord>. The intention was to continue capturing the same data that we've been gathering (albeit with more attributes now) and to employ the same strategy as that used for <accid>, <artic>, and <dot>; that is, if you want to capture more detail than is allowed using attributes, then you must employ child elements. For example, in the same way that if you want to specify the color of an accidental you have to use <accid> instead of @accid, if you want to capture the color of a stem, then you must use <stem> and not the @stem attributes. **NB: I just noticed that <stem> isn't allowed as a child of <chord>, but I think that's easily remedied.

Only a single <flags> child is allowed within <stem>; however, its attributes are allowed to take multiple values. This is in keeping with the way staff/@lines.color is handled. The number of values should agree with the number of flags. Although I haven't yet been able to come up with one yet, it would be great to have a Schematron rule that makes sure that if any attribute on <flags> has multiple values, then all attributes have to have the same number of values. I'd appreciate help with this rule, as I don't have the slightest idea how to write it, but I think it involves the use of SQL.

Looking at the figured bass markup at the end of the example, you'll see that there are a couple of ways of using SMuFL within text. One is to use the Unicode character entity for the thing you want to insert (ਖ਼ in this example, although I'm not sure if this is the proper way to address characters in the PUA). Another option is to use the <symbol> element (which can now appear within text). The advantage of this method is that you can then use the full range of attributes on <symbol>.

You'll also notice in this example a nod toward supporting black mensural notation. For example, flags/@shape allows values appropriate for this repertoire. What you can't see (without access to the schema that the example validates against), is that stem/@dir supports a much expanded set of values -- "up, down, left, right, ne, se, sw, and nw" -- that when taken in combination with stem/@pos allow for virtually every kind of weird stem that one can imagine being given for a single note. (Stems for chords containing augmented unisons is yet to be addressed.) Multiple stems found in this repertoire are supported by allowing multiple occurrences of <stem> within <note>. My plan is to restrict this for CMN in the mei-CMN customization.

I've tried to consider the objections raised during the discussion while also moving toward a level of granularity that makes it possible to intuitively support SMuFL. I don't believe some kind of multi-valued attribute, say on <note>, that captures any/all pertinent SMuFL code points is particularly "intuitive". I don't think I've added any new complexity that wasn't already inherent in the system once <note> and the children of <app> were allowed to contain <accid>, <artic>, and <dot>.

I'm eager to hear any comments. And, even though we're supposed to keep the addition of new features to a minimum, I'd like to put this into the next release. This would put us miles ahead of our competitors in the support of SMuFL. ;-)

<staff xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.music-encoding.org/ns/mei">

  <layer>
    <chord stem.dir="up" stem.mod="1slash" stem.len="7.5mm">

      <note head.shape="backslash" head.fill="solid" head.fillcolor="purple" head.mod="paren"
        head.visible="false" stem.pos="right" stem.dir="down" stem.len="7.5" stem.mod="1slash"
        stem.with="above" artic="acc bend" accid="f" color="blue" colored="true" enclose="brack"
        smufl.code="#xE1D6">

        <notehead color="aqua" mod="circled" rotation="45" shape="square" smufl.code="#xE0AB"/>
        <!-- Schematron prevents notehead from occurring more than once within note -->
        <!-- <notehead/> -->
        <stem color="black" pos="center" dir="down" len="7.5" mod="1slash" visible="true"
          with="above" smufl.code="#xE219">
          <!-- Need constraint that makes sure all flag's attrs have multiple values if one attr has multiple values -->
          <flags color="fuchsia green" fillcolor="gray green" pos="left right" shape="straight
            hooked" smufl.code="#x1D1EA" fontname="BravuraText"/>
        </stem>
        <stem color="red" pos="center" dir="up">
          <flags pos="end" color="red"/>
        </stem>
        <accid />
        <dot fontname="myOwnFont" fontsize="33"/>

        <app>
          <rdg>
            <dot/>
            <stem/>
          </rdg>
        </app>

      </note>

    </chord>

    <app>
      <rdg>
        <dot/>
        <!-- Schematron prevents stem from occurring unless it's the descendant of a note -->
        <!-- <stem/> -->
      </rdg>
    </app>

    <harm tstamp="1">
      <fb>
        <f>
          <choice>
            <orig><rend fontname="Bravura"><symbol smufl.code="#xEA59" smufl.name="figbass5Raised2"
                /></rend></orig>
            <reg><rend fontname="Bravura">&#xA59;</rend></reg>
          </choice>
        </f>
      </fb>
    </harm>

  </layer>

</staff>

[raffazizzi]

Hi Perry, looks like terrific work. A few comments and questions:

Schematron is used to constrain the use of to a single occurrence.

Why is Schematron needed for this?

the basic idea being that if notes differ with respect to their noteheads (where there is potential for difference in semantic meaning), they are different beasts.

I agree with this and I think it helps to avoid proliferation of unnecessary add/rdgs

In addition to the changes to support SMuFL, @headshape on <note> has been pulled apart into multiple attributes -- @head.shape, @head.fill, @head.fillcolor, @head.mod, @head.visible, and @head.color

This worries me and I see it as a regression. It's very procedural markup and I wish this information lived outside of MEI in a CSS-like document. This also includes other attributes like @fontname. I didn't mind this kind of markup on <rend> because MEI is not for text encoding, so some procedural markup in that domain is tolerable. But this is procedural markup in the music notation and I don't like it. I understand the pressure to support SMuFL ASAP, but it shouldn't come at the cost of descriptive markup. I'm also not a fan of having @sumfl. attributes and I think a <symbol>-based solution is way better, but it looks like I'm alone in this so be it :)

The number of values should agree with the number of flags. Although I haven't yet been able to come up with one yet, it would be great to have a Schematron rule that makes sure that if any attribute on has multiple values, then all attributes have to have the same number of values.

It sounds doable with XPath, something like (it may be a report rather than assert, I always mix them up):

<sch:rule context="mei:flag">
   <sch:assert test="
        if (count(distinct-values( 
            for $att in @* return 
                 count(tokenize($att, ' '))
            )) > 1)
        then false()
        else true() ">All attributes must have the same number of values</sch:assert>
</sch:rule>

use the <symbol> element (which can now appear within text)

Hurrah! This makes things a bit easier for <ornament>, too (see #254).

stem/@dir supports a much expanded set of values -- "up, down, left, right, ne, se, sw, and nw"

Honestly, I wouldn't mind having these values added to the datatype for @place. The question is, though, where do we stop? E.g. "I want s-se".

---

To conclude, I think there are parts of this customization that do not belong to MEI, but rather to an external CSS-like specification. I'm referring in particular to the proposed attributes on note to describe color, fill, visibility, and font face . Why don't we work together on a CSS for MEI instead? It could be expressed in XML (as an MEI module, say), but it needs to be stand-off and replaceable.

On the other hand, the segmentation into multiple elements for <note> is still grounded in the descriptive domain, and it will make more detail encoding possible, so I welcome those upgrades.

[pe-ro]

Thanks. I put some effort into it. :-)

I used schematron to constrain the occurrence of <notehead> in order to simplify the content model of <note>. The content model of <note> is kept simple (in DTD-like syntax):

(notehead | stem | model.noteModifierLike | model.verseLike | model.sylLike | appLike | model.editLike | model.transcriptionLike)*

so that the order of the content isn't significant. But, the number of occurrences of any <note> child elements isn't controlled. Hence, the need for schematron. The answer to the more general question, Why should a note have only one notehead? is that if there's more than one notehead on a stem, then MEI calls that a "chord". :-) A similar principle is at work with regard to <stem>; that is, in CMN a note can only ever have 1 stem. A note with 2 stems is an indication of overlapping "layers". A schematron rule for this must be added in the CMN customization, however. Adding it in the MEI "core" would disallow the use of multiple stems in mensural notation when using the mei-all schema.

You're definitely not alone in your desire to encourage people to use descriptive markup. But, there are instances where a description (and I use that word intentionally) of the physical attributes of the notation is the best that can be done. I still see this as descriptive markup. Because music data objects, like <note> have no content to wrap something like <rend> around (and wrapping <rend> around <note> leads to an insanely complex data model), the attributes allowed on <rend> must be moved up in the hierarchy to the object itself (in this case, <note>). The same thing happens on <artic>, <accid>, and so on and so on ... In fact, placing these attributes on the object reinforces the idea that their content is descriptive and not necessarily renditional. I would never encourage someone to use these attributes to describe intended output. That is the province of a stylesheet or style language.

You're also not alone in your desire to encourage the use of the @altsym/symbolDef approach. I didn't put it into this proposal, but my intention is to also expand the role of <symbolDef> by making it more like TEI's <charDecl> element. That is, using @altsym to point to a <symbolDef> which, in turn, either references a code point in SMuFL (or similar system), provides a vector graphic (in SVG), or describes the symbol using text. The @smufl.* attributes are just a short cut for those who don't want the overhead of using <symbolDef> for common cases.

Re: schematron for the attributes on flags -- the more I think about this, the less desirable it becomes. I'm inclined to leave it out for now. In any case, distinct-values won't work because some flags might be the same color (for instance) -- color="blue red blue" is 3 values, not 2. :-)

I'm inclined not to add the extra values allowed by stem/@dir to @place because @place is exclusively for specifying the relationship between an object and its staff -- what does it mean to say that an accidental is southwest of the staff? As for where to stop, I think the current set of compass points is generous. Any other direction/vector could be expressed as rotation from "north". But that's for a much later version of MEI. :-)

[raffazizzi]

Re: schematron for the attributes on flags -- the more I think about this, the less desirable it becomes. I'm inclined to leave it out for now. In any case, distinct-values won't work because some flags might be the same color (for instance) -- color="blue red blue" is 3 values, not 2. :-)

No, it will work: distinct-values() is applied to the count of tokens, not to the values. Basically given two attributes with values "a a" and "b c", the XPath first counts the number of values for each attribute and returns a sequence: (2, 2). Then distinct-values() makes sure that all counts are the same: distinct-values((2, 2)) returns 2. A final check makes sure that distinct-values() only returned one value (so the attributes have the same number of token values).

If we had two attributes with values "a b" and "c", the count would have returned a sequence of (2, 1), thus distinct-values() would return (2, 1) and cause the final check to fail.

I'm sure there's a less complex solution, but this should do :)

I'm inclined not to add the extra values allowed by stem/@dir to @place because@place is exclusively for specifying the relationship between an object and its staff -- what does it mean to say that an accidental is southwest of the staff?

But what about an ornament that is placed to the left of the note? This makes me wonder if @place would be better defined as relative to the element it is placed on, rather than the staff.

For the rest, I think I'm OK with the proposal, unless someone else has other views on the procedural/descriptive debate... @kepper?

Have you been working on a branch for this ODD? Maybe you can send a Pull Request so that we can look at the code too? Happy to help through the process via email, if needed!

[pe-ro]

Ok, I'll take your word on the distinct-values() issue. Still, I think this particular schematron constraint isn't necessary.

[pe-ro]

Closed by commit de72af3