[MEI-L] Layout discussion

[Byrd, Donald A.]

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