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

Mon Nov 9 22:07:59 CET 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151109/cf843c00/attachment.html>