[osis-core] Rome Issues list: HELP!

Fri, 31 May 2002 09:48:53 -0400

This is a multi-part message in MIME format.
--------------030406040705040409040104
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Guys,

Attached is the Rome issues list with what I think is the current 
resolution! I say I think because I have been staring at it too long to 
be sure. Think I have covered everything but may have missed something. 
Please review in detail against the schema to follow in just a few minutes.

Known open issues (ones that I think are open!)

1. Linking Aramaic to translation provided in the text itself (cite?)

2. Namespace for OSIS and URL?

Others?

Thanks!

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu

--------------030406040705040409040104
Content-Type: text/xml;
 name="RomeIssuesList_test10.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="RomeIssuesList_test10.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>

Prepared by Steven J. DeRose
Started Sat 2002-04-27
Last modified Sun 2002-04-28

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.

<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status>AIP</status>
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=''
 

<disp>Made seg a general container (phrase level) element, added TEI milestone, should suffice for shadow.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>AIP</status>
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. 

<disp>Done, now special case of reference with type attribute.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>USFM meeting</raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric, et al.</raised-by>
<status></status>
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. 
]]>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status></status>

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.

<disp>Done, note that revisionDesc added to standard Dublin core metadata.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Steve D</raised-by>
<status></status>
Should we distinguish Psalm prescriptions from generic heads? These seem to be the only headings that are part of the source texts.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Troy</raised-by>
<status></status>
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 &lt;psalm-header> or, better, &lt;original-header> (as opposed to head, which can be editorial. &lt;head resp=''> or &lt;head type=''>.

<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>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
Cantillation markup, for levels-of-break, not just the marks as glyphs.!
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
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?
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Bob P</raised-by>
<status>ACCEPTED</status>
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. 

<disp>Done, seg has become true seg container, now have milestone element.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric: </raised-by>
<status>ACCEPTED</status>
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.

<disp>Done, now have transChange element with types.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
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.

<disp>See preceeding issue for resolution.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Troy, Eric: </raised-by>
<status></status>
should divineName be collapsed into here too? Is name misleading re. non-G-d divinities?
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Bob P, Steve D: </raised-by>
<status>ACCEPTED</status>
Make front matter metadata mostly optional.

<disp>Done, only title is required. revisionsDesc, if used, requires date and resp.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
Add distinction in references, of the refsys of this pointer, vs. the document to be sought.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Steve</raised-by>
<status></status>
Need to document the detailed algorithm for resolving a reference. Priority of work fields, fallback sequence. Full set of fields:
author title language translation edition dialect refsys ref graintype grain
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
How do we mark up things like the alternate ending of Mark?
</issue>

<issue>
<date>20!
02-04-28</date>
<raised-by>Eric, Steve, Patrick, Troy: </raised-by>
<status>ACCEPTED.
</status>

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.

<disp>Done, lists now nests, optional lable element (within each list)</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
Should we distinguish genaology, inventory, etc?
REJECTED
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
Should we have 2 versions of the schema, one that prevents extending semi-open attributes, etc, and one that allows it?
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
Should we enumerate DIV types? front and back matter?
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED.</status>
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.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
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).

<disp>Done, role number reduced to ten common roles.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
Add resp to note, revisionhistory, and in dublin core. Charge Patrick to review all elements for applicability and report to list.

<disp>Done, resp also added to transChange</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
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.

<disp>Done, assuming that phraseGroup is all that is required.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
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.

<disp>Done, notes are now recursive</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Kees:</raised-by>
<status>ACCEPTED</status>
catchWord in notes: Add markup for catchphrase/referencedText; don't conflict with TEI dictionary useage (headWord).

<disp>Done, added to schema and phraseGroup, need reminder on where else it should go.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
EricReading (cf XSEM): just in notes, to show alternate reading (&quot;Some manuscripts read &apos;...&apos;, but the Hebrew reads &apos;...&apos;). Also refText? Reading's meaning inherits from note-type (translation, text-critical, exegetical). 
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
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.

<disp>Done, not sure how simplier the soup is but looks better, probably tastes worse.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status></status>
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 
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status></status>
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 &quot;having two syntaxes in same thing&quot; 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
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Kees: </raised-by>
<status>ACCEPTED</status>
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
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Steve</raised-by>
<status>ACCEPTED WITH LOUD APPLAUSE</status>
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).

<disp>OK, but we need to declare the refSys list and the regexes.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Rome tech meeting</raised-by>
<status>ACCEPTED</status>
Need spec to talk about controlled vocabulary being English. Define blind-interchange to be English.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
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.</issue>
<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>
<issue>
<date>2002-04-28</date>
<raised-by>Patrick: </raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Bob Batzinger: </raised-by>
<status>ACCEPTED</status>
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. 

<disp>Done, I included salute and signed as part of close.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>P: </raised-by>
<status>ACCEPTED</status>
Can it recurse? E checks whether there are examples. Include linegroup, but don't recurse.

