Hi,<div><br></div><div>First of all, not to overload the list, I would recommend people interested in the discussion to have a look at our ismir paper</div><div><a href="http://ismir2012.ismir.net/event/papers/505-ismir-2012.pdf" target="_blank">http://ismir2012.ismir.net/event/papers/505-ismir-2012.pdf</a></div>
<div><br></div><div>The module as describe in the paper works well for OMR where we need to be able to store exact positions for all the elements on the page. We also tested it for comparing the content of several sources, where we end up with one single sub-tree with the musical content, with <app> and <rdg> for differences. We can call it the logical tree, (e.g., note pitches and note durations). The positioning information is stored in sub-trees, one for each sources. The link is accomplished by xml:id in the layout sub-tree referencing elements in the logical sub-tree. In other words, the logical sub-tree is autonomous, which is not the case of the layout sub-trees.</div>
<div><br></div><div>A while ago, we had a discussion about introducing a page-based representation in MEI:</div><div><a href="https://lists.uni-paderborn.de/pipermail/mei-l/2011/000280.html">https://lists.uni-paderborn.de/pipermail/mei-l/2011/000280.html</a> (very long thread!)</div>
<div>At that point, this option did not appear to be necessary. However, as Johannes explained, we came up to the conclusion in New Orleans that it might be a good idea to re-evaluate the relevance of such a page-based representation in the light of what we learned by designing the layout module since they are quite similar in what we would like to achieve. We could say that the main difference is that with the layout module approach, the information about the layout information is subordinated to a traditional content representation of the music (stored in another sub-tree), whereas that with a page-based representation approach, everything is (or can) be represented in one single tree. As Johannes explained, we could also decide to have page-based representation files with only layout information and referring to other MEI files, and in that case they would act exactly as the layout module sub-trees.</div>
<div><br></div><div>Best,</div><div>Laurent</div><div><br><div class="gmail_quote">On Sat, Nov 10, 2012 at 4:35 AM, Eleanor Selfridge-Field <span dir="ltr"><<a href="mailto:esfield@stanford.edu" target="_blank">esfield@stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm lurking too and pass on one practical issue: web browsers. I've been<br>
noticing recently that<br>
Chrome has trouble resolving the printing parameters of attachments<br>
received on A4 paper (it may be the reserve elsewhere). Presumably some<br>
intermediate software will always stand between MEI and any screen<br>
display.<br>
<br>
For me screen layout is the next question after page layout. Instinct<br>
tells me that separate semantic content from all layout and rending<br>
questions is the better path. The SCORE approach may be instructive: the<br>
program uses virtual units to etablish the desire aspect ratio. It also<br>
has a virtual relationship to the physical page. Note though that in the<br>
music printing industry page sizes may not have the same aspect ratio as<br>
those used with desktop printers. (AT the AMS I had a discussion about<br>
this with Douglas Woodfill-Harris from Bärenreiter.)<br>
<br>
Eleanor<br>
<span><font color="#888888"><br>
<br>
Eleanor Selfridge-Field<br>
Consulting Professor, Music (and, by courtesy, Symbolic Systems)<br>
Braun Music Center #129<br>
Stanford University<br>
Stanford, CA 94305-3076, USA<br>
<a href="http://www.stanford.edu/~esfield/" target="_blank">http://www.stanford.edu/~esfield/</a><br>
</font></span><div><div><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: mei-l-bounces+esfield=<a href="mailto:stanford.edu@lists.uni-paderborn.de" target="_blank">stanford.edu@lists.uni-paderborn.de</a><br>
[mailto:<a href="mailto:mei-l-bounces%2Besfield" target="_blank">mei-l-bounces+esfield</a>=<a href="mailto:stanford.edu@lists.uni-paderborn.de" target="_blank">stanford.edu@lists.uni-paderborn.de</a>] On<br>
Behalf Of Byrd, Donald A.<br>
Sent: Friday, November 09, 2012 11:22 AM<br>
To: Music Encoding Initiative; Johannes Kepper<br>
Subject: Re: [MEI-L] Layout discussion<br>
<br>
I'm just emerging from a long period of lurking -- with a lot of ignoring<br>
:-| . I (for one) would love to see "a thorough introduction of our layout<br>
tree proposal and its specific qualities."<br>
<br>
--Don<br>
<br>
<br>
On Thu, 8 Nov 2012 14:45:11 +0100, Johannes Kepper <<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>><br>
wrote:<br>
<br>
> Don't blame it on me ? some of you requested to have the following<br>
> discussion completely in public, and I think we should follow that<br>
> suggestion. I expect this thread to be somewhat lengthy. What we<br>
> should try to resolve is how MEI deals with layout-specific<br>
> information, its relationship to the semantic parts of MEI, separating<br>
> out layout info in a similar way than CSS does for HTML, relationship<br>
> of various units (and types thereof), page-based approaches to MEI<br>
> etc.<br>
><br>
> I will try to summarize the model I briefly introduced in New Orleans<br>
> last week. I would love to see Laurent replying to that, ideally with<br>
> a thorough introduction of our layout tree proposal and its specific<br>
> qualities. This should introduce lurkers to our current state, and<br>
> from there, we can refer back to our proposal from last week and see<br>
> where the discussion leads us?<br>
><br>
> The basic situation is that we want to preserve differences between<br>
> multiple sources. The most obvious way for doing this is to use the<br>
> <app> / <rdg> elements, which provide a very intuitive way for doing<br>
> so. But, as soon as we also want to preserve detailed information<br>
> about layouts, we have to add many more attributes to each note etc.,<br>
> so it becomes more likely that differences between the sources will<br>
> result in additional <app>s and <rdg>s. Eventually, this will lead to<br>
> a separate <app> / </rdg> for almost every note. While this is still<br>
> possible, it might be regarded as somewhat impractical. The<br>
> alternative for this is to use one file, let's call it common.xml, to<br>
> store all the commonalities between the sources, but also the most<br>
> important differences. Basically, this file contains only @pname, @oct<br>
> and @dur for every note. It will split up into <app>s and <rdg>s where<br>
> the sources differ in this regard, but it will not consider stem<br>
> directions, exact positioning etc.<br>
> Every single source is also represented by a separate file, let's call<br>
> it sourceXY.xml. These files do not contain <app>s and <rdg>s at all,<br>
> they just reflect the musical text as given in the according source.<br>
> They contain elements for all notes etc., but they omit the basic<br>
> attributes as specified in the common.xml. Instead, they use a<br>
> reference to the corresponding elements in this file. Here's an<br>
> example:<br>
><br>
> common.xml:<br>
> <note xml:id="noteX" pname="c" oct="4" dur="1"/><br>
><br>
> sourceXY.xml:<br>
> <note stem.dir="up" sameas="common.xml#noteX/><br>
><br>
> It is easily possible to point to a note within a <app>/<rdg> in case<br>
> the basic parameters already differ.<br>
><br>
> With this strategy, layout information can be separated out quite<br>
> completely. <sb/> and <pb/> are stored only within the sourceXY.xml<br>
> files (though they could be provided in the common.xml within <app>s<br>
> and <rdg>s as well). If one wants to extract a source file completely,<br>
> he just has to resolve all pointers. This is cumbersome when doing<br>
> manually, but with an xml database and an index on xml:ids, it<br>
> shouldn't be too hard. Also, it is still possible to extract<br>
> information about differing stem directions etc., but it requires more<br>
> processing than the <app>/<rdg> approach. Basically, this is a<br>
> compromise somewhere in the middle between source separation and<br>
> integration, which tries to address the most common cases in the most<br>
> convenient way, while accepting some additional hurdles for corner<br>
> cases. Of course it is open for discussion which attributes should go<br>
> in the common.xml, and which attributes should be separated out to the<br>
> individual source files.<br>
><br>
> The benefit of this approach is that it completely relies on existing<br>
> MEI ? it does not require any further additions to the standard and<br>
> works "out of the box".<br>
><br>
> But, it does not address all requests catered for with a distinct<br>
> layout tree, which I hope Laurent will introduce.<br>
> jo<br>
><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
<br>
<br>
<br>
--<br>
Donald Byrd<br>
Woodrow Wilson Indiana Teaching Fellow<br>
Adjunct Associate Professor of Informatics & Music Indiana University,<br>
Bloomington<br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</div></div></blockquote></div><br></div>