[mei-catalog-ig] Proposed changes to <event> and <history> in MEI 3.0.0
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Wed Mar 16 16:01:43 CET 2016
Hi Axel,
In your example I think the text “Concert for the benefit of the poor. First performance.” is in fact a label for data provided in the <date>, <geogName>, and <persName> elements. Perhaps I wasn’t as thorough as I could have been, but in my examination of the way <event> has been used (by you and others), I didn’t find any use of <p> that made it significantly different from <label>. In all cases I saw, the <p> element contained fairly short text strings without any other internal structure common to paragraphs, such as line breaks, internal lists, etc. In addition, the name “paragraph” usually implies a certain presentation, often as a distinct block of text , that I believe doesn’t apply in this case.
In spite of my earlier statement, I now think it *is* important to draw a distinction between structured and unstructured content for <event>. Leaving the parsing/teasing apart a mixed model to a downstream processor is not a good choice. As painful as it might be now, I’d rather have the choice made at the time of encoding rather than at the point of publishing/rendering.
I agree that using <desc> as a grouping mechanism for multiple <p> elements or adding a grouping element for multiple <desc> children isn’t necessary. I would also add that if we agree that “grouping ‘loose’ paragraphs mixed in between the more ‘data-like’ elements” tends “to make the encoding quite messy”, then we should also agree that allowing even a single paragraph between data-like elements is just as messy.
Thanks for speaking up. Believe me, I struggled with this quite a bit. I’m sorry I didn’t consult you directly. I naively thought that you were watching the GitHub repo and that your silence indicated agreement with the proposed changes. Although I am a little wary of the pressure it might create to add <desc> in many other places, I’m not completely opposed to adding <desc> to model.eventPart, where <desc> has the same content model as <label>. This would allow us to “have our cake and it eat it too”; that is, allow a somewhat more expansive description within an otherwise database-like model for <event> while simultaneously permitting an unstructured (or, if you will, more loosely structured) model. The most important thing for me is to avoid the ambiguous content model that is created when <p> is part of both options. By the way, to minimize the amount of change we could even go back to using <head> instead of <label>. :-)
There’s still time to make these changes before the official release, I think. But, I will defer to Johannes, who’s in the process of preparing the Guidelines, web site, etc.
--
p.
From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger
Sent: Wednesday, March 16, 2016 5:22 AM
To: 'mei-catalog-ig at lists.uni-paderborn.de'
Subject: [mei-catalog-ig] Proposed changes to <event> and <history> in MEI 3.0.0
Hi Perry & metadata group
Finally I have found some time to review the proposed changes to the header in the MEI 3.0.0 pre-release. I noticed a change in the <event> model that I'd like to ask about. It has to do with the combination of structured and non-structured content. In our discussion in November (below) we were focusing on the grouping of events within event lists. This has been implemented in the new schema as agreed. No problem. In your original post you also addressed the content of the <event> model (semi-structured vs. non-structured). I am sorry that I didn’t respond to that earlier.
The current schema (2.1.0) has the following model for <event>:
<element name="event">
<optional>
<ref name="model.headLike"/>
</optional>
<zeroOrMore>
<choice>
<ref name="model.eventPart"/>
<ref name="model.pLike"/>
<ref name="model.tableLike"/>
<ref name="list"/>
<ref name="castList"/>
</choice>
</zeroOrMore>
<zeroOrMore>
<ref name="biblList"/>
</zeroOrMore>
<ref name="att.bibl.attributes"/>
<ref name="att.calendared.attributes"/>
<ref name="att.common.attributes"/>
<ref name="att.datable.attributes"/>
<ref name="att.edit.attributes"/>
<ref name="att.lang.attributes"/>
<empty/>
</element>
whereas the proposed 3.0.0 schema has
<element name="event">
<optional>
<ref name="mei_model.labelLike"/>
</optional>
<choice>
<zeroOrMore>
<ref name="mei_model.eventPart"/>
</zeroOrMore>
<zeroOrMore>
<choice>
<ref name="mei_model.pLike"/>
<ref name="mei_model.tableLike"/>
<ref name="mei_castList"/>
<ref name="mei_eventList"/>
<ref name="mei_list"/>
</choice>
</zeroOrMore>
</choice>
<zeroOrMore>
<ref name="mei_biblList"/>
</zeroOrMore>
<ref name="mei_att.bibl.attributes"/>
<ref name="mei_att.calendared.attributes"/>
<ref name="mei_att.common.attributes"/>
<ref name="mei_att.datable.attributes"/>
<ref name="mei_att.edit.attributes"/>
<ref name="mei_att.facsimile.attributes"/>
<ref name="mei_att.lang.attributes"/>
<ref name="mei_att.typed.attributes"/>
<empty/>
</element>
You and I had a private discussion about this in February/March 2013. Your conclusion then was:
>I now think the best course of action is not to try to create two choices (semi-structured vs. free),
>but rather to return to intermingling the elements of both options and letting the chips fall where they may.
Then why did we end up having to choose between the two approaches now? If I have forgotten or overlooked something, please remind me.
It causes me problems because personally, and because of the way MerMEId works, I prefer a rather structured approach. However, I still would like to be able to add an explanatory or descriptive text to the event also. The new <label> doesn’t seem to be the right place. Back in 2013 you suggested adding a <desc> element to the event model, and that would be just fine. A <label> is described as ‘a text that identifies the feature to which it is attached’. That’s something quite different, isn’t it? Why not <desc>?
Basically, I would prefer not having to choose either a structured or a non-structured model. I am quite fond of this combination of some basic, precisely defined, ‘data-like’ information and some prose added to it. We use it all the time.
The suggested <event> model prevents me for from this kind of use both when listing performances within <history> and when describing source transmission in <provenance>. In both cases I have some quite well-defined information such as the date and the persons involved, and some descriptive text.
An example. Here’s a performance encoded as an MEI 2.1.0 event:
<event xml:id="event_d1e66836522">
<date isodate="1846-03-23">23 March 1846</date>
<geogName role="venue" xml:id="geogName_d910d5f3">Gewandhaus</geogName>
<geogName role="place" xml:id="geogName_b69c0299">Leipzig</geogName>
<persName role="conductor" xml:id="persName_b598dc1e">Gade</persName>
<persName role="soloist" xml:id="persName_ed9dabab">Franziska Schwarzbach</persName>
<p xml:id="p_4222N215DA">Concert for the benefit of the poor. First performance.</p>
<biblList xml:id="listBibl_65b1553d-ff51-420d-aea3-a335d66069d06553">
<head>Reviews</head>
<bibl xml:id="bibl_d1e67206558">
<genre>article</genre>
<genre>journal</genre>
<title level="j">Neue Zeitschrift für Musik</title>
<imprint>
<date isodate="1846-04-12">1846-04-12</date>
</imprint>
<biblScope unit="vol">30</biblScope>
<biblScope unit="page">119-120</biblScope>
</bibl>
</biblList>
</event>
The <p> containing the descriptive text – which could be any length – would have to be converted to <label> in MEI 3.0.0, which doesn’t sound quite right to me. And what if I have more than one <p>? There can be only one <label>. And above all: In what way does the existing <p> element – ruin the structuredness of the encoding more than <label> does? They both may contain mixed, that is, non-structured, content. So even with the new model, the ‘structured’ option is likely to contain non-structured information. I don’t see that as a problem. Non-structured content can easily be ignored by software dealing with the structured parts only. So why bother changing the <event> model at all?
I do think that introducing a <desc> element or the like to wrap the potential unlimited number of paragraphs would be a good idea, though. Those ‘loose’ paragraphs mixed in between the more ‘data-like’ elements do tend to make the encoding quite messy. I’d be happy to have them wrapped in some container to isolate them from the other information.
Best, Axel
-----Oprindelig meddelelse-----
Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 13. november 2015 12:06
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FW: changes to <eventList> and <event>
Hi Axel,
I'm happy we could reach consensus on this. Unless I hear objections in the next couple of days, I'll go ahead with this change.
--
p.
__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Friday, November 13, 2015 3:53 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] FW: changes to <eventList> and <event>
Hi Perry
Your eventList model looks fine to me.
/axel
-----Oprindelig meddelelse-----
Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h)
Sendt: 11. november 2015 17:43
Til: Music Encoding Initiative
Emne: Re: [MEI-L] FW: changes to <eventList> and <event>
Hi Axel,
I was coming to a similar conclusion, so thanks for proposing a compromise solution. Your model of eventGrp, however, doesn't allow for continued nesting of <eventGrp> elements. So, I'd like to counter with the following models which merge eventList and eventGrp into a single entity --
For eventList:
<content>
<rng:zeroOrMore>
<rng:ref name="model.headLike"/>
</rng:zeroOrMore>
<rng:zeroOrMore>
<rng:group>
<!-- an organizing data element -->
<rng:optional>
<rng:ref name="model.eventPart"/>
</rng:optional>
<!-- an event description or another list of events -->
<rng:choice>
<rng:ref name="event"/>
<rng:ref name="eventList"/>
</rng:choice>
</rng:group>
</rng:zeroOrMore>
<!-- at the very end, lists of citations -->
<rng:zeroOrMore>
<rng:ref name="biblList"/>
</rng:zeroOrMore>
</content>
For event:
<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>
By making the "grouping key" optional, the model of <eventList> does allow for mixing of events grouped on a date, place, person, etc. and a "simple" list of events, but I see that as a good thing, not an impediment. This makes it possible to eliminate <eventGrp> and matches the behavior of other list-like structures (where a list contains a mixture of item and subordinate lists). Most importantly, the model of <event> now meets the original goal -- a clear distinction between a database-like approach to recording the event description and a free-text approach.
I've removed the <listHead> formatting element. We can always take that up again at a later date. I still maintain that they're useful, but I'll also forego the @mark and @order formatting attributes. That battle can wait, too.
--
p.
> -----Original Message-----
> From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni-
> paderborn.de] On Behalf Of Axel Teich Geertinger
> Sent: Tuesday, November 10, 2015 8:10 AM
> To: Music Encoding Initiative
> Cc: mei-catalog-ig at lists.uni-paderborn.de<mailto:mei-catalog-ig at lists.uni-paderborn.de>
> Subject: Re: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and
> <event>
>
> Hi Johannes & Perry
>
> This discussion is started on both MEI-L and MEI-Catalog-IG; I'm
> posting my reply to both lists, but in order not to exclude anyone now
> I suggest we continue the discussion on MEI-L only.
>
> I agree with Johannes that an alternating sequence of date and event
> elements would be a way of looking for trouble. If I want to delete an
> event or change the order of events, I would have to make sure always
> to do the same with the preceding date sibling. If there is any. I
> would definitely prefer being able to address an event or group of
> events as a single element without having to care about any siblings.
> Also, Perry's model (if I read your suggestion correctly) implies that
> it would not be possible to have an <event> without a preceding
> <date>. But we are not always able to date events. Even if <date>
> could be left empty, the construct would seem somehow awkward to me.
> Finally, from a purely practical perspective, the way we handle
> elements would make it a pain to maintain and edit such a list of alternating elements.
>
> If we are introducing <eventGrp>, we have a clear way of
> distinguishing a list of events (that is, a possibly unordered,
> non-grouped <eventList>) from a group of events that have something in
> common. Let's not mix them up. If we want to group events by date, we
> could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>):
>
> <eventList>
> <event><!-- some single event --></event>
> <eventGrp>
> <!-- a group of events -->
> <date><!-- the grouping parameter - could also be geogName etc.
> instead -
> -></date>
> <event><!-- event 1 --></event>
> <event><!-- event 2 etc. --></event>
> </eventGrp>
> </eventList>
>
> Alternatively, the @isodate approach could be used on <eventGrp>.
>
> /axel
>
> -----Oprindelig meddelelse-----
> Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På
> vegne af Johannes Kepper
> Sendt: 10. november 2015 00:20
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] FW: changes to <eventList> and <event>
>
> Hi Perry,
>
> I understand (and fully support) your motivation to clean up events.
> However, could you please refresh my memory and indicate the current /
> planned content of event? Maybe I understand your proposal to move all
> these things out of events better with that model in mind. As you
> know, we use even annots in a data-like way, and while I agree that
> both annots and events are perfectly valid to take free-form content,
> I'm still in love with structured things - maybe just a couple of
> attributes. Or would it be an alternative to provide separate elements
> for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>?
>
> Just guessing.
> jo
>
>
> Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>:
>
> >
> > Our current handling of <eventList> is a mess, which reduces its
> > effectiveness for data interchange and interoperability. Clarifying
> > its possible content can counteract this tendency. It's relatively
> > easy to provide alternative grouping mechanisms. For instance, a
> > content model for <eventList> like --
> >
> > <content>
> > <rng:zeroOrMore>
> > <rng:ref name="model.headLike"/>
> > </rng:zeroOrMore>
> > <rng:optional>
> > <rng:ref name="listHead"/>
> > </rng:optional>
> > <rng:zeroOrMore>
> > <rng:group>
> > <rng:choice>
> > <rng:ref name="model.eventPart"/>
> > </rng:choice>
> > <rng:choice>
> > <rng:ref name="event"/>
> > <rng:ref name="eventGrp"/>
> > </rng:choice>
> > </rng:group>
> > </rng:zeroOrMore>
> > <rng:zeroOrMore>
> > <rng:ref name="biblList"/>
> > </rng:zeroOrMore>
> > </content>
> >
> > would allow any member of model.eventPart to act as the organizing
> > "term". For instance,
> >
> > <eventList>
> > <date><!-- date of event --></date>
> > <event><!-- event description --></event>
> > <!-- and so on -->
> > </eventList>
> >
> > or
> >
> > <eventList>
> > <geogName><!-- place of event --></geogName>
> > <event><!-- event description --></event>
> > <!-- and so on -->
> > </eventList>
> >
> > or
> >
> > <eventList>
> > <persName><!-- personal name, of conductor for example --
> ></persName>
> > <event><!-- event description --></event>
> > <!-- and so on -->
> > </eventList>
> >
> > are all possible. This is the essentially the model used by HTML
> > for <dl>, by
> EAD for <chronlist>, and by TEI for <list> of @type "gloss". The
> difficulty, of course, is ensuring that each event in a list is
> preceded by the same kind of element. I'm not sure if this is
> possible using RNG alone, but it can certainly be enforced using Schematron.
> >
> > --
> > 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:40 PM
> >> To: Music Encoding Initiative
> >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event>
> >>
> >>
> >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h)
> >> <pdr4h at eservices.virginia.edu<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-catalog-ig mailing list
> mei-catalog-ig at lists.uni-paderborn.de<mailto:mei-catalog-ig at lists.uni-paderborn.de>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto: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-catalog-ig/attachments/20160316/129212c7/attachment.html>
More information about the mei-catalog-ig
mailing list