Slurs with contradictory startid/endid and staff attributes

[lpugin]

It seems that the musicxml2mei stylesheet generates sometimes contradictory attributes regarding the positioning of slurs. Slurs have always startid/endid attributes and timestamps and staff attributes. In some cases, the staff value do not correspond to the staff of the startid. See measure 17 (startid="#d648110e5686" and staff="4") https://raw.githubusercontent.com/music-encoding/sample-encodings/master/MEI%203.0/Music/Complete%20examples/Brahms_StringQuartet_Op51_No1.mei

I don't see the reason to duplicate the information using startid/endid together with timestamp. I would rather recommend to use either one. This would avoid this type of situation and/or the need to define an order of precedence to apply when the information do not match.

[pe-ro]

Don't you hate it when that happens? :-)

Duplication is not the problem. The actual problem is the erroneous calculation of the value of @staff. I wonder if we should just throw away this stylesheet and start again.

[pe-ro]

A couple more thoughts --

It's a shame we didn't preserve the MusicXML files for these examples because the problem might not lie in the stylesheet, but in the original MusicXML instead. I'm just sayin'. :-)

Also, could we turn this into a validation issue by adding a schematron rule that makes sure that @staff contains a value that matches that of the target of @startid and @endid? It wouldn't fix the error of course, but it would alert one to the fact that an error exists.

[lpugin]

This is where I am not sure about the utility to always duplicate the information. Per se it is not a problem, but it will inevitably yields contradictory situations since validating and maintaining duplicated information is always an issue. This is often the case with MusicXML data. Information is duplicated, but will still don't know what to expect.

I would rather have guidelines clearly specifying when duplicate and contradictory information can be useful. I can see cases for it. For example, using startid for precisely encoding the start position, and then staff="1 2 3 4 for encoding to what staves it applies. If we are clear about this in the guidelines, we do not have to discuss which one has the precedence or have a schematron rule for verifying that the information is contradictory (since we might want this).

I still cannot see the use of having both startid and tstamp (and endid and tstamp2 respectively). Any example?

[pe-ro]

I can't think of a reason right now to record both @startid and @tstamp (or @endid and @tstamp2) as they are closely related (though not quite the same thing since tstamp's value can be deduced from @startid, but not the other way around). However, that doesn't mean such a reason might not exist.

I agree that it would be a good idea to put something in the Guidelines about when to choose each combination -- start/end ID or tstamp/tstamp2. Where would be the most appropriate place?

We could also add a switch to the MusicXML -> MEI stylesheet which allows the user to choose one approach or the other (in fact, it would throw away the one not selected). In addition, I wouldn't object to a schematron rule that issues a warning (but not an error) if both sets of attributes are present.

[lpugin]

For the guidelines, I think the best place would be in section 4.1.5 Timestamps and Durations.

A switch would be ideal. You would probably also want to be able to choose between <tie> vs @tie since these also get duplicated.

[lpugin]

Moved to music-encoding