[osis-core] OSIS: Post Rome draft
Patrick Durusau
osis-core@bibletechnologieswg.org
Mon, 06 May 2002 15:08:31 -0400
This is a multi-part message in MIME format.
--------------010408040802020806020106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Guys,
This draft will not validate and my head is too congested to keep
tracking down why XMLSpy, etc., has a problem with it. I have also
attached Steve's notes so you can see where I was attempting to go with it.
Please email specific fixes to particular parts of the schema. I will
try again tomorrow based upon your comments and suggestions to take it
to a valid schema that more fully reflects Steve's notes.
Note that I have attached a stylesheet that is different from the one
Steve originally prepared. This one sets my comments off in green so you
can quickly see what, if anything, has been done on any particular point.
I still have a doctor's appt. tomorrow at NOON but the afternoon
meeting has been cancelled so I should be back in the office by 4 PM, so
just a loss of 6 hours. :-(
Patrick
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------010408040802020806020106
Content-Type: text/xml;
name="RomeIssueList.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="RomeIssueList.xml"
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE issue [ ]>
<?xml-stylesheet href='issueList.css' type='text/css' ?>
<issue>
<body>
<h1>Rome meeting issue list</h1>
<p>Prepared by Steven J. DeRose</p>
<p>Started Sat 2002-04-27</p>
<p>Last modified Sun 2002-04-28</p>
<p>The status shown below is one of ACCEPTED, AIP (accepted in principle, or already fixed), OK (already covered), or REJECTED. Unmarked ones are not decided yet.</p>
<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status>AIP</status>
<p>Suggestion re. shadow milestones -- used to mark where to scroll to when it's not the very start of the verse. For example you may want to go to before introductory material. This should be done with segStart type='loc' ref=''
</p>
<p>
<disp>Made seg a general container (phrase level) element, added TEI milestone, should suffice for shadow.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>AIP</status>
<p>Drop otPassage and NTquotation: ot/nt offensive. Could use more general 'inter-textual-reference' instead, and process via work atribute. W!
e drop them and propose using types on ref.
</p>
<p><disp>Done, now special case of reference with type attribute.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>USFM meeting</raised-by>
<status></status>
<p>Do we want a tag to mark where book titles occur, such as in some translations' intro materials? Some editions italicize them. We could also make them references of some type.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric, et al.</raised-by>
<status></status>
<p>Genaology: Maybe just lists? Break down internals?
<![CDATA[
<gen>
<genEntry>And Abraam was the father of Jacob</genEntry>...</gen>
Other lists: Prov.22-Prov.23; 6 things the Lord hates; lists of gifts by tribe and clan in Numbers; groups of generations in Matthew.
]]>
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status></status>
<p>
Dublin-core: add as front-matter object? Copy from OEB (uses same role-set, and standard element/attribute names). Maybe pitch the whole TEI docTitle/titlePart thing in consequence (since we'r!
e not quite compatible with it anyway.
</p>
<p><disp>Done, note that revisionDesc added to standard Dublin core metadata.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Steve D</raised-by>
<status></status>
<p>Should we distinguish Psalm prescriptions from generic heads? These seem to be the only headings that are part of the source texts.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Troy</raised-by>
<status></status>
<p>Need easy way to distinguish the text from editorial stuff. Troy uses verseStart/verseEnd for this -- which means unmarked pairs for Psalm prescriptions. Does this mean you don't use verse markers in the Apocrypha? If Troy's convention in Psalms isn't required, you can't count on this anyway. Could introduce <psalm-header> or, better, <original-header> (as opposed to head, which can be editorial. <head resp=''> or <head type=''>.
</p>
<p><disp>Suggested disposition: Since the headers are in fact verses in another reference system (at least for the case of Psalms, couldn't they be marked as verses, reference system equals HebrewBible, to distinguish from the default system for the work and the stylesheet displays verses as headers that do not appear in the default reference system? At least in Psalms?</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Cantillation markup, for levels-of-break, not just the marks as glyphs.!
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Morphology: How much should it be broken down into structure? How much should be validated? How should annotations be attached to the places they apply?
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status>ACCEPTED</status>
<p>Collapse Start/End -- In non-linear media (e.g. maps, VRML models, etc.) there's no reason for "2" ends -- or 'start/end' at all. Combine. Big reason: refStart/refEnd is NOT currently parallel to verseStart/verseEnd etc. Also this lets our syntax go straight into being an XPointer scheme if we want, or being used otherwise in a URI.
</p>
<p><disp>Done, seg has become true seg container, now have milestone element.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric: </raised-by>
<status>ACCEPTED</status>
<p>Generalize supplied/changedTense. Will want to mark other kinds of deviations from your general translation philosophy; changedTense is Anglocentric. Perhaps nonLit? Not a very good !
name. Discussion of whether to try to enumerate a bunch more types, or to collapse into one element with subtypes. Subtypes get extensibility, though we also want validation. Make semi-open.
</p>
<p><disp>Done, now have transChange element with types.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Subtype nonLit as added, deleted, amplified, changed, moved. Not to include generic/specific, or from/to attributes for linking source and target texts. Lose supplied, changedTense, ampRead. cf TEI set. This is a container. sourceComparison? sourceTrace? sourceMatch? translationChange? transChange? Should allow note and w inside.
</p>
<p><disp>See preceeding issue for resolution.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Troy, Eric: </raised-by>
<status></status>
<p>should divineName be collapsed into here too? Is name misleading re. non-G-d divinities?
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Bob P, Steve D: </raised-by>
<status>ACCEPTED</status>
<p>Make front matter metadata mostly optional.
</p>
<p><disp>Done, only title is required. revisionsDesc, if used, requires date and resp.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Add distinction in references, of the refsys of this pointer, vs. the document to be sought.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Distinguish language and version fields in work, so updated editions, dialect editions like American vs. British English NIV, can be detected as being editions of the same work.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Steve</raised-by>
<status></status>
<p>Need to document the detailed algorithm for resolving a reference. Priority of work fields, fallback sequence. Full set of fields:</p>
<p>author title language translation edition dialect refsys ref graintype grain</p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>How do we mark up things like the alternate ending of Mark?
</p></issue>
<issue>
<date>20!
02-04-28</date>
<raised-by>Eric, Steve, Patrick, Troy: </raised-by>
<status>ACCEPTED.
</status>
<p>
Make lists nested. Note also need in introductory material. Need a label element (not attribute, so you can get internal structure) -- inside the item. Lets us have one list type by making label optional.
</p>
<p><disp>Done, lists now nests, optional lable element (within each list)</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Should we distinguish genaology, inventory, etc?
REJECTED
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Should we have 2 versions of the schema, one that prevents extending semi-open attributes, etc, and one that allows it?
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Should we enumerate DIV types? front and back matter?
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED.</status>
<p>What about !
divineName? Seems very special, unique. Would need its own subtype if combined with nonLit anyway. Do we want to use it for qualified forms such as yhwh elohim too? Enumerate and subtype them? Closed set? Yes unless Talmud, etc. use additional qualified forms. But if we close the set, isn't it redundant with the content? Don't want to omit content since it would be a training anomaly. Wouldn't be fully redundant because the content may be inflected or not absolutely consistently translated, so trivial programs can't check for consistency. Messy. divineName enclose the tetragrammaton phrase, but has no type attribute.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
<p>Added roles: Should we validate? No. Add list from Bob Batzinger: stylists, copyeditors, typographers,... Leave set semi-open. Should we limit to "x-" for extensions and validate for it? To do so, we should include the whole USMARC relator codes l!
ist -- unwieldy, but do it. Put top few in doc, tell them where to look for the rest (in the schema).
</p>
<p><disp>Done, role number reduced to ten common roles.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
<p>Add resp to note, revisionhistory, and in dublin core. Charge Patrick to review all elements for applicability and report to list.
</p>
<p><disp>Done, resp also added to transChange</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
<p>Add date to revision history. Explain practice that you have at least one revDesc to each cohesive set of changes done (in effect, each checkin). Should we have p in revDescs? Could just make separate revDescs; and the p level seems a waste. Instead, lose p but give revDesc the same content as p.
</p>
<p><disp>Done, assuming that phraseGroup is all that is required.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
<p>Do we need notePart? Is mainly a place to hang a reference, but would enclose not just the reference, but the !
part of the note that relates to it. Instead do a recursive note.
</p>
<p><disp>Done, notes are now recursive</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Kees:</raised-by>
<status>ACCEPTED</status>
<p>catchWord in notes: Add markup for catchphrase/referencedText; don't conflict with TEI dictionary useage (headWord).
</p>
<p><disp>Done, added to schema and phraseGroup, need reminder on where else it should go.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>EricReading (cf XSEM): just in notes, to show alternate reading ("Some manuscripts read '...', but the Hebrew reads '...'). Also refText? Reading's meaning inherits from note-type (translation, text-critical, exegetical).
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Add mentioned -- happens in notes and in source text (Dorcas, Tabitha, etc), and everywhere (not worth trying to exclude syntactically). In translation: sometimes rendered specially. Could add (may have been accidentally omitted to start with); or could put just in note. Allow in general content; try to simplify the soup model.
</p>
<p><disp>Done, not sure how simplier the soup is but looks better, probably tastes worse.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Do references have content? Currently they're basically like HTML A. Given the normalized reference in the ref attr, can we generate the rendered content from it? Eric: parsing process to get it is difficult. S: ? But then you can't
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Shouldn't have to havce special parser for references (even though it's easy, it's not easy enough). Wants to process with XSLT. Shouildn't have non-XML markup in there. S: but we already do have non-XML stuff -- dates, etc. Also how would we define an unbounded number of (extra-biblical) ref schemes? Eric: Privilege just us; extra-biblicals can be done generically. E: Against "having two syntaxes in same thing" Troy: Would you make outreferences not contain their content? E: Yes; and you always auto-g!
enerate the content for display. P: Is the real problem how we generate the display text given the complicated reference string? E: Yes. S: after all the lookup of language-specific expansion of booknames, etc., breaking it at single-character punctuation isn't hard. E: basic principle of not having non-XML substructures within XML.
REJECTED
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Specify way to transform punctuation of references, in a reference system declaration document. For example, declaration of a reference system should be able to say to change "Matt.1.1" to "The Gospel of Matthew, chapter 1, verse 1". Start with XSEM book-name declarations.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Kees: </raised-by>
<status>ACCEPTED</status>
<p>Why are we using 4-char abbreviations for book names instead of SIL/UBS 3-character bookNames? Patrick: Because they're SBL. Could of course override by tweak!
ing the schema. S: Yech. There are two big communities; one will need software. SIL never displays the 3-letter forms, though everybody has them memorized; originate in days of very constrained memory. What of Jewish forms? SBL has alternate forms for these. Everybody: not so big a deal. Consensus to go with 4-letter names
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Steve</raised-by>
<status>ACCEPTED WITH LOUD APPLAUSE</status>
<p>Underscore issue: To be ID/IDREF, we'd need initial letter, hence KNG1 instead of 1KNG etc. E: Can use schema? P: Can't guarantee uniqueness resolved between milestones, only within some ancestor's scope. E: key is no worse than ID for validation, so go with key and pitch the underscore. Can do this with compound key (refSys + ref).
</p>
<p><disp>OK, but we need to declare the refSys list and the regexes.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
<p>Need spec to talk about controlled vocabulary being English. Define blind-interchange to be English.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Poetry: no poem tag. lg meant to be recursive to cover this. fix in spec.
type is open, so can handle Philippian and other hymns.</p></issue>
<p><disp>Done, lineGroup now recusive. Note that for all recursive elements, I have tried to list the recusive element as the first one in the content model to make it easier to spot.</disp></p>
<issue>
<date>2002-04-28</date>
<raised-by>Patrick: </raised-by>
<status></status>
<p>Should we ever enumerate types? E: Yes, it's useful to have semi-open. If you go beyond it, is you can hope for a generic fallback.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Bob Batzinger: </raised-by>
<status>ACCEPTED</status>
<p>Consider whole letter included within paragraph, such as Ezra. XSEM would use blockquote (which includes salutation) for this, for prayers, peter's speech in acts, lord's prayer, liturgical formulae; other standalone blocks. P: combine quote and blockquote, adding these types? E: 1. author's decision is a statement that it can stand alone -- not just about length. 2. if use quote, you're back at milestones -- hard to format. S: Maybe get block format via making both milestones blocks, though it's ugly. E: Tried that, can do in one version of IE, not elsewhere. Consensus: add this.
</p>
<p><disp>Done, I included salute and signed as part of close.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>P: </raised-by>
<status>ACCEPTED</status>
<p>Can it recurse? E checks whether there are examples. Include linegroup, but don't recurse.
</p>
<p><disp>Done, note that lineGroup added to phraseGroup for this affect</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>ACCEPTED</status>
<p>E: Add salute to div for Pauline corpus? Also convenient to include salute, signed, and closer (as in TEI). If you have the container.
</p>
<p><disp>Done, but questionable content modeling. Put salute ahead of content in div, the grabble it again, but as part of closer.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>ACCEPTED</status>
<p>E: Lose q and qStart/qEnd? P: It's merely there to annoy Eric. Consensus: lose q.
</p>
<p><disp>Done, but not sure I remember how to mark quotations now.</disp></p>
</issue>
<issue>
<date>2002-04-28</date>
<raised-by>E: </raised-by>
<status>AIP</status>
<p>What's groupLine -- gone, was error for lg.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Daud: </raised-by>
<status>AIP</status>
<p>aramaic issue: In NRSV, 3 different renderings for mentioned: Mark 5:41 ('which mean'), Matthew 27:33 ('[which means]'), 1C 16:22 maranatha -- come our lord'. These are all foreign, not mentioned.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Patrick, Steve: </raised-by>
<status></status>
<p>Define a namespace and namespace URI for us.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Steve: </raised-by>
<status>AIP</status>
<p>Make sure we have outRef attributes are on div, for use in extra-Biblical works. Yes, we do.
</p></issue>
<issue>
<date>2002-04-28</date>
<raised-by>Steve: </raised-by>
<status></status>
<p>Add a display-form attribute to verseStart/chapStart/bookStart. They're currently empty, which means there is no choice *but* to have the display-form generated by some mechanism (or to just display the internal form). We could make verseStart etc. non-EMPTY, but that would really be gross becaus!
e the Start and End pairs would not both be empty, though they would still work as a pair.</p>
</issue>
<h2>Rome meeting Monday 2002-04-29?</h2>
<issue>
<date>2002-04-29</date>
<raised-by></raised-by>
<status>E: </status>
<p>Since we're largely using generic structures with subtypes, should all the front and back stuff be generic divs too. do we want specialized divs for front and back? Could constrain types (toc in front, biblio in back), but still couldn't constrain div type=biblio to contain only bibentry elements, etc.
</p>
<p>Easiest way to add stuff in publishing model, is to make them new element types instead of jsut divs (plus then they can constrain their content). So can expect to add new front and back matter element types (plus allow generic divs in the meantime). Generic is nice, though can't constrain internal struc.
</p>
<p>Consensus: front and back will allow generic divs. as we added specialized types that only go in front and back, we'll make them th!
eir own element types so they can have their own content models. For now, front becomes dublin_core, revision History, then div*.</p>
<p>E: Have revision entries' resp attribute point to a creator declared in dublin core section.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Div now gets only milestones, div, and p. For editions without rendered paragraphing, most still have pilcrows or some other paragraph notion. It's cleaner to avoid mixed content up at div. Such editions can insert a paragraph per verse (perverse?) as a convention.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
<p>Publisher module is not crucial overall, as publishers aren't jumping to help. SIL does need some of this, though not DRM stuff; basically enough to properly render: cover, front matter, etc. Could use the XSEM things in this domain, though the approach doesn't mesh perfectly (XSEM more f!
ocused on author-level work). Could we crank a publisher module in the core WG?</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Bob B</raised-by>
<status></status>
<p>Need to capture both editorial and typesetting markup.Eric: System like GBS uses, has both typog and descr markup ("xml-like") -- seems like this is what processing instructions are for in XML. We could define a OSIS set of PIs, but at least, fonts and such shouldn't be in the element structure per se.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Bob Batzinger</raised-by>
<status>ACCEPTED</status>
<p>He has sections, subsections, etc., but OSIS has only one level of 'segment'.</p>
<p>We do not understand this comment; we do have one element type that fulfills these functions, but it's recursive. Could mean things like Psalm 42, "The prayer of someone in exile: a continuation of Psalm 42"; basically multiple levels of leading heads on a single div.</p>
<p>We could make title and head recur!
sive, like div; thus losing titlePart and getting the needed effect. One may also want to segment titles for rendering or other funny parts; it seems odd to use recursive titles/heads for that. Could use seg instead; but then do we want to allow both seg and recursion?</p>
<p>Collapse head with title? No. Regularize to title meaning 'title of a work' (so occurs now in text, say, to refer to a book in introductory material; will later probably crop up in bibliography, and on title page). Regularize head to be for headings -- so the big heading for start of Biblical book would be a head. Head is recursive; titles aren't (we're ignoring the rare cases librarians need to deal with).</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Kees</raised-by>
<status>OK</status>
<p>Poetry subcomponents (strophe, etc)?</p>
<p>LG element is recursive and has type, so ok. Won't do sub-line components like metrical markup, of course.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Bob Batzinger</raised-by>
<status>ACCEPTED</status>
<p>Need not just language, but writing system (several variations on how this works). Should be available on everything (with lang-like inheritance). Seems as if wr system if defined mainly as one level below lang (since if two langs use similar writing systems, they're in principle not identical). Lang often gets overloaded to support things like picking spell-checkers. It gets even more complex (cf TEI). Could identify 'encoded writing system'</p>
<p>So, should this be a separate attr, or a suffic on lang? Separate. Call it ews for encoded writing system. Global. NMTOKEN for now, so can serve as an ID reference to ws declaration later if we want, and so we reserve punctuation etc. in case we want to add internal structure later.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Bob Batzinger</raised-by>
<status>REJECTED</status>
<p>There's only one translation per manuscript. What about meta-translations, or !
sources that can produce multiple dialects or versions.</p>
<p>Not sure we know what this means. Manuscript = document, yes? By dialects etc., we think he means different writing system editions from a common source. If so, that's a rendering issue. Parallel columns, diglots etc. are also a rendering issue.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Drama such as in Song of Songs. Can we identify a speaker via who on quotes (point to personDecl in header)?</p>
<p>P: We settled on speech markup for this. Speech is currently a milestone pair; do we have any actual crossings to worry about in our corpus?</p>
<p>Common enough for core? Should we allow who now, though, since we don't have a castDecl? Or add optional castDecl (check actual uses of 'who' in quotes, etc., for resolvability).</p>
<p>Add speaker inside speech. speech, blockquote, figure, and lg go where p can go. blockquote and lg can still occur in phrase da!
ta, but figure (figure is like div). Clarify that this is for drama genre; not for 'speeches' that occur within p, for which use qStart/qEnd.</p>
<p><disp>Done, but not sure if correctly. Assumed figure was a typo, and added speaker into phraseGroup so it can appear in line as opposed to lineGroup.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Steve, Eric</raised-by>
<status>ACCEPTED</status>
<p>Can you mark arbitrary sync points (say, for audio sync)?</p>
<p>Can do this with segStart/segEnd. E: Add a point (empty) equivalent. Names: osisPoint; point; location; anchor (definitely not 'a');
ACCEPTED</p>
<p><disp>See new but traditional single ended milestone element.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Why call the top 'text'?</p>
<p>Changed to 'osis'.</p>
<p><disp>Done, now outside container is osisText</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Can we constrain note placement to be at the point they apply to? Could then give it (only) a 'where-is-my-start' attribute). Implementing floating notes is a pain because you have to check after every element (at least).</p>
<p>Proposal: Place all notes in back batter !
section just for them. Insert 'annotated' markers at the point of reference, to provide a place for note to point to. This has to be mmilestones.</p>
<p>S: Then should let notes refer to already-labelled verses, chapters....</p>
<p>P: No, just duplicate the key onto a like-scoped annotatedStart/annotatedEnd pair. S: But that's non-normalized, real verbose, redundant.</p>
<p>S: But it really shouldn't be 'annotated', since other things ought to be able to point to these, too; like references. </p>
<p>E: If we just point back from the note, we have document update problems. P: though can fall back to verse level. E: Though that's kind of lame.</p>
<p>E: It's dog slow, and hard, in XSLT if you don't have markers inline for your notes. Have to check note db at least at every element.</p>
<p>P: want them to use only IDs, so they don't break. So have to insert key pair for every annotation. S: Can't do that on r/o documents at all, and it gets really big anyway.</p>
<p>S: Can define grain type string(some-unique-string) -- give the first word of the scope, or all of it. </p>
<p>E: But they'll still break even with the string.. S: So will anything, because machine can't know the intent of user's editing actions. Many frequent user operations break the intent, such as copying a section to edit somewhere else (parallels in gospels, duplicate psalms, similar phrases of all kinds). If you let </p>
<p>String approach still gives you far better recovery over editing: can immediately detect and report if a link is broken; can also report what the scope of the note's applicability actually read before it was changed; can estimate new scope (certainly to verse, and likely to scope via character-matching heuristics). Could also store numeric estimates such as original offset and length, or % of way through verse, to make more estimates possible. This also makes it easy to write an easy 'review my links' thing to run once in a while to clean up (machin!
e stops and asks at mismatching links, user can delete or drag a new scope as appropriate.</p>
<p>S: This will also work fine for eventual external databases. E: But out-of-line links are a big implementation deal. S: But if we're doing somewhat out-of-line, like end of book, it's not much easier.</p>
<p>E: Could deal with notes being required to be inline; nice to place at end of scope of applicability, and point to start. In that case it's ok to point to milestones, etc.</p>
<p>S: Sounds good; keeps it very simple, and very separate from later annotation mechanisms we know we'll want, so we don't start down an unsure path and run into later problems.</p>
<p>P: Should also have a marker attribute (TEI n) for superscript numbers, etc.</p>
<p>Consensus: Notes must go inline exactly at the end of the scope they apply to. They get an 'n' attribute. They may point to the start of their scope, using TEI target attribute; which may point to milestones, elements, and/or offsets. Add string('x') grain type, that points to the start of the first match of the string; allow backslash to make anyfollowing character literal.</p>
<p><disp>Done, check the syntax and need reference stuff</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>How would we handle things like multiple leading infoids above a chapter, like the head, a parallel passage ref, and then related-verse crossrefs?</p>
<p>Chapter head, with 2 subheads.</p>
<p><disp>Done, heads recurse</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Add castList to header.</p>
<p><disp>Pending. TEI has castList which contains phraseGroup plus castGroup (to apparently gather cast members into groups) along wth role and roleDesc elements. Not sure we need castList, better just allow recursive list in front matter and can attach whatever type yo like to the various recursive lists.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>What about quotes? OSIS doesn't require auto-generation currently, so it seems like the quotes should go in literally. Should we allow attributes to express reasons for quoting, like so sw can check. Level comes from markup, but you need direct/indirect/unspecified speech; monologue/dialog/spoken=unspecified/thought; reference to!
quoted source (citation). </p>
<p>Is this a continuation of a prior quote (Spanish makes some distinctions in things like "Hello Bill," said Tim, "how are you today". (could conceivably have a 3 case such as by appending {as he jumped up and down, "I'm fine"}). </p>
<p>initial x final; or initial/medial/final/complete. Only tradeoff is that if you use initial x final of each milestone, the middle 4 have the same setting, so you'd have to look at the other end if those 4 aren't supposed to all look the same. If we go with initial/medial/final/complete, then you can distinguish all 8 cases by looking at those 4 plus whether you're a qStart or a qEnd.</p>
<p>Should we have next/prev pointers on quotes? P: Or use</p>
<p><disp>Not sure where we ended up on this one, but we currently don't have q milestones or simply q.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Steve</raised-by>
<status></status>
<p>S: Why are we using milestone pairs instead of chained segments? This amounts to switching TEI methods.</p>
<p>E: Ugly; milestones seem best.</p>
<p>S: Would chain w/ next/prev. This means for vast majority of book/chap/verse you can just use plain old elements. You could render easier in CSS and XSLT because there are elements that have contents (so scope and inheritance works). This is likely to be better for all generic XML tools, including search engines (containment searches); editors (select element; insert one instead of two); and XSLT (can match on verses initial part, etc., and do a pull for the rest.</p>
<p>The file gets shorter on (32000v + 1000c + 66b). First by 8 chars per because of tag names not including "start" and "end". It also saves duplicating the reference on the end milestone, if you don't put it on the non-initial segments (since you can still find everything via prev/next).</p>
<p>We don't have to explain the distinction to users or Perl hackers. The chaining makes the hard cases explicit, and you can always distinguish initial/medial/final via next/prev attributes. And it would be parallel to quotes discussed above.</p>
<p>S: I like this a lot, why didn't we work through it before? P: Let's look at it.</p>
<p><disp>OK, but what does it mean in terms of a content model? Should I allow book/chapter as types of divs and a div content model is a choice (how I implemented it this round) that allows choice of p (which can contain verse) or verse for your basic content model? There are some things, like lineGroup that cannot be contained in verse, so I would need two soup models instead of one, although I don't see that as an argument against going this way.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>E: What is our response to someone who marks up their text basically just with a tons of segs, or designs tons of extensions using them? Results won't be interoperable.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Can we handle quasi-hand-shift, like "I, Paul"? Rather, the "signed Paul" at the very end.</p>
<p>Should we use signed? Yes, add to end of div. Except sometimes (Roman? 1Cor) more text comes after it (could put inside closer).</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Linking to dictionaries, you may want to link a word-instance to a particular sense entry.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>w tag is a bit awkward when enclosing stuff that's a "word" in the source, but several in the target. For example, "of the Lord" vs. "Kuriou". Esp. since we'd be using it for morph relative to receptor lang, even though it's "w"-ness is about the source.</p>
<p>S: All the attributes of w are ambiguous this way: we could want to encode a lemmatization of the present text, or a pointer to the source lemma. In OT might want to do Hebrew, LXX, and receptor.... So this solutions get potentially very gross.</p>
<p>P: With lemma we were thinking of simplistic mapping from receptor to original: sourceLemma. (Twisted idea: Declare Strong's numbers as a name authority list; make a version of GNT with just Strong's numbers, and mouseOver to show word). Same with morph, pos.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>How about abbr?</p>
<p>Add it.</p>
<p><disp>Done.</disp></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>!
How about soCalled? As in for 'those so-called apostles'. Or in scholarly remarks like "My colleagues 'exegesis' of this passage..."</p>
<p>Could be abused easily (to get quotation marks?). We don't have term either, as in for introductory materials, or stuff in commentaries. Could move to a non-Biblical materials module; but intro material in a Bible can do most of this too.</p>
<p>Think on this one some more.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>What about tables? Becoming popular to render gift lists, geneologies, and such this way.</p>
<p>Gak. But anything more specific won't cover the range of cases. P: real test is adoption; this might help. Require a header row to help with retrieval?</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>OK</status>
<p>Introductory material in divs</p>
<p>Use div type='introductory'</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Figures</p>
<p></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
<p></p>
</issue>
<h1>Translation module ideas</h1>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Specialized note types: 2 types in XSEM due to difference in allowing resp; we have resp on all notes.</p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>
<!--
<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>
-->
<h2>Produce real lists and declarations for</h2>
<p>
SBL style guide items
</p>
<p>
Bible vers!
ions
</p>
<p>
Person and place names (by canons?)
</p>
<p>
Front and back matter div types
</p>
<h2>Marketing, admin, organization tasks</h2>
<p>
Re-organize web-site. Make it easy to find download area. Create areas for archiving texts, schemas, authority lists, namespaces, tools, etc.
</p>
<p>
Clean up old email lists. Start a general 'osis-l' for discussing biblical text encoding and OSIS issues.
</p>
<p>
Get IP agreements from all WG members -- to public domain or to BTG with GPL, or something like that.
</p>
<p>
Develop liaison with USFM group to make sure mapping works well.
</p>
<p>
Set up training for key people; set up training workshops for users. Piggyback onto SBL, CBA, ACH?, CTC,....
</p>
<p>
Complete basic manual/tutorial. Online and print, with manual interconnected with passages. Index of problem passages.
</p>
</body>
</issue>
--------------010408040802020806020106
Content-Type: text/css;
name="issueList.css"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="issueList.css"
/* Stylesheet for simple issue lists.
Written April 29, 2002 by Steven J. DeRose. Modified May 6, 2002 by Patrick Durusau to add disp, short for disposition by PLD
*/
issue { display:block; border-top:2px;
margin-top:18pt; margin-bottom:18pt; margin-left:18pt;}
issue:before { display:block; color:blue; content:attr(date);}
date { display:block; font-weight:bold; color: purple; }
raised-by { display:block; font-weight:bold; color: purple; }
status { display:block; font-weight:bold; color: red; }
disp { display:block; font-weight:bold; color: green; }
p { display:block; margin-left:18pt; margin-right:18pt; margin-top:6pt; }
h1 { margin-top:36pt; font-size:24pt; font-weight:bold;
color:blue; display:block; }
h2 { margin-top:24pt;border-top:2pt blue groove; font-size:18pt; display:block; }
pre { font-family:monospace; margin-top:12pt; margin-bottom:12pt;
white-space: pre; }
--------------010408040802020806020106
Content-Type: text/plain;
name="OSISCore_PostRome.xsd"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="OSISCore_PostRome.xsd"
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:dc="http://purl.org/dc/elements/1.0"
elementFormDefault="unqualified">
<xs:annotation>
<xs:documentation> OSISCore_PostRome.xsd <p>
<date>2002-05-06</date>
<version>1.0.PR.1</version>
This is the first complete revision of the OSIS schema since the meetings in Rome. I have attempted to use XML comments to allow the original text to remain along side the changes and have inserted a number of comments based upon the discussions in Rome. I will also prepare a clean version of the new schema for use in authoring/conversion, as this one is more suited for discussion of the various changes.</p>
<p> Note that I have substantially reorganized the schema to (hopefully) make it easier to follow. New organization starts with the high level containers, osisText for example, as the ultimate container element (name subject to debate/change), which contains a header (primarily OEB/Dublin Core elements, that replace our title/titlePart elements. Most of the elements in the metadata header are optional. That is followed by the usual suspects, front, body and back. I then follow with the larger divisions, front, body and back. Those large divisions are followed by the various elements and content models for those elements. After all the structural stuff, then I have the simpleTypes and other material.</p>
<p>Among the more significant changes are the loss of milestones and their replacement with segmentation of elements that bear next and previous attributes. The reasoning for this change was that boundary crossing elements are the exception and not the rule, hence only those cases should require unusual markup, as opposed to requiring milestones for all possible crossing elements. Since elements require a known context (unlike milestones) it will be possible to use the key/keyref mechanism for validation of these references.</p>
</xs:documentation>
</xs:annotation>
<xs:element name="osisText">
<xs:complexType>
<xs:annotation>
<xs:documentation>
<p>Header and body elements are required and in that sequence. Front and back are optional (front primarily optional to allow quick start on encoding, most texts will have one.</p>
<p>Rome changes: Added header, loses title/titlePart (within divs/books/chaps/etc. becomes recursive head). Made front optional to allow quick start to encoding. Header has Dublin Core materials drawn from OEB and the role attribute cut down to ten (10) possible roles. See the final section of the schema for roles and other simple type declarations.</p>
<p>Attribute changes: note that attributes now distinguish both the work and refSys for a text.</p>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="header"/>
<xs:element ref="front" minOccurs="0"/>
<xs:element ref="body"/>
<xs:element ref="back" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="work" type="osisWork" use="optional"/>
<xs:attribute name="refSys" type="osisRef" use="optional"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="osisWork">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="osisRef">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<!-- Note that syntax for osisWork and osisRef need to be written, Steve mongo regex? -->
<!-- Need namespace declarations for Dublin Core elements as well -->
<xs:element name="header">
<xs:annotation>
<xs:documentation>
<p>Rome changes: Most of this information was in front and required in the earlier version of OSIS. Have moved the metadata information into the header element and made most of it optional. Only dc:title required. Note that we recommned revisionDesc be used and if it is, it does have required sub-elements of date and resp. </p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="dc:Contributor" minOccurs="0"/>
<xs:element ref="dc:Title" minOccurs="1"/>
<xs:element ref="dc:Creator" minOccurs="0"/>
<xs:element ref="dc:Subject" minOccurs="0"/>
<xs:element ref="dc:Description" minOccurs="0"/>
<xs:element ref="dc:Publisher" minOccurs="0"/>
<xs:element ref="dc:Date" minOccurs="0"/>
<xs:element ref="dc:Type" minOccurs="0"/>
<xs:element ref="dc:Format" minOccurs="0"/>
<xs:element ref="dc:Identifier" minOccurs="0"/>
<xs:element ref="dc:Source" minOccurs="0"/>
<xs:element ref="dc:Language" minOccurs="0"/>
<xs:element ref="dc:Relation" minOccurs="0"/>
<xs:element ref="dc:Coverage" minOccurs="0"/>
<xs:element ref="dc:Rights" minOccurs="0"/>
<xs:element ref="revisionDesc" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="dc:Contributor">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Title" minOccurs="1">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Creator" minOccurs="0" maxOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="resp" type="xs:string" use="required"/>
<xs:attribute name="role" type="role" use="required"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Subject" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Description" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Publisher" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Date" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Type" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Format" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Identifier" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Source" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Language" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Relation" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Coverage" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="dc:Rights" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="revisionDesc" minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType>
<xs:sequence>
<xs:element ref="date" minOccurs="1"/>
<xs:element ref="resp" minOccurs="1"/>
<xs:group ref="phraseGroup" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attribute name="TEIform" fixed="revisionDesc"/>
</xs:complexType>
</xs:element>
<xs:element name="front">
<xs:annotation>
<xs:documentation>
<p>Note that with the addition of the header element, the various sub-elements such as titleGroup, author, date, copyright, publisher, pubPlace, revisionDesc have been removed. Not really compatible with TEI anyway. Now contains only div and global attributes. Note that div is recursive and contains generic content. Note that title is recursive so can have subtitles and the like.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="title" minOccurs="0"/>
<xs:element ref="div" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="body">
<xs:annotation>
<xs:documentation>
<p>Major Rome changes were the elimination of the titleGroup, since that information is carried in the header. The div element contains a recursive header for title type information that should be recorded in the body.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="title" minOccurs="0"/>
<xs:element ref="div" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attribute name="TEIform" fixed="body"/>
<xs:attributeGroup ref="referenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="back">
<xs:complexType>
<xs:sequence>
<xs:element ref="title" minOccurs="0"/>
<xs:element ref="div" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attribute name="TEIform" fixed="back"/>
<xs:attributeGroup ref="referenceAttributes"/>
</xs:complexType>
</xs:element>
<!-- end of main structural elements of header, front, body and back -->
<!-- Begin listing of lower level elements and their content groups -->
<xs:element name="abbr">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="expansion" type="xs:string" use="optional"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="blockQuote">
<xs:annotation>
<xs:documentation>
<p>My notes indicate salute, note, p, phrase-class, close-salute-signed. Should all these be separate elements in the sequence or should close contain salute-signed? Have modeled it that way but open to suggestions.</p>
</xs:documentation>
<xs:complexType>
<xs:sequence>
<xs:element ref="salute" minOccurs="0" maxOccurs="1"/>
<xs:element ref="p" minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="speaker" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="close" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="catchWord">
<xs:complexType mixed="true">
<xs:sequence>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="close">
<xs:annotation>
<xs:documentation>
<p>Note that both salute and signed contain phrase-class elements.</p>
</xs:documentation>
<xs:complexType mixed="true">
<xs:sequence>
<xs:element ref="salute" minOccurs="0" maxOccurs="1"/>
<xs:element ref="signed" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="date">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
<xs:attribute name="calendar" type="calendar" use="optional" default="ISO"/>
<xs:attribute name="value" use="optional"/>
<xs:attribute name="TEIform" fixed="date"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="calendar">
<xs:restriction base="xs:string">
<xs:enumeration value="Chinese"/>
<xs:enumeration value="Gregorian"/>
<xs:enumeration value="Islamic"/>
<xs:enumeration value="ISO"/>
<xs:enumeration value="Jewish"/>
<xs:enumeration value="Julian"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="div">
<xs:complexType>
<xs:choice>
<xs:sequence maxOccurs="unbounded">
<xs:element ref="div" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="p" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="closer" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="figure" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref=lineGroup" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="salute" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="speech" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence maxOccurs="unbounded">
<xs:element ref="div" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="verse" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="closer" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="figure" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref=lineGroup" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="salute" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="speech" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:choice>
<xs:attribute name="lang" type="languageType" use="optional"/>
<xs:attribute name="type" type="divType" use="optional"/>
<xs:attribute name="divTitle" type="xs:string" use="optional"/>
<xs:attributeGroup ref="inReferenceAttributes"/>
<xs:attributeGroup ref="segmentAttributes"/>
<xs:attribute name="TEIform" fixed="div"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="divType">
<xs:union memberTypes="divsOSIS attributeExtension"/>
</xs:simpleType>
<xs:simpleType name="divsOSIS">
<xs:annotation>
<xs:documentation>
<p>Enumerated list of types of div elements in an OSIS text. Note that users can add types of divs using the x- extension prefix on their type names.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="appendix"/>
<xs:enumeration value="book"/>
<xs:enumeration value="chapter"/>
<xs:enumeration value="concordance"/>
<xs:enumeration value="glossary"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="divineName">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="figure">
<xs:complexType>
<xs:sequence>
<xs:element name="caption" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="src" type="xs:string" use="required"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="foreign">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="head">
<xs:complexType>
<xs:sequence>
<xs:element ref="head" minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="inscription">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="item">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element ref="label" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="label">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="line">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="lineGroup">
<xs:complexType>
<xs:sequence>
<xs:element ref="lineGroup" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="line" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="list">
<xs:complexType>
<xs:sequence>
<xs:element ref="list" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="head" minOccurs="0"/>
<xs:element ref="item" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="mentioned">
<xs:complexType mixed="true">
<xs:sequence>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="milestone">
<xs:annotation>
<xs:documentation>
<p>Added to make explicit the shadown milestone requested by BobP. Don't think you need a loc attribute with the inReferenceAttribute group but am open to comments. Since you have the ref attribute in inRefAttributes. May want to add the generic n attribute so people can make pages, etc.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attributeGroup name="inReferenceAttributes"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="name">
<xs:annotation>
<xs:documentation>
<p>An element with an attribute simiar to role that allows a semi-open attribute for specifying what type of name is being recorded in the markup. Examples include person, geographic, etc. Note the general format for enumerated values: a list is declared as a simpleType and then followed by a union statement combining that list with the attributeExtension simpleType which contains a regular expression constraining additions to the OSIS enumerated list to begin with the string "x-". This allows OSIS to speify a list of values and yet allow users to extend that list.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="nameType" type="nameType" use="required"/>
<xs:attribute name="regular" type="xs:string" use="optional"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="namesOSIS">
<xs:annotation>
<xs:documentation>
<p>Enumerated list of name types commonly found in biblical texts.</p>
<p>The attribute nonhuman was inserted to allow the marking of names that are not encoded with the element divineName. The divineName element was introduced to treat name occurences that are treated differently, i.e., the setting of Lord in small caps, to represent a name in the original text. Rather than attempt to enumerate all the varying traditions for such practices, the divineName element simply recognizes it and allows encoders to follow that practice (or not) as they desire.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="geographic"/>
<xs:enumeration value="holiday"/>
<xs:enumeration value="nonhuman"/>
<xs:enumeration value="person"/>
<xs:enumeration value="ritual"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="nameType">
<xs:union memberTypes="namessOSIS attributeExtension"/>
</xs:simpleType>
<xs:element name="note">
<xs:annotation>
<xs:documentation>
<p>Note that note is now recursive, which allows the elimination of notePart. Has enumerated list of note types.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:element ref="note" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="catchWord" minOccurs="0" maxOccurs="1"/>
<xs:element ref="p" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="reading" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:ID" use="optional"/>
<xs:attribute name="lang" type="languageType" use="optional"/>
<xs:attribute name="n" type="xs:string" use="optional"/>
<xs:attribute name="resp" type="xs:string" use=optional"/>
<xs:attribute name="type" type="noteType" use="required"/>
<xs:attribute name="TEIform" fixed="note"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="noteType">
<xs:union memberTypes="notesOSIS attributeExtension"/>
</xs:simpleType>
<xs:simpleType name="notesOSIS">
<xs:annotation>
<xs:documentation>
<p>Enumerated list of note types for biblical texts. This list can be extended using the <x-> extension in front of other note types added by users.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="allusion"/>
<xs:enumeration value="alternative"/>
<xs:enumeration value="background"/>
<xs:enumeration value="citation"/>
<xs:enumeration value="devotional"/>
<xs:enumeration value="exegesis"/>
<xs:enumeration value="explanation"/>
<xs:enumeration value="study"/>
<xs:enumeration value="translation"/>
<xs:enumeration value="variant"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="p">
<xs:complexType mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="reading">
<xs:complexType mixed="true">
<xs:sequence maxOccurs="unbounded">
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="reference">
<xs:annotation>
<xs:documentation>
<p>Note otPassage and ntProphecy have been dropped as elements. Actually references, inter-textual for post-modernists, and should be marked as such. Can use extensible type attribute to denote a typology of references. I have added the target attribute as xs:string but we may (or may not) want to force some validation on that attribute. Tend to favor not, since we don't know what reference someone might wish to point to and validity is their problem.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="referenceTo" target="xs:string" type="referenceType" use="optional"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="referenceType">
<xs:union memberTypes="referenceOSIS attributeExtension"/>
</xs:simpleType>
<xs:simpleType name="referenceOSIS">
<xs:annotation>
<xs:documentation>
<p>Partial list reference types for biblical texts. This list can be extended using the <x-> extension in front of other note types added by users.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="allusion"/>
<xs:enumeration value="paraphrase"/>
<xs:enumeration value="quotation"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="salute">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="who" type="xs:string"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="seg">
<xs:annotation>
<xs:documentation>
<p>Decided to not abuse the seg element from TEI as a milestone. Returned to its traditional role of marking arbitrary segments of text (although it must properly nest). Should give us a little more flexibility in allowing markup of phrase level stuff we have not thought of up to this point.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType mixed="true"?
<xs:sequence>
<xs:element ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="signed">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="who" type="xs:string"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="speech">
<xs:complexType>
<xs:sequence>
<xs:element ref="speaker" minOccurs="0" maxOccurs="1"/>
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="speaker">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="who" type="xs:string"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="title">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element ref="phraseGroup minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attribute name="TEIform" fixed="title"/>
</xs:complexType>
</xs:element>
<xs:element name="transChange">
<xs:annotation>
<xs:documentation>
<p>Bad name but all we could think of, please suggest better! Takes the place of ampRead, supplied, changedTenes. Supply types to enumerate added, deleted, amplified, changed, moved, other possibles, sourceComparison, sourceTrace, sourceMatch, transChange. Have not enumerated all in the list below but just a couple to act as place holders while we work out the scope of this element.</p>
</xs:documentation>
</xs:annotation>
<xs:complexType mixed="true">
<xs:sequence>
<xs:element ref="note" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="w" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="resp" type="xs:string" use="optional"/>
<xs:attribute name="transChange" type="transChangeType" use="optional"/>
<xs:attributeGroup ref="globalAttributes">
</xs:complexType>
</xs:element>
<xs:simpleType name="transChangeType">
<xs:union memberTypes="nonLitOSIS attributeExtension"/>
</xs:simpleType>
<xs:simpleType name="transChangeOSIS">
<xs:annotation>
<xs:documentation>
<p>Partial list of translation change types for biblical texts. This list can be extended using the <x-> extension in front of other types added by users.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="added"/>
<xs:enumeration value="amplified"/>
<xs:enumeration value="changed"/>
<xs:enumeration value="deleted"/>
<xs:enumeration value="moved"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="verse">
<xs:complexType mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:group ref="phraseGroup" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="outReferenceAttributes"/>
<xs:attributeGroup ref="segmentAttributes"/>
<xs:attributeGroup ref="globalAttributes"/>
</xs:complexType>
</xs:element>
<xs:element name="w">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="POS" type="attributeExtension" use="optional"/>
<xs:attribute name="morph" type="attributeExtension" use="optional"/>
<xs:attribute name="lemma" type="attributeExtension" use="optional"/>
<xs:attribute name="gloss" type="xs:string" use="optional"/>
<xs:attribute name="xlit" type="xs:string" use="optional"/>
<xs:attribute name="TEIform" fixed="w"/>
<xs:attributeGroup ref="globalAttributes"/>
<xs:attributeGroup ref="outReferenceAttributes"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- end new element listing -->
<!-- Global Attributes and simpleTypes -->
<xs:simpleType name="attributeExtension">
<xs:annotation>
<xs:documentation>
<p>Where attribute values are declared, users can extend the allowed values by prepending the string "x-" to the values they desire to use. Attribute values are declared as the union of an enumerated set of values and this attributeExtension type.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="x-([^\s]+)"/>
</xs:restriction>
</xs:simpleType>
<xs:attributeGroup name="globalAttributes">
<xs:attribute name="ews" type="xs:key" use="optional"/>
<xs:attribute name="ID" type="xs:ID" use="optional"/>
<xs:attribute name="lang" type="languageType" use="optional"/>
<xs:attribute name="type" type="xs:string" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="inReferenceAttributes">
<xs:attribute name="ref" type="Define" use="required"/>
<xs:attribute name="refSys" type="Define" use="optional"/>
<xs:attribute name="work" type="Define" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="outReferenceAttributes">
<xs:attribute name="ref" type="refType" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="segmentAttributes">
<xs:attribute name="next" type="xs:string" use="optional"/>
<xs:attribute name="prev" type="xs:string" use="optional"/>
</xs:attributeGroup>
<!-- Element Groups -->
<xs:group name="phraseGroup">
<xs:annotation>
<xs:documentation>
<p>A group for common annotations recorded on a text.</p>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="abbr" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="blockQuote" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="divineName" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="foreign" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="inscription" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="lineGroup" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="list" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="mentioned" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="milestone" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="name" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="note" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="reference" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="seg" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="speaker" mixOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="title" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="w" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<!-- SimpleType Declarations -->
<!-- Role simpleType for the header element -->
</xs:simpleType>
<xs:simpleType name="role">
<xs:annotation>
<xs:documentation>
<p>This is a selected set of the most common role names likely to be needed for basic encoding. The full set of relator codes on which this listing (and the descriptions are based, was taken from: MARC Code List: Relator Codes -- Term Sequence (http://lcweb.loc.gov/marc/relators/re0002r1.html). This listing will be followed for later OSIS modules.</p>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="art">
<xs:annotation>
<xs:documentation>Artist: Use for a person (e.g., a painter) who conceives, and perhaps also implements, an original graphic design or work of art, </xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="aut">
<xs:annotation>
<xs:documentation>Author: Use for a person or corporate body chiefly responsiblefor the intellectual or artistic content of a work, usually printed text. This term may also be used when more than one person or body bears such responsibility.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="aft">
<xs:annotation>
<xs:documentation>Author of afterword, colophon, etc.: Use for a person or corporate body responsible for an afterword, postface, colophon, etc. but who is not the chief author of a work.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="aui">
<xs:annotation>
<xs:documentation>Author of introduction, etc.: Use for a person or corporate body responsible for an introduction, preface, foreword, or other critical introductory matter, but who is not the chief author.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="clb">
<xs:annotation>
<xs:documentation>Collaborator: Use for a person or corporate body that takes a limited part in the elaboration of a work of another person or corporate body that brings complements (e.g., appendices, notes) to the work.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="cwt">
<xs:annotation>
<xs:documentation>Commentator for written text: Use for a person or corporate body responsible for the commentary or explanatory notes about a text.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="com">
<xs:annotation>
<xs:documentation>Compiler: Use for a person who produces a work or publication by selecting and putting together material from the works of various persons or bodies.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="ctb">
<xs:annotation>
<xs:documentation>Contributor: Use for one whose work has been contributed to a larger work, such as an anthology, serial publication, or other compilation of individual works. Do not use for someone whose sole function in relation to a work is as author, editor, compiler or translator.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="edt">
<xs:annotation>
<xs:documentation>Editor: Use for a person who prepares for publication a work not primarily his/her own, such as by elucidating text, adding introductory or other critical matter, or technically directing an editorial staff.</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="trl">
<xs:annotation>
<xs:documentation>Translator: Use for a person who renders a text from one language into another, or from an older form of a language into the modern form.</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:schema>
--------------010408040802020806020106--