[MEI-L] Encoding staff positions

[Johannes Kepper]

Hi again,

I agree that TEI's genetic encoding approach is something we should try to combine with MEI, but as Raffaele suggested, we should try to (re)use their namespace as much as possible. This thing is definitely designed for more complicated situations than most of us will encounter on a daily basis. For me, the main question is if there is a need for a smaller solution within MEI's namespace that addresses something like 80% of the situations out there. It's just like <zone> vs. SVG: Simple solution within the format vs. mighty solution by including something else. The only problem then is to find where those 80% might end, and what is needed to get there…




Am 07.02.2011 um 22:43 schrieb Laurent Pugin:

> Hi all,
> 
> As Perry mentioned it, we already had conversations about adding the
> opportunity to use another hierarchy depending one the goal being
> pursued. The case given by Andrew a typical one where it would be much
> easier with a page-oriented hierarchy. Of course, if things are well
> organized, it should be possible to automatically change the
> hierarchy. Nodes in the tree would become milestones (i.e. leafs), and
> reverse. With reasonably complex cases, I don't see any reason why it
> could not be lossless. So one might say, if we can encode it with the
> current schema and just convert it to another hierarchy internally,
> why would we need another way of encoding it?
> 
> If think that the first point is that being able to choose the most
> appropriate hierarchy would make the encoding and the processing much
> simpler. To some extend, it would not necessary be very different from
> the score vs parts representations. And as for score and parts, it is
> very ofter possible to go from one to the other, but not always, and
> we could also have more complex cases where it would not be possible
> to go back and forth between a page oriented and a score/parts
> oriented representation.
> 
> One interesting thing to look at is the TEI module for genetic
> editions, and for our discussion in particular points 1.3 (document
> vs. text) and 3 (the document level)
> http://www.tei-c.org/Activities/Council/Working/tcw19.html
> 
> It goes far beyond the simple example we are discussing here, and with
> such complex cases being able to change the hierarchy without losing
> anything seems very challenging. I am not sure we have to go so far,
> but we should think about it because it would not necessary create
> backward compatibility with the current schema. It would mainly make
> it easier to use it when the goal is to encode a document with more
> focus on the physical aspect of it.