[MEI-L] order of elements

[Joachim Veit]

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

-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : veit.vcf
Dateityp    : text/x-vcard
Dateigr??e  : 364 bytes
Beschreibung: nicht verf?gbar
URL         : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110829/6884d359/attachment.vcf>