[MEI-L] Page-based encoding

[Raffaele Viglianti]

Hi Laurent, thanks for sharing this, a few comments:

On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin <lxpugin at gmail.com> wrote:


>
>
> 1) For the document structure to be encoded, we need to have page and
> system elements. The content of a score becomes a list of /page. Each /page
> contains a list of /system. In un-measure music /system contains a list of
> /staff. In measured music, we can imagine a) /system containing a list of
> /staff containing a list of /measure (and then /layer), or b) /system
> containing a list of /measure containing a list of /staff. Solution a)
> seems more natural to me (if we think how music is written on paper, we
> first have staves and then add measure). Solution b) has the advantage of
> being closer to the standard MEI focusing on content. This needs to be
> discussed.
>

It makes sense that when the page hierarchy is flipped, the system
hierarchy gets flipped as well, so that you can encode layout data on
systems too. Though I don't think the same logic applies to staff and
measure so I'd be tempted to go with b), because it would make switching
between a page-based encoding and a "standard" encoding easier.


>
>
> 2) For the positioning, we need to add attributes the elements that can
> have a position. Basically, any element with the @facs. We can solve this
> by making the att.facsimile class member of att.coordinated. This provides
> us with the necessary @ulx, @uly, etc. for specifying the position. We also
> need to specify to which image the position refers to. A simple approach is
> to add a @surface to /page. As mentioned before, all this does not preclude
> to use the standard @facs and facsimile tree scheme at the same time, for
> example if a higher resolution image needs to be added for specific
> elements. We also need to have a @unit in /page and presumably also be able
> to specify if the positioning is absolute or relative.
>

+1. Those would be good to have around even outside of a page-based module,
I think.


>
>
> Another point to be discussed it if we want to keep this in the score
> subtree or if such encoding could be put into another subtree. One option
> would be a /pages element at the same level of /parts and /score. In other
> word, this would be a third representation option in MEI.
>
>
>
Yes, I'd keep it in a different subtree, so that content can be linked in
the same file if necessary.

In general: I see why this approach to encoding is useful, though if we
make it part of MEI, we should make quite clear when it's ok to encode in
page-based fashion and when it's not. Basically we should discourage this
approach unless it's required for specific (scholarly, justifiable)
reasons.

Raf



> I already made a customization for unmeasured music and I am willing to do
> one for measured music for option a) or b) and when we agree where to put
> it. The sample file attached for unmeasured music was generated from the
> OMR output of Aruspix.
>
>
> Best,
>
> Laurent
>
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131031/806dc7a5/attachment.html>