Support measure_n attributes other than numbers?

[aerhard]

Currently, it's necessary in mei2vf that the measure n attributes read from the XML code can be converted to a number, because these numbers are used as array indexes. But the MEI datatype of the n attribute n is not numeric, but xsd:NMTOKEN, see [http://music-encoding.org/documentation/guidelines2013/att.common], so measure_1, 1a or auftakt_zu_1 would be valid n values in MEI, but wouldn't render in mei2vf.

[raffazizzi]

I'm ok with this. We can restrict the data type in the ODD. @zolaemil any thoughts?

[zolaemil]

I believe there's no place where we actually need to assume that it's a number. But as it is all over the place it will need a more careful look. But I think it wouldn't be a problem leaving it alone as a string.

The only thing that would change in the interface is that rendered_measures couldn't be an array any longer, but an associative array (aka object) indexed by strings. Again, I don't think the array-ness of this has ever been exploited, so this isn't a problem. If need be we can expose an array that indexes the staves according their position in the score.

[zolaemil]

One more comment: the most specific assumption about measure/@n is, I believe, the one when checking if it's the first measure https://github.com/TEI-Music-SIG/MEItoVexFlow/blob/master/src/Converter.js#L892
This of course can easily be written as a string comparison, but assuming the first measure is has n="1" seems to conflict with the otherwise non-restrictive approach (let alone the case when first measure is n="0" which is still a number), so we need to find a better way to check this condition.

[aerhard]

One more comment: the most specific assumption about measure/@n is, I believe, the one when checking if it's the first measure https://github.com/TEI-Music-SIG/MEItoVexFlow/blob/master/src/Converter.js#L892

I removed that passage from mei2vf in the latest pull request, so that wouldn't be an issue anymore. There's another passage depending on an organization of the measures in an array: https://github.com/TEI-Music-SIG/MEItoVexFlow/blob/master/src/Converter.js#L1003. It looks up the last addition to the MEI2VF.Converter.allVexMeasureStaffs by getting me.allVexMeasureStaffs[me.allVexMeasureStaffs.length - 1]. Changing this should not be a problem.
But there is one more thing: According to the guidelines, n attributes need not to be unique. Do you think that means that they are generally not suitable as array indexes / object names in mei2vf?

[zolaemil]

Yes, that's true. But maybe that restriction could go to the ODD? That is, "if you want to render something please make sure the measure numbers are unique": this requirement is probably not completely unreasonable. However, if it is unnecessary I wouldn't object switching to referencing measures by xml:id instead.

[aerhard]

I think requiring unique measure numbers is very plausible when you are dealing with only one musical 'piece'. In MEI, it makes sense not to require unique measure numbers globally, because there can be multiple pieces or movements in one file (each of which might start with M 1). So, do you think there should be support for multiple pieces/movements in one MEI2VF instance? (As far as there are no disadvantages to MEI2VF, I would not mind supporting it.)
Currently, in MEI2VF's MEI files, measure n attributes serve only as labels, that is, there is nothing pointing to a measure by its n. Other than staffs / layers, which can be addressed by a staff or layer attribute in other elements, there is no measure attribute in the MEI schema. I'm not totally sure about that, but if there is no such thing as a measureRef in MEI, it should be legitimate to only treat them as labels and address measures independently. That would have the advantage that users could name them whatever they like -- the script could cope with any numbering scheme.
So I like the idea of working with xml:ids. References to the measures are already stored in arrays in the MEI2VF.System objects, so there would be a way to get 'the previous measure to this one' and similar things.

[raffazizzi]

I also like the idea of treating @n as a label and not as an indicator of the order of the measure. The code should be rendering the measures in the sequence they appear, so that gives us the order.

rendered_measure could still be an array, but containing objects with a couple of properties for each measure, e.g. "n" and "order".

I'm not totally sure about that, but if there is no such thing as a measureRef in MEI, it should be legitimate to only treat them as labels and address measures independently. That would have the advantage that users could name them whatever they like -- the script could cope with any numbering scheme.

References should always be handled with xml:ids