[MEI-L] Layout discussion

[Johannes Kepper]

Don't blame it on me – some of you requested to have the following discussion completely in public, and I think we should follow that suggestion. I expect this thread to be somewhat lengthy. What we should try to resolve is how MEI deals with layout-specific information, its relationship to the semantic parts of MEI, separating out layout info in a similar way than CSS does for HTML, relationship of various units (and types thereof), page-based approaches to MEI etc. 

I will try to summarize the model I briefly introduced in New Orleans last week. I would love to see Laurent replying to that, ideally with a thorough introduction of our layout tree proposal and its specific qualities. This should introduce lurkers to our current state, and from there, we can refer back to our proposal from last week and see where the discussion leads us…

The basic situation is that we want to preserve differences between multiple sources. The most obvious way for doing this is to use the <app> / <rdg> elements, which provide a very intuitive way for doing so. But, as soon as we also want to preserve detailed information about layouts, we have to add many more attributes to each note etc., so it becomes more likely that differences between the sources will result in additional <app>s and <rdg>s. Eventually, this will lead to a separate <app> / </rdg> for almost every note. While this is still possible, it might be regarded as somewhat impractical. The alternative for this is to use one file, let's call it common.xml, to store all the commonalities between the sources, but also the most important differences. Basically, this file contains only @pname, @oct and @dur for every note. It will split up into <app>s and <rdg>s where the sources differ in this regard, but it will not consider stem directions, exact positioning etc. 
Every single source is also represented by a separate file, let's call it sourceXY.xml. These files do not contain <app>s and <rdg>s at all, they just reflect the musical text as given in the according source. They contain elements for all notes etc., but they omit the basic attributes as specified in the common.xml. Instead, they use a reference to the corresponding elements in this file. Here's an example: 

common.xml:
<note xml:id="noteX" pname="c" oct="4" dur="1"/>

sourceXY.xml:
<note stem.dir="up" sameas="common.xml#noteX/>

It is easily possible to point to a note within a <app>/<rdg> in case the basic parameters already differ. 

With this strategy, layout information can be separated out quite completely. <sb/> and <pb/> are stored only within the sourceXY.xml files (though they could be provided in the common.xml within <app>s and <rdg>s as well). If one wants to extract a source file completely, he just has to resolve all pointers. This is cumbersome when doing manually, but with an xml database and an index on xml:ids, it shouldn't be too hard. Also, it is still possible to extract information about differing stem directions etc., but it requires more processing than the <app>/<rdg> approach. Basically, this is a compromise somewhere in the middle between source separation and integration, which tries to address the most common cases in the most convenient way, while accepting some additional hurdles for corner cases. Of course it is open for discussion which attributes should go in the common.xml, and which attributes should be separated out to the individual source files. 

The benefit of this approach is that it completely relies on existing MEI – it does not require any further additions to the standard and works "out of the box". 

But, it does not address all requests catered for with a distinct layout tree, which I hope Laurent will introduce. 
jo