[osis-core] Outstaning Comments/Concerns?

Tue, 25 Jun 2002 13:44:14 -0400

--============_-1187094630==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 07:56 AM -0400 06/25/02, Patrick Durusau wrote:
>Greetings,
>
>Other than the outstanding questions voiced by Harry last Friday 
>(simple links and emph problems) are there any other major items on 
>the table? (I realize that Troy has deferred to some degree his 
>concern on overlaps to OSIS 2.0. It is also one of my major research 
>interests so I will be working on it in the meantime as well.)
>
>I will be spending most of the day on house-keeping sorts of things, 
>removing the various revision comments, moving comments on best 
>practices to annotation elements in the schema, etc.,  so please 
>forward anything that you thing we need to include.
>
>Will try to issue a version by late afternoon or early evening that 
>reflects what I view as our current consensus (this may not in fact 
>be our current consensus so do not be offended but politely point 
>out where I have fallen short. If you disagree with it, it is clear 
>that I have not accurately reported our consensus. That is error on 
>my part, to fail to speak up is error on yours. ;-)

I think we're mostly ok other than that.

Oh, there's my question about date-systems vs. date-formats.

And I don't recall if we actually decided re. whether to add an 
optional TEI header slot (I'm in favor, I think).

Well, I just pulled out the Rome Issues List, wasted an hour writing 
a script to auto-number the issues (result enclosed), and found a few 
things we should still discuss:

C-001: "Shadow milestones' for where to scroll to when it isn't just 
the default of top of unit (say, scrolling to before a header or 
intro material, etc)

C-004, C-018: Did we decide genealogy would just be list? C-018 
records rejecting adding genealogy per se.

C-011, C-012: Did we resolve "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."

C-016: What syntax did we settle on for separting language, version, 
edition, author, title, etc within 'work'?

C-018: What did we decide is the proper way to mark up, say, the 
alternate ending to Mark?

C-025: Did we add 'resp' attribute to various places?

C-037: Did we remember to add poem tag?

C-039: I don't remember this clearly, but I think we haven't fixed it yet.

C-045: We need to document a namespace URI for us.

C-056: We should check that speaker occurs in the various additional 
places listed in this issue.

C-061: Add castList to header (was accepted).

C-062: Need some more complicated details for broken quotes.... Gets 
complicated, seems as if each quote milestone needed to identify 
itself as initial/medial/final/complete, as well as knowing whether 
it's a start or end milestone. How best to map that to containers is 
also interesting.

Not bad, I think. Can we nail these in the next day or so (plus 
whatever else comes up?

Everybody should take a look at the issue list and point out anything 
I missed, or contribute other things we should add to said list (hey, 
if you copy the XML and fill in the blanks, we can just paste it in, 
which would be real nice).

-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sderose@mac.com, sjd@stg.brown.edu
--============_-1187094630==_============
Content-Id: <a05111713b93e4aeb8a17@[192.168.1.101].0.0>
Content-Type: text/plain; name="RomeIssueList.xml"; charset="us-ascii" ; format="flowed"
Content-Disposition: attachment; filename="RomeIssueList.xml"
 ; modification-date="Tue, 25 Jun 2002 13:22:41 -0400"

<?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>
<issueNum>C-001</issueNum>
<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=''

</issue>

<issue>
<issueNum>C-002</issueNum>
<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. We drop them and propose using types on ref.
</issue>

<issue>
<issueNum>C-003</issueNum>
<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>
<issueNum>C-004</issueNum>
<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>
<issueNum>C-005</issueNum>
<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're not 
quite compatible with it anyway.
</issue>

<issue>
<issueNum>C-006</issueNum>
<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>
<issueNum>C-007</issueNum>
<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=''>.
</issue>

<issue>
<issueNum>C-008</issueNum>
<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>
<issueNum>C-009</issueNum>
<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>
<issueNum>C-010</issueNum>
<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.
</issue>

<issue>
<issueNum>C-011</issueNum>
<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.
</issue>

<issue>
<issueNum>C-012</issueNum>
<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.
</issue>

<issue>
<issueNum>C-013</issueNum>
<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>
<issueNum>C-014</issueNum>
<date>2002-04-28</date>
<raised-by>Bob P, Steve D: </raised-by>
<status>ACCEPTED</status>
Make front matter metadata mostly optional.
</issue>

<issue>
<issueNum>C-015</issueNum>
<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>
<issueNum>C-016</issueNum>
<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>
<issueNum>C-017</issueNum>
<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>
<issueNum>C-018</issueNum>
<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>
<issueNum>C-019</issueNum>
<date>2002-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.
</issue>

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

<issue>
<issueNum>C-021</issueNum>
<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>
<issueNum>C-022</issueNum>
<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>
<issueNum>C-023</issueNum>
<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>
<issueNum>C-024</issueNum>
<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 list -- unwieldy, but 
do it. Put top few in doc, tell them where to look for the rest (in 
the schema).
</issue>

<issue>
<issueNum>C-025</issueNum>
<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.
</issue>

<issue>
<issueNum>C-026</issueNum>
<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.
</issue>

<issue>
<issueNum>C-027</issueNum>
<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.
</issue>

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

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

<issue>
<issueNum>C-030</issueNum>
<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.
</issue>

<issue>
<issueNum>C-031</issueNum>
<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>
<issueNum>C-032</issueNum>
<date>2002-04-28</date>
<raised-by>Eric</raised-by>
<status></status>
Shouldn't have to have 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-generate 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>
<issueNum>C-033</issueNum>
<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>
<issueNum>C-034</issueNum>
<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 tweaking 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>
<issueNum>C-035</issueNum>
<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).
</issue>

<issue>
<issueNum>C-036</issueNum>
<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>
<issueNum>C-037</issueNum>
<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>

<issue>
<issueNum>C-038</issueNum>
<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>
<issueNum>C-039</issueNum>
<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.
</issue>

<issue>
<issueNum>C-040</issueNum>
<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.
</issue>

<issue>
<issueNum>C-041</issueNum>
<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.
</issue>

<issue>
<issueNum>C-042</issueNum>
<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.
</issue>

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

<issue>
<issueNum>C-044</issueNum>
<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.
</issue>

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

<issue>
<issueNum>C-046</issueNum>
<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>
<issueNum>C-047</issueNum>
<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 because the Start and End pairs would not both 
be empty, though they would still work as a pair.
</issue>

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

<issue>
<issueNum>C-048</issueNum>
<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 
their 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>
<issueNum>C-049</issueNum>
<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>
<issueNum>C-050</issueNum>
<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 focused on author-level work). Could we crank a 
publisher module in the core WG?
</issue>

<issue>
<issueNum>C-051</issueNum>
<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>
<issueNum>C-052</issueNum>
<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 recursive, 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>
<issueNum>C-053</issueNum>
<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>
<issueNum>C-054</issueNum>
<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>
<issueNum>C-055</issueNum>
<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>
<issueNum>C-056</issueNum>
<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 data, 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.
</issue>

<issue>
<issueNum>C-057</issueNum>
<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
</issue>

<issue>
<issueNum>C-058</issueNum>
<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>
</issue>

<issue>
<issueNum>C-059</issueNum>
<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 (machine 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.

</issue>

<issue>
<issueNum>C-060</issueNum>
<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>
</issue>

<issue>
<issueNum>C-061</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>Add castList to header.</p>
</issue>

<issue>
<issueNum>C-062</issueNum>
<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

</issue>

<issue>
<issueNum>C-063</issueNum>
<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.

</issue>

<issue>
<issueNum>C-064</issueNum>
<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>
<issueNum>C-065</issueNum>
<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>
<issueNum>C-066</issueNum>
<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>
<issueNum>C-067</issueNum>
<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>
<issueNum>C-068</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status>ACCEPTED</status>
<p>How about abbr?</p>
<p>Add it.</p>
</issue>

<issue>
<issueNum>C-069</issueNum>
<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>
<issueNum>C-070</issueNum>
<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>
<issueNum>C-071</issueNum>
<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>
<issueNum>C-072</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p>Figures</p>
<p></p>
</issue>

<issue>
<issueNum>C-073</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
<p></p>
</issue>

<h1>Translation module ideas</h1>

<issue>
<issueNum>C-074</issueNum>
<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>
<issueNum>C-075</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>

<issue>
<issueNum>C-076</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>

<issue>
<issueNum>C-077</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>

<issue>
<issueNum>C-078</issueNum>
<date>2002-04-29</date>
<raised-by>Eric</raised-by>
<status></status>
<p></p>
</issue>

<issue>
<issueNum>C-079</issueNum>
<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 versions
</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>
--============_-1187094630==_============--