Reusable layouts below system

[clnoel]

@notator and I have been proposing in #185 (see #185 (comment) for an example) that there should be ”reusable” layout definitions for the layers below system-layout, and that these should be siblings of system-layout.

As @joeberkovitz says in #185 (comment) this ends up complicating the definitions, and might not actually be used by the programs making mnx files. And it's not actually necessary for grouping parts, so we're spinning it off into this issue.

[notator]

In #185 (comment), @joeberkovitz says:

The following things are bothering me — I am not taking a hard stand on these points yet, but I want to float these thoughts to see how others feel.

Here's the case for having reusable layout definitions at all levels, not just at the <system-layout> level:

@joeberkovitz again:

In terms of the rendered result, reusable definitions add nothing to this proposal. There is nothing you can encode with a reusable definition that cannot be encoded with repeated "inline" definitions. So we could get everything we want without reuse...

and

Let's ask what reusable definitions actually do bring to the table. I can only think of one thing: they allow an application that already reuses named layout definitions to encode definitions as first-class concepts.

Its true that repeated "inline" definitions could always be used instead of re-usable layout definitions, but re-usable definitions

• add no more complexity to the code than already exists (multiple, reusable <system-layout> definitions are, as @joeberkovitz says, essential)
• make it possible to create new <system-layout> definitions more easily and efficiently. This is especially important in scores that have large ensembles. For example: Changing the layout for two flutes for a system in a large orchestral score should not mean that one has to write out the detailed layout definitions for the rest of the woodwind, the brass, percussion and strings again.

I don't see [reusable definitions] being used by manual encoders, or by applications that are not pro-level notation editors.

On the contrary, I think it would be much easier for manual encoders to use reusable definitions, than for them to have to write the definitions out again every time they are used. Similarly for applications.

To me, this feels like an instance of a general principle in programming: Re-use of code is efficient, and leads to better maintainability.

But... how likely is it that different notation editors are going to have reusable layout definitions which are organized exactly like the MNX schema? Seems like a bad bet.

If an application can write a layout definition, it can give it a name or id, and re-use it. The internals of notation editors need not concern us. (BTW: I'm having second thoughts about using name attributes rather id. I'm leaning towards using id everywhere. The ids have to be unique, and existing tools probably enforce that.)

Reusable definitions add non-trivial complexity to both the schema and the document topology, as the layout elements now form a directed acyclic graph instead of a tree. If we ever allow groups-within-groups or any other recursive construct, the potential for cycles would exist which is tricky to validate.

If reusable <system-layout> definitions have to exist, then applications that can deal with them can also deal with other reusable layout definitions. As I said above, I don't see any additional complexity.
If, inside <layouts>, all layout elements have to be defined before they are referenced (as is the case with all XML elements), then cyclic references become impossible in the file. While a <group-layout> definition can reference one or more (previously defined) <group-layout> elements, it can never reference itself.

I take your point about recursive constructs being difficult to validate.
If defining <group-layout> recursively is a real problem in the schema, we could define it there non-recursively: Only allow a fixed number of nestings, with a different <group-layout> type at each level.

And having a -definition variant of each reusable element (which would be important for validation) doubles the number of elements.

I don't see the need for a -definition variant of each reusable element.

The interaction between definitions and style properties (or, actually, any inheritable layout properties at all) is going to be quite complex to get right. A reusable definition will inherit totally different properties from its ancestors for each different place it is used. These properties may interact with what's in the definition so that it does not really behave like a copy of itself in each instance where it is referenced. It can all be carefully speced out, but why take this on here and now?

This discussion really belongs in #263 (which I have not really been following), but I currently don't understand why there's a fundamental problem here. If there's a clearly defined nesting hierarchy (that includes referenced elements) then every object in the hierarchy has a clearly defined set of styles. We should continue this discussion in #263, when I've caught up there.