Edirom
Bug: navigation via concNav in sources with parts at multiRests
Problem description see https://github.com/Max-Reger-Institut/Edirom-Online/issues/3
@bwbohl (and @feuerbart): Do we actually need to test for @label and/or @n values when we have parts?
Possible fix: https://github.com/Max-Reger-Institut/Edirom-Online/commit/e8622666efca86d663a0a5ef160967617f1b57a9
wouldn't this be a proper solution:
https://github.com/Edirom/Edirom-Online/commit/ffa0b56bddbf0b63e9033131ee6cf4c4351e3e65#diff-6c15f465cf43219c6f5de818ba16a6a1bda301ebc0dc21fc64f67857d75ef81dR37-R54
@bwbohl I don't think so. The problem is the "internalIDType". When we have parts with only measure/multiRests at a given measureNo and measure[multiRest]/@label or ./@n is something like "1–6" internalIdType will always be "unknown" because measureNo is a number value ( "1", "2", etc.) and @label/@n a string value. So for sources with such a constellation Edirom won't call getMeasures.xql (where the actual calculation of needed measures in parts takes place). I have a running example of this incident, but it is not publicly accessible yet. You know where to find me, to see it in action… ;-)
https://github.com/Max-Reger-Institut/Edirom-Online/commit/e8622666efca86d663a0a5ef160967617f1b57a9 would be my Reger-centric solution for this: just test if there are measure elements in this mdiv at all to get internalIdType = "measure", so getMeasures.xql gets executed.
But my question is: Are there any circumstances to consider when @label or @n values should be tested in getInternalIdType.xql?
I have thought about this again and so far for me there seems to be no case where my solution won't work. So @bwbohl and @krHERO, should I change the xQuery as I have done in https://github.com/Max-Reger-Institut/Edirom-Online/commit/e8622666efca86d663a0a5ef160967617f1b57a9 so this issue could be closed?