Order of <part-group> elements is unspecified

[lemzwerg]

What specifies the horizontal order of vertical braces, brackets, etc., set up with <part-group>? How do I correctly distinguish between the first and the second image?

As far as I can see, the standard doesn't give an answer...

The only solution that comes to my mind is to use the number attribute of <part-group> to specify the order: a larger value than the current delimiter's one puts the new delimiter to the left. Thus, using pseudo-XML, the first image would be encoded as

<part-group number="1" type="start">
  <part-group number="2" type="start">
    <staff 1>
    <staff 2>
  <part-group number="2" type="end">
  <part-group number="2" type="start">
    <staff 3>
    <staff 4>
  <part-group number="2" type="end">
<part-group number="1" type="end">

and the second image as

<part-group number="2" type="start">
  <part-group number="1" type="start">
    <staff 1>
    <staff 2>
  <part-group number="1" type="end">
  <part-group number="1" type="start">
    <staff 3>
    <staff 4>
  <part-group number="1" type="end">
<part-group number="2" type="end">

If my conclusion is correct, please document it.

[mscuthbert]

I don't know that this part of the spec has been fully determined. There are three choices to consider:

Containers show outside to inside--this is the most standard XML and I think most logical

Numbers show order from lowest--inner to highest outer. What you've described.

Musically intelligent: groups with more staves are outside groups with fewer.

If I remember correctly the spec does not support overlapping groups where staff can be part of an inner brace but not an outer bracket. It is simple to draw something like this and not harder to imagine a case where it might be useful. (Tbn1-3 grouped at one level but Tbn3+Tuba at another is common way of orchestrating) I can't remember encountering this in a score.

The best way to take an ambiguous MusicXML example and move it to a recommendation is to document what the majority of interpreters expect for this. My hunch is that outer layers of XML will represent furthest left brackets regardless of number.

(Also note that most "number="1-6"" attributes in MusicXML aren't meant to have the number imply order. They could just as well be 6 unordered shapes for most purposes. MusicXML treats them as unordered string keys)

[lemzwerg]

Containers show outside to inside--this is the most standard XML and I think most
logical

AFAICS, this is not what gets used here.

Numbers show order from lowest--inner to highest outer. What you've described.

Yes.

Musically intelligent: groups with more staves are outside groups with fewer.

Alas, this doesn't reflect reality (or I misunderstood you). Consider the following real-world example:

The group with the most staves (namely all of them) is the innermost. It also demonstrates that you need logical groups, too (i.e., groups that don't draw anything), so that you can correctly realise the bar lines:

innermost group (all staves): bracket, no bar line grouping
  winds group: no symbol, with bar line grouping
    flauti: square, no bar line grouping
    ...

However, logical grouping alone doesn't determine whether a new brace, bracket, or square symbol gets drawn to the left or to the right of the current grouping symbol.

If I remember correctly the spec does not support overlapping groups where staff
can be part of an inner brace but not an outer bracket.

I don't see this restriction in the description of <part-group>. But admittedly, I haven't seen such overlaps either.

The best way to take an ambiguous MusicXML example and move it to a
recommendation is to document what the majority of interpreters expect
for this. My hunch is that outer layers of XML will represent furthest left
brackets regardless of number.

As described above, this isn't sufficient.

(Also note that most "number="1-6"" attributes in MusicXML aren't meant
to have the number imply order. They could just as well be 6 unordered
shapes for most purposes. MusicXML treats them as unordered string keys)

At first I thought the same, but after some thinking I came to the conclusion that here the order is important. BTW, MuseScore does exactly what I've described in the OP.

[mdgood]

You distinguish these two cases by using the <group-symbol> element and specifying a default-x attribute value. There's an example of using this element here, though it doesn't show the case of nested groups.

[lemzwerg]

OK, thanks. @mdgood, am I right that without such x-attribute values the horizontal positioning of nested vertical delimiters (i.e., braces, brackets, etc.) is application-specific?

[mdgood]

Yes, that's correct.

[lemzwerg]

Thanks again. So, this is a documentation issue, in case someone is classifying such reports.