[MEI-L] order of elements

[Roland, Perry (pdr4h)]

Hi Joachim,

Thanks for the vote of confidence.  No allusion to recent events intended!  :)

It's not immediately obvious, but repetition of certain elements is handled one more level down from where we're talking about now.  For example, multiple <annot> elements are allowed within <notesStmt> and multiple <title> elements are allowed in <titleStmt>.  In other words, <notesStmt> functions as a grouping mechanism for multiple <annot> elements, so <notesStmt> only occurs once.  I suppose one could argue for allowing multiple occurrences of <notesStmt> in order to arrange similar annotations in each group.  However, since this kind of grouping can be accomplished using @type on each <annot> element, there's no need to introduce a second method of grouping.

I'm interested to find out the effects of the hurrican on C'ville myself as I'm currently in central Tennessee, nearly 1000 miles away!

--
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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Joachim Veit [veit at weber-gesamtausgabe.de]
Sent: Monday, August 29, 2011 4:47 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] order of elements

Hi Perry,
thanks for your explicit answer! For my part, I fully consent with your
proposal (at least 98,9 %...): There is no real advantage for a user
having the possibility of ordering elements in the header in this way or
the next three ways in the next two projects .... But perhaps this leads
to processing efforts which are really unnecessary.
I prefer to have a guidance in putting down my metadata and I am always
happy when I am (only after several daily examples) familiar with the
given order in the TEI header - because I don't have to think about:
which details I have forgotten / what is the best element to join next
etc...
So I plead for the DTD-order with comma und only beg you to think about
some more asterisks, if repetitions of data really occur. But I am a bit
uncertain where this might be the case - notesStmt??
Best greetings, I hope that Charlottesville had no problems with the storm!?
Joachim


Am 29.08.11 16:47, schrieb Roland, Perry (pdr4h):
> Hi Johannes,
>
> In all of the schema languages I'm aware of, if a group of sub-elements are unordered, then it's impossible to control their number.  Stated the other way around, if you want to control the number of sub-element occurrences, then you must also control for their order.
> Using your<source>  example, the following model (in "DTD speak" for brevity) --
>
> <!ELEMENT source (identifier | titleStmt | editionStmt | pubStmt | physDesc | seriesStmt | notesStmt | langUsage | classification | relatedItem)*>
>
> permits any order but also *any number*.
>
> However, aside from<identifier>  and<relatedItem>, which may occur 0 or more times, each of the children of<source>  should only occur once, leading to --
>
> <!ELEMENT source (identifer*, titleStmt?, editionStmt?, pubStmt?, physDesc?, seriesStmt?, notesStmt?, langUsage?, classification?, relatedItem*)>
>
> So, for example, we can make sure there is only one publication statement and accept that the elements must be in order OR we can make the sub-elements unordered and live with the possibility that someone might use pubStmt multiple times.  I chose the first of these two options, thinking that the trouble it caused would be less than the headache caused by the second.
>
> There are many other places in the schema where the "any number, any order" model is used.  We've often referred to this as the rope that users may hang themselves by.  We could adopt that policy here as well, BUT I believe the ordered model is best within the header because this is the area where users need the most guidance; that is, more restrictive models.  This choice is also similar to TEI practice, where<biblFull>  (which holds bibliographic details within<sourceDesc>) follows the model --
>
> titleStmt, editionStmt?, extent?, publicationStmt, seriesStmt?, notesStmt?
>
> --
> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de]
> Sent: Monday, August 29, 2011 4:41 AM
> To: Music Encoding Initiative
> Subject: [MEI-L] order of elements
>
> Dear MEIers,
>
> this is a somewhat technical question, but I guess of interest to nearly everyone who's producing MEI, either by hand or by software. The current schema of MEI enforces a certain order of child elements for large parts of the header. For instance, you may write
>
> <source>
>          <titleStmt>…</titleStmt>
>          <notesStmt>…</notesStmt>
>          <relatedItem>…</relatedItem>
> </source>
>
> but not
>
> <source>
>          <notesStmt>…</notesStmt>
>          <titleStmt>…</titleStmt>
>          <relatedItem>…</relatedItem>
> </source>
>
> or any other order like
>
> <source>
>          <titleStmt>…</titleStmt>
>          <relatedItem>…</relatedItem>
>          <notesStmt>…</notesStmt>
> </source>
>
> This is somewhat cumbersome when adding header elements on the fly, as you always have to check for the correct place for insertion. This is surely a technical issue without any semantic reason behind, so I'm wondering if there is a way around that. Could someone with more experience in ODD and the other schema languages provide some more background on this? Raffaele?
>
> Thanks,
> 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