kepper

I am very strong on pushing this down the road. Changing this markup will break guidelines generation, and I don't want to rush this. This doesn't mean it's a bad...

at ODD Friday, we agreed that we pull in the schema right now (after the meeting), and will try to set up a GH Action independently of that. The GH...

Hi @ahankinson, if I got you right, the job here is actually slightly different. This is not to extract the Schematron rules that are part of MEI, but to control...

Yes, at some point, we should. That seems to be a rather significant change, though, that requires proper testing. So I'm inclined to schedule that for a later, dedicated meeting,...

running this locally results in 57 consistency problems in the specs and guidelines. I would like to have this merged before starting to fix those errors.

Thanks for this. Now a question to our experts @bwbohl, @musicEnfanthen, and maybe @riedde: What would be necessary to have this as an automatic check when committing, and then automatically...

We do have a value of `rightmar` in [data.NONSTAFFPLACE](https://music-encoding.org/guidelines/dev/data-types/data.NONSTAFFPLACE.html), which seems quite appropriate. However, that it's not really accessible in this situation, as it's bringing too much other stuff. I...

A potential way around this could be to split up data.NONSTAFFPLACE into multiple data types, but we would probably end up having another attribute named `place`, with yet another set...

will close this, according to the arguments given in #951

The problem I see with `@x / @y / @height / @width` is exactly the ambiguity you're describing. Of course we may state clearly in the guidelines which point is...