[MEI-L] FW: changes to <eventList> and <event>
Johannes Kepper
kepper at edirom.de
Mon Nov 9 22:19:30 CET 2015
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
-------------- 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/6132210c/attachment.sig>
More information about the mei-l
mailing list