[MEI-L] FW: changes to <eventList> and <event>

Johannes Kepper kepper at edirom.de
Mon Nov 9 22:39:50 CET 2015 

Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:

> 
> An <eventGrp> element containing <event> with the current model makes no sense as there's no indication of the grouping criterion.  The <date> followed by <eventGrp> construct makes it clear that the events are grouped by date.  In fact, that's the only way to group them using this model.

Ok, what constitutes a group of events? What does it mean to have events grouped? Is there any other grouping mechanism other than by date? Does it make sense to have events grouped by place? If so, why don't we factor in groups (by date, for instance) and subgroups (by place)? Or is it maybe better to let the grouping be done by applications, based on structured markup like @isodate, @resp, @type and similar options?

> 
> It is nothing like the concept of chords that you raise.

I need to look into the preceding sibling to fully understand the current element…

> Order is a good thing here as it makes the structure of the data clear.
> 

jo

> --
> p.
> 
> 
>> -----Original Message-----
>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
>> Johannes Kepper
>> Sent: Monday, November 09, 2015 4:20 PM
>> To: Music Encoding Initiative
>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>
>> 
>> I'm sorry to say, but I'm not convinced by this one either. I see the point to
>> have an eventGroup element, but everything else seems rather dubious to
>> me. By all means, I would like to keep the date inside events, even for free-
>> form text-driven events (in contrast to data-driven events). Also, I hate the
>> idea to have an alternation of events and something, and have to rely on
>> document order to understand the meaning of something - this gets pretty
>> close to MusicXML's concept of chords, doesn't it? Are there any real-world
>> limitations that motivate this proposal? If so, could we discuss it with those
>> examples on the table?
>> 
>> jo
>> 
>> 
>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h)
>> <pdr4h at eservices.virginia.edu>:
>> 
>>> 
>>> I sent this message to the cataloging interest group list earlier.  I apologize if
>> you receive it twice, but I thought it would be a good idea to post to this list
>> as well in the interest of generating as much discussion as possible.
>>> 
>>> BTW, this is not a new feature, but rather a remedy for an existing bug. But
>> I think it's finally squashed this time.
>>> 
>>> --
>>> p.
>>> 
>>> 
>>> From: Roland, Perry D. (pdr4h)
>>> Sent: Monday, November 09, 2015 3:46 PM
>>> To: 'mei-catalog-ig at lists.uni-paderborn.de'
>>> Subject: changes to <eventList> and <event>
>>> 
>>> 
>>> I know we've had a few rounds of discussion about the content models of
>> <eventList> and <event> in the past.  I think there are basically 2 issues
>> currently facing us:
>>> 
>>> *       eventList contains a bug that doesn't allow grouping events that share
>> the same date
>>> *       the model of event is too vague
>>> 
>>> I propose to remedy the first problem by using the following content model
>> for <eventList>:
>>> 
>>> eventList   (head*, listHead?, (date, (event | eventGrp))*, biblList*)
>>> 
>>> By placing <date> outside the model of <event>, the main content of
>>> <eventList> can be constrained to be any number of pairs of <date> and
>>> <event> elements, like so -
>>> 
>>> <eventList>
>>>  <date><!-- when "it" happened --></date>
>>>  <event><!-- what happened -->
>>>  <date><!-- another happening --></date>
>>>  <event><!-- another description -->
>>> <!-- and so on -->
>>> </eventList>
>>> 
>>> Or, when multiple events share the same date, like so --
>>> 
>>> <eventList>
>>>  <date><!-- the date --></date>
>>>  <eventGrp>  <!-- the events occurring on the date -->
>>>    <event>Event 1</event>
>>>   <event> Event 2</event>
>>>   <!-- and so on -->
>>>  </eventGrp>
>>> </eventList>
>>> 
>>> The new model also introduces listHead, a new formatting element.
>>> <listHead> contains a pair of <head> elements, one for each column in
>>> the eventList date-event pair.  This makes it possible to treat the
>>> list of events as though it were a table with a column heading for the
>>> dates and a heading for the descriptions.  Of course, eventList/head
>>> continues to contain a heading for the entire list --
>>> 
>>> <eventList>
>>>  <head>My List o' Special Events</head>
>>>  <listHead>
>>>    <head>When</head>
>>>  <head>What</head>
>>>  </listHead>
>>>  <event/>
>>>  <event/>
>>> </eventList>
>>> 
>>> I plan to investigate how this might work for other lists as well, such as
>> <biblList>, <castList>, and <list>.  Any list that allows a label preceding its
>> "items" could benefit from this treatment, I think.
>>> 
>>> One more change -- <eventList> is now a member of model.listLike,
>> meaning it can occur not just in the header but anywhere a "regular" list can
>> happen.
>>> 
>>> The <event> element now has the following model (switching to RNG as
>>> it's somewhat clearer than DTD syntax) --
>>> 
>>> <content>
>>>  <rng:optional>
>>>    <rng:ref name="model.labelLike"/>
>>>  </rng:optional>
>>>  <rng:choice>
>>>    <!-- data-like organization -->
>>>    <rng:zeroOrMore>
>>>      <rng:choice>
>>>        <rng:ref name="model.eventPart"/>
>>>        <rng:ref name="eventList"/>
>>>      </rng:choice>
>>>    </rng:zeroOrMore>
>>>    <!-- free-form organization -->
>>>    <rng:zeroOrMore>
>>>      <rng:choice>
>>>        <!-- model.listLike is expanded here in order to disallow biblList -->
>>>        <rng:ref name="model.pLike"/>
>>>        <rng:ref name="model.tableLike"/>
>>>        <rng:ref name="castList"/>
>>>        <rng:ref name="eventList"/>
>>>        <rng:ref name="list"/>
>>>      </rng:choice>
>>>    </rng:zeroOrMore>
>>>  </rng:choice>
>>>  <rng:zeroOrMore>
>>>    <rng:ref name="biblList"/>
>>>  </rng:zeroOrMore>
>>> </content>
>>> 
>>> English translation is "an optional label, followed by EITHER some data-like
>> elements or nested eventLists OR any number of paragraphs, tables,
>> castLists, eventLists, or lists, followed by any number of lists of bibliographic
>> citations."
>>> 
>>> The central choice (a data-centric organization OR a free-form text
>>> one) is the important factor here.  In purely practical terms, any
>>> file that formerly used a group of data elements followed by a
>>> paragraph will have to be translated into --
>>> 
>>> <event>
>>>  <label><!-- former paragraph content -->
>>>  <geogName/><persName/> <!-- etc. --> </event>
>>> 
>>> This element re-naming and re-ordering is not a difficult task and can be
>> made part of the 2013 -> 2015 XSLT transformation.  If the re-ordering poses
>> a significant issue (that is, you *must* have the data elements followed by
>> the label), I think it's not a problem to allow that, but please let me know.
>>> 
>>> As always, I apologize for the length of the message and the XML
>>> "gobbledy-gook".  I just don't know of any other way to communicate.
>>> ;-)
>>> 
>>> --
>>> p.
>>> 
>>> ________________________________
>>> Perry Roland
>>> University of Virginia
>>> P. O. Box 400874
>>> Charlottesville, VA, 22904
>>> 434-982-2702 (w)
>>> pdr4h (at) virginia (dot) edu
>>> 
>>> _______________________________________________
>>> 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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 496 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151109/c374dcb0/attachment.sig>

More information about the mei-l mailing list