adapt instrDef to staffDef

[rettinghaus]

Using att.nNumberLike instead of att.nInteger for instrDef seemed a bit inconsistent, as staffDef and layerDef are part of the latter.

This PR proposes to model it like staffDef instead of using att.common.

[bwbohl]

Like the harmonisation, nevertheless dislike that you had to reference all those other classes just to change one of them…

Seems to me that maybe we should rethink the attribute classes at some point, especially the need of two versions of @n.

[rettinghaus]

True. There are several elements that are actually affected here (e.g., keyAccid). Maybe it would be better to have att.nInteger in att.common and switch on att.nNumberLike in those specific cases we actually want to allow this?

[kepper]

But that is a separate discussion, isn't it? What I would propose is to have two flavors of att.common, which can be referenced as needed. Regular att.common would bring att.nNumberLike (so we have very few changes throughout the specs), and prospective att.common.nInteger (or some such) would bring att.nInteger.

[ahankinson]

@rettinghaus could you remove the draft label?

[rettinghaus]

@ahankinson with pleasure!

[ahankinson]

Thanks!