[MEI-L] order of elements

[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