<disp>Done</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>ACCEPTED</status>
E: Add salute to div for Pauline corpus? Also convenient to include salute, signed, and closer (as in TEI). If you have the container. 

<disp>Done</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by></raised-by>
<status>ACCEPTED</status>
E: Lose q and qStart/qEnd? P: It's merely there to annoy Eric. Consensus: lose q.

<disp>Was a mis-understanding. Only needed one or the other. Since dropped start/close milestones, now have q.</disp>
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>E: </raised-by>
<status>AIP</status>
What's groupLine -- gone, was error for lg.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Daud: </raised-by>
<status>AIP</status>
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. Still an open issue (I think). Is the question how to link the Aramaic phrase to its translation in the text? Could use cite? 
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Patrick, Steve: </raised-by>
<status></status>
Define a namespace and namespace URI for us. Still an open issue.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Steve: </raised-by>
<status>AIP</status>
Make sure we have outRef attributes are on div, for use in extra-Biblical works. Yes, we do.
</issue>

<issue>
<date>2002-04-28</date>
<raised-by>Steve: </raised-by>
<status></status>
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. No longer an issue since dropped start/end milestones.
</issue>

<h2>Rome meeting Monday 2002-04-29?</h2>

<issue>
<date>2002-04-29</date>
<raised-by></raised-by>
<status>E: </status>
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.

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. 

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*.
E: Have revision entries' resp attribute point to a creator declared in dublin core section.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Rome tech meeting</raised-by>
<status></status>
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?
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Bob B</raised-by>
<status></status>
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.
</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>

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.

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?

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).
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Kees</raised-by>
<status>OK</status>
Poetry subcomponents (strophe, etc)?
LG element is recursive and has type, so ok. Won't do sub-line components like metrical markup, of course.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Bob Batzinger</raised-by>
<status>ACCEPTED</status>
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'

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.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Bob Batzinger</raised-by>
<status>REJECTED</status>
There's only one translation per manuscript. What about meta-translations, or !
sources that can produce multiple dialects or versions.
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.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
Drama such as in Song of Songs. Can we identify a speaker via who on quotes (point to personDecl in header)?
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?
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).
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.
<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>
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Steve, Eric</raised-by>
<status>ACCEPTED</status>
Can you mark arbitrary sync points (say, for audio sync)?
Can do this with segStart/segEnd. E: Add a point (empty) equivalent. Names: osisPoint; point; location; anchor (definitely not 'a'); 
ACCEPTED
<disp>See new but traditional single ended milestone element.</disp>

</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>
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).

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>S: Then should let notes refer to already-labelled verses, chapters....</p>

P: No, just duplicate the key onto a like-scoped annotatedStart/annotatedEnd pair. S: But that's non-normalized, real verbose, redundant.

S: But it really shouldn't be 'annotated', since other things ought to be able to point to these, too; like references.

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.

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: 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.

S: Can define grain type string(some-unique-string) -- give the first word of the scope, or all of it.

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

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.

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.

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>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>

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.
<disp>Done, check the syntax and need reference stuff</disp>
</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>
Add castList to header.
<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>
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
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).

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"}).

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.

Should we have next/prev pointers on quotes? P: Or use
<disp>Not sure where we ended up on this one, but we currently don't have q milestones or simply q.</disp>
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Steve</raised-by>
<status></status>
S: Why are we using milestone pairs instead of chained segments? This amounts to switching TEI methods.

<p>E: Ugly; milestones seem best.</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.

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).

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.

S: I like this a lot, why didn't we work through it before? P: Let's look at it.
<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>
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
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.
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
Can we handle quasi-hand-shift, like "I, Paul"? Rather, the "signed Paul" at the very end.
Should we use signed? Yes, add to end of div. Except sometimes (Roman? 1Cor) more text comes after it (could put inside closer).
</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>
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.

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: 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.
</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>
!
How about soCalled? As in for 'those so-called apostles'. Or in scholarly remarks like "My colleagues 'exegesis' of this passage..."
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>Think on this one some more.</p>
</issue>

<issue>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
What about tables? Becoming popular to render gift lists, geneologies, and such this way.
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?
</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>

Re-organize web-site. Make it easy to find download area. Create areas for archiving texts, schemas, authority lists, namespaces, tools, etc.

Clean up old email lists. Start a general 'osis-l' for discussing biblical text encoding and OSIS issues.

Get IP agreements from all WG members -- to public domain or to BTG with GPL, or something like that.

Develop liaison with USFM group to make sure mapping works well.

Set up training for key people; set up training workshops for users. Piggyback onto SBL, CBA, ACH?, CTC,....

Complete basic manual/tutorial. Online and print, with manual interconnected with passages. Index of problem passages.

</body>
</issue>
--------------030406040705040409040104
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; }

--------------030406040705040409040104--