keySig should not be a child of scoreDef

[rettinghaus]

keySig should be disallowed as child on scoreDef, as explicitly encoded keyAccid would then not make sense within multi staff encodings with different clefs.

Also it is quite weird, that keySig only is allowed before pgHead, so if feels decoupled from all the staffDef elements.

[rettinghaus]

The same probably also applies to meterSig.

[lpugin]

Why are you assuming the clef has to be different? You can very well have multiple staves with the same clef and the same key signature.

[rettinghaus]

Then why isn't clef allowed?

[lpugin]

It should be.

[rettinghaus]

No it shouldn't. Clefs and key signatures always apply to a specific staff.

[lpugin]

That is very assertive. We can currently do this:

<scoreDef clef.line="2" clef.shape="G" keysig="2f">
   <staffGrp>
      <staffDef n="1" />
      <staffDef n="2" />
   </staffGrp>
 </scoreDef>

And since we can already have <keySig> instead of @keysig, then allowing <clef> would make things more consistent. If you do not like it, do not use it, but there is nothing wrong with it.

[pe-ro]

The <keySig> element is provided for those cases where a key signature needs to be "elevated" to element status, usually in order to attach new/extra attributes, for instance to capture typographic details such as color, placement, etc. <keySig> is provided at the score-level, not because these attributes apply to all the key signatures displayed on the individual staves (although they may!), but to accommodate single staff scores. Such things do exist. :-)

So, I agree with @lpugin that removal of <keySig> as a child of <scoreDef> isn't necessary. In fact, it moves the schema backwards.

The strict encoding order of the children of <scoreDef> is intended to establish common practice. It doesn't say anything about the relative importance of the children or their relationships to each other. Also, when transforming the original MEI DTD into a RelaxNG schema, it was easiest to stick with the practice set by DTDs. Now that we're fully in RNG land, order and number are no longer linked the way they were in DTDs, so we can relax the order of siblings without losing control over their number. See #1350 where I proposed a change like this in the context of <work>, <expression>, etc.