<directions> (global). Explicitly encode location: left or right?

[cecilios]

<directions> defined in <measure> (global) go in different locations, some at start of measure, e.g. <time signature=...>, and others at end of measure, e.g. <jump type="dsalfine"/>. But if all directions goes in a single <directions> container in a <measure> (global) this creates ambiguity about the direction location, and the location of each child must be decided by the consumer application based on child type and context.

Perhaps it would be better to explicitly define the location by using an attribute. e.g.:

   <global>
      <measure>
         <directions location="left">
            <time signature="4/4"/>
         </directions>
      </measure>
      <measure>
         <directions location="left">
            <segno/>
         </directions>
      </measure>
      ...
      <measure>
         <directions location="left">
            <time signature="4/4"/>
         </directions>
         <directions location="right">
            <jump type="dsalfine"/>
         </directions>
      </measure>

A default value could be defined for most common cases, e.g. "left"

[clnoel]

Don't we already have a "measure location" data type for this, where 0 = at or just after the left barline and 1 = at or just before the right barline?

[cecilios]

Thanks Christina. My point is not about what data type to use or what values to place, but about the convenience of this separation and if convenient, the need to mandate it.

It is true that there is a measure locator data type but <directions> (global) doesn't have any attributes (at least this is what current documentation says https://w3c.github.io/mnx/docs/mnx-reference/elements/directions-global/ ), so 'location' is not a valid attribute for directions.

Also, the specification does not mention that this separation is required. In the MNX examples, e.g. this one https://w3c.github.io/mnx/docs/mnx-reference/examples/jumps-dal-segno/ , the <jump type="segno"/> element does not have any location defined, and the specification does not prevent placing it as the last element in the measure.

By the way, to my knowledge value 0 is start of measure but value for end of measure depends on the time signature, so value 1 would be the end of measure only for 4/4 time signature.

[joeberkovitz]

Is this issue more general: how can style attributes be attached to music content, and how/when is this information applied? The directions/left/right issue is just one case among many, isn't it?

[cecilios]

Is this issue more general ...?

@joeberkovitz No, my question was specific. I have started an implementation to get better knowledge about the different proposals (I'm not good at very abstract reasoning) and I found this problem: at which location should I place a direction coming from a measure global? Probably for some directions, deciding if it should go at start or at end is trivial. But I'm not sure if this is going to be the case for all directions. That's why I open this issue.

I don't see its relation with attachment of style attributes, to me location has nothing to do with styles or layout. So, perhaps it would be better to open another issue for attachment of style attributes if needed.

[samuelbradshaw]

If we go this route, I'd recommend the terminology "start" and "end," or "measure-start" and "measure-end," instead of "left" and "right," to provide more flexibility in sheet music for right-to-left languages.

[bhamblok]

I'm in doubt myself here...
Shall we continue making the same "mistake" as css is doing, and indeed use "start" and "end"?
Or shall we do it right ;-) and use the terminology: "begin" and "end" (or "start" and "stop")?

[cecilios]

Thanks for the comments. But before entering into the details it would be nice if we solve the main question:

Do you think it is necessary to classify directions in global measures into two sets, those that are associated to the start of the measure and other one for those associated to the end of the measure? Or is it simple enough for a consumer application to deduce the location and this is not needed?

If you are in favor of an explicit indication this can be achieved in different ways. Let's discuss it once the previous question is solved. Just an example of two simple possible options:

• make mandatory a that all children of <directions> have a location attribute (or other name) to explicitly say the position (begin/end, start/stop, other values)
• allow that global measures can have two <directions> elements, and request an explicit location attribute (or other name) on them to say the position (begin/end, start/stop)

[joeberkovitz]

This question was already addressed in the Draft MNX Specification here. Each child direction has its own mandatory location attribute. There is no default location value for a direction since directions in the general case cannot be classified into two sets. Nor are there only two sets, as many directions can occur mid-measure, for instance tempo directions (which for some reason have also been removed from the 1.0 specification).

I think it's unfortunate that this information seems to have been discarded in the migration to 1.0, and if there is a reason why then it would be good to understand.

Furthermore I do not think it makes sense to attach a location attribute to <directions>. This is intended as a container element for all global directions in a measure, so its children will often be placed at more than one location in the measure. Thus, putting location on <directions> is no more than a syntactic shortcut for placing all children in one location, but this creates more complexity with only a very modest gain in efficiency. Bad tradeoff.

[cecilios]

@joeberkovitz Thank you very much for all this information. I agree that <directions> should not have a location attribute if the children have it.

I'm having serious problems with the specification because I don't know which of the two papers, the one you pointed (the specification in old format, more complete) or the new paper (the MNX 1.0 draft specification in new format) is the valid one. There are important differences between them, for instance, this one of location attribute in children of directions. Also the examples in MNX by example do not help to solve this issue as, in line with the 1.0 spec., they do not include the location attribute (e.g. the Jumps (D.S. al Fine) example https://w3c.github.io/mnx/docs/mnx-reference/examples/jumps-ds-al-fine/ uses just a <jump type="dsalfine"/> without location and in my understanding, as its location is at the end of the measure, not at the start, it should include it.

I agree that if would be nice to know which information has been discarded and the reasons for it. And better, it should be clearly marked one of these two specifications as "Obsolete" or, if both are valid, it is urgent keep them synchronized. Current situation is not good as it is impossible to know with certainty what to discuss and improve. Also, in last meeting it was raised the issue of starting with tentative implementations, but without a clear draft specification this is an impossible task.

[samuelbradshaw]

I'm in doubt myself here...
Shall we continue making the same "mistake" as css is doing, and indeed use "start" and "end"?
Or shall we do it right ;-) and use the terminology: "begin" and "end" (or "start" and "stop")?

I don't have much preference, as long as we're consistent. Every language has its own convention. In CSS, it's start/end; In Swift, it's leading/trailing; etc. If you have a preference, I'm curious what your thoughts are on why one is better than the other.

[joeberkovitz]

@adrianholovaty I've added a new issue #253 to try to get clarity on the apparent missing info in the 1.0 spec.

I think it will help to first figure out what is missing and migrate it into the 1.0 spec before pursuing this directions issue further.

[cecilios]

@adrianholovaty Acording to your post in #253 (comment), how should we deal with this issue? Is still location a mandatory attribute for children of <directions>?

[joeberkovitz]

With respect to the begin/end question, see https://w3c.github.io/mnx/specification/common/#common-spanning-directions for the current definitions. The pair of spanning attributes is currently location and end. This is not a pair of opposites in English, but my thoughts at the time were 1) it would be a bad idea to have a different name for location when the direction spans a time interval, and 2) in the non-spanning case, start seemed quite wrong. Perhaps a new issue is the best place to capture objections to this design and other proposals.

[clnoel]

I looked at the newly migrating measure location data type and think that we need to make some changes.

1. I believe that a "left/right" option or a "start/end" option or a "first/last" option should be added. I'm not tied to the actual words one way or the other, but there should be an option for "just after the beginning barline" and for "just before the ending barline". In both of these cases we want the direction to be associated or aligned with a barline instead of the notes/events, and in the second case the actual measure location number changes depending on the time signature, which makes it hard to maintain.
2. (Might be out of scope for this issue) I believe that the eventref option should not be limited to the current measure, but should also have the option of being an eventref in another measure if the direction is inside a sequence. In this case, the referenced event must be inside a sequence with the same voice value. This lets things like octavas connect events in a voice more naturally.

[joeberkovitz]

@clnoel re (1), I have also seen the need for barline-relative locations, and agree that the present measure location definition needs some additional way to cover that. That is a slightly different issue than this one (which I think can be closed) and I would like to migrate that question to a new thread. Perhaps this can be thought of as a "measure-relative" location rather than a "barline-relative" location to avoid assuming that there are barlines. Also prefer "start/end" to avoid baking in a culturally specific reading order.

(2) I think you're right and at the very least, an end location can be linked to an event in a different measure. I don't see why not fold this clarification into the same new issue.

[cecilios]

This issue can be closed as soon as it is confirmed that children of directions have a mandatory location attribute. And then, perhaps it would be necessary to open an issue to fix all examples using directions in global measures, to add a location attribute to them.

[adrianholovaty]

In 1751e71 I've updated the spec to document the location attribute for the following direction elements —

• <fine>
• <jump>
• <segno>
• <tempo>

Note that this is just a subset of direction elements. For all others, I don't think a location attribute is meaningful. Here's the full list of other directions, with an explanation of why location wouldn't make sense:

• <time> — only one time signature is allowed per measure, and it's always at the beginning (location=0)
• <repeat> — start-repeat barlines are always placed at the start of the bar, and end-repeat barlines are always placed at the end of the bar
• <ending> — the ending applies to the entire measure and hence has no location
• <key> — only one key signature is allowed per measure, and it's always at the beginning (location=0)
• All direction elements that are within <sequence> — these are positioned by sequencing the content and hence do not allow a location attribute.

In 58d7153 I updated the appropriate examples to use location attributes (thanks for the reminder @cecilios!).

Marking this issue as closed now that this has been worked out. Please let me know if I overlooked anything.

[cecilios]

@adrianholovaty In elements <jump>and <tempo> the location attribute is marked as not required. Is this correct? If yes, perhaps a default value should be documented.

Edited to replace fine by tempo

[adrianholovaty]

@cecilios Thanks! I've fixed <jump> in 345d887. For <tempo>, it does indeed specify a default (zero).