[MEI-L] Layout discussion

[Johannes Kepper]

Just a comment from the sideline: I haven't warned Laurent about this request, so we all should be patient with him. If he can't provide a summary early next week, I'll try to cook something up, but Laurent is definitely more familiar with the details of this proposal. 

Johannes



Am 09.11.2012 um 20:22 schrieb "Byrd,  Donald A." <donbyrd at indiana.edu>:

> I'm just emerging from a long period of lurking -- with a lot of ignoring :-| . I (for one) would love to see "a thorough introduction of our layout tree proposal and its specific qualities."
> 
> --Don
> 
> 
> On Thu, 8 Nov 2012 14:45:11 +0100, Johannes Kepper <kepper at edirom.de> wrote:
> 
>> 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
>> 
>> 
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
> 
> 
> 
> --
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics & Music
> Indiana University, Bloomington
>