[MEI-L] typable events

[Raffaele Viglianti]

This also seems a bit forced to me. The datatype for att.typed is too free,
with good reason sometimes, but in this context it would be too misleading
without a better specified taxonomy. Andrew's solution is much more
expressive and understandable by any MEI application than a type value that
is not in the schema and is understandable by your application only.

Raffaele


On Wed, Aug 7, 2013 at 7:46 AM, Andrew Hankinson <
andrew.hankinson at mail.mcgill.ca> wrote:

> The only thing I have to add here is from an old discussion Perry and I
> had a while back. I just remembered it when reading through Johannes'
> e-mail, so I'll reproduce it here:
>
> > … I think it's good practice to use @type to indicate the
> *classification of the element itself, not its contents.*  For example,
> <name type="personal">Perry Roland</name> as opposed to <name
> type="composer">Perry Roland</name>.  The first seems to me like a good use
> of @type -- it classifies the name, not Perry Roland.  Down the second path
> is ruin and death. :)
>
> In the case of the example Johannes provided, I'm unclear what the problem
> is. Is it that you can't do "<rest type='supplied' />"? This seems a
> strange way of marking it up, especially since we have quite extensive
> functionality for editorial additions.
>
> Couldn't it be:
>
> <measure>
> …
> <supplied reason="missing" resp="$POINTER_TO_AUTHOR_DEF_IN_HEADER">
>    <rest />
> </supplied>
> </measure>
>
> -Andrew
>
> On 2013-08-07, at 1:07 PM, Johannes Kepper <kepper at edirom.de>
>  wrote:
>
> > Hi Thomas,
> >
> > thanks for pointing that out. This solution seems to be too temporary to
> me, I would like to have something more stable. Also, I'm actually using
> both @type and @subtype. But this is just about my example – what's your
> take on the availability of @type on events in general?
> >
> > jo
> >
> >
> >
> > Am 07.08.2013 um 13:03 schrieb TW <zupftom at googlemail.com>:
> >
> >> My favourite attribute to abuse for temporary solutions that should
> >> not result in invalid MEI is @label as it's available almost
> >> everywhere.  (Kristina can tell you a thing or two about that.)
> >>
> >> 2013/8/7 Johannes Kepper <kepper at edirom.de>:
> >>> Dear List,
> >>>
> >>> I have some issues I've found recently that I would like to discuss.
> Let's start with a question about typable events. In current MEI, it is not
> possible to use @type (att.tybable) on all events (model.eventLike), such
> as notes, rests, chords, spaces, tuplets, bTrems etc.
> >>> I wonder if this is intention, or if we just missed to add that class.
> Even if it was our intention (though I haven't found a former discussion on
> this), what were the arguments, and do we still think this is a necessary
> restriction?
> >>>
> >>> The following sample may be skipped for brevity…
> >>>> My example for this is somewhat questionable in itself, so let me
> explain it a bit. For our Freischütz edition, we're heading off with Finale
> data converted to MEI via MusicXML. In the case of multiple layers on one
> staff, Finale clips shared events at the end of the second (and any
> subsequent) layer: If both layers share a rest at the end, only the first
> layer holds this rest, while the second is just incomplete.
> >>>>
> >>>> For several reasons, I think this is faulty behavior, and therefore
> add corresponding spaces by XSLT. However, I would like to keep track which
> spaces were contained in the original file, and which spaces were added by
> me. A simple @type on the latter would be perfect for me.
> >>>>
> >>>> I am fully aware that MEI offers a whole plethora of elements to
> indicate added, normalized, or otherwise changed content. But since this is
> just an intermediate step in the process of generating my data, I regard
> this additional markup as too complicated. I'm not sure if I will keep this
> information after the next step of proofreading. On the other hand, I don't
> want to operate on invalid data, even if it is only a temporary state.
> >>>
> >>> I'm pretty sure there are simpler examples and better arguments at
> hand, but I hope my example makes the point. So, what do others say –
> should events like notes and rests be typable?
> >>>
> >>> Best,
> >>> Johannes
> >>> _______________________________________________
> >>> mei-l mailing list
> >>> mei-l at lists.uni-paderborn.de
> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >>
> >> _______________________________________________
> >> mei-l mailing list
> >> mei-l at lists.uni-paderborn.de
> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >
> >
> > _______________________________________________
> > mei-l mailing list
> > mei-l at lists.uni-paderborn.de
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> 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/20130807/98bfe7e7/attachment.html>