[osis-core] Dallas TC meeting minutes for May 22
Kirk Lowery
osis-core@bibletechnologieswg.org
Thu, 22 May 2003 18:50:13 -0400
Also at: http://whi.wts.edu/OSIS/admin
--
Kirk E. Lowery, Ph.D.
Director, Westminster Hebrew Institute
Adjunct Professor of Old Testament
Westminster Theological Seminary, Philadelphia
Theorie ist, wenn man alles weiss und nichts klappt.
Praxis ist, wenn alles klappt und keiner weiss warum.
Bei uns sind Theorie und Praxis vereint:
nichts klappt und keiner weiss warum!
OSIS TECHNICAL COMMITTEE MINUTES
May 22, 2003
TC members present:
Steve DeRose, chair
Kees Deblois, vice-chair
Patrick Durusau
Troy Griffits
Kirk Lowery, secretary pro tem
Mike Perez
Todd Tillinghast
Issues and Decisions
[1.1.1] Remove dead element <cell>
ACCEPTED
[1.1.2] Milestones
Background:
<milestone> marks special breaks. <milestoneSE> encapsules <closer>,
<abbv>, <div>, etc. It is intended to be a stand-in for crossing
elements. It's the overlapping hierarchy solution.
Two views of markup hierarchy: (1) BSP (Book, Section, Paragraph)
approach: viewing the biblical text hierarchy as pericopes, chapter and
verse secondary; (2) BCV (Book, Chapter, Verse) approach: chapter and
verse primary, pericopes secondary.
From software point of view: BCV preferred. Academics like it. BFES
likes it. UBS/ABS/SIL like BSP. One way is better than two. Can satisfy
the BCV camp using osisRefs using BSV.
Proposed:
Applications must support BSP (BCV optional)
Documents, including Bible texts must include osisIDs
Add "chapter" to <mileStoneSE> type attribute
Keep <verse>container, which is canonical container for Bibles, but
other texts (e.g., Church fathers) have canonical containers, too.
So we need to specify "what container(s) are canonical?"See point
5.
An attribute called canonical is globally available and always
optional, inherits like lang attribute.
The default for <verse> is canonical true, for <note> is canonical
false and no other element type specifies a default for the
canonical attribute; if canonical is true, require osisID; create
<chapter> element; add chapter to mileStoneSe type; remove chapter
from div type; <chapter> is optional splitID attribute; <div> does
not have a splitID
Elements that cannot be splittable
osis
osisText
osisCorpus
div
head.*
If <div>crosses chapter, <chapter>must break (either splitID or
mileStone).
milestoneStart, milestoneEnd, should be globalWithoutType,
attribute value should be milestoneSE which now does not combine
with osisMilestoneSE to allow extension.
[Document how to mark up book/chapter/verse when there is no
section/paragraph information. ]
So one can have a <book><chapter><verse></verse></chapter></book>
container hierarchy, if there are no sections or paragraphs. If
there are sections and/or paragraphs, then at least the cross-over
chapters and verses must be milestones.
ACCEPTED AS "OSIS conforming"
Proposal:
Is it permissable to have chapter/verse containers and milestones in the
same <osisText>?
Best Practice: Recommend that one avoids mixing chapters as containers
and chapters as milestones within a single document.
ACCEPTED
Simple <mileStone> can have the canonical attribute.<mileStoneEnd> does
not get the canonical attribute because it is error-prone and for data
normalization.
ACCEPTED
<mileStoneStart> may have canonical attribute, but <mileStoneEnd> may
not have the attribute.
ACCEPTED
[2.1] Add section, front, body, back, titlePage, introduction, index,
preface, afterword, colophon, entry, dedication, acknowledgments,
majorsec, subsec, coverPage, gazetter, commentary, devotional, map,
imprematur to the type attribute on <div>.
ACCEPTED
[2.2] Add all children of <verse> to <catchWord>.
ACCEPTED
We want an example for the documentation for <note> in <catchWord>.
Issue 2.3 "lang/script/ews" deferred until tomorrow.
ACCEPTED
[2.4] Allow <table> and <list> in <p> and <speech>. Subject to Patrick's
objections, elimination any differences of content model and attributes
between <q> and <speech>, i.e., they become synonyms or aliases of each
other.
[2.5] osisID as a list, then it points @ "at" with osisRef with grain
We need to say in the documentation, that applications are expected to
discard or map the grain when they cannot get a hold of the right
translation.
DEFERRED until tomorrow[Todd is writing up a summary for approval.]
[2.6] Should osisRefbe allowed as a <list>?
Are there discontinuous references?
DEFERRED until tomorrow
OSIS Technical Committee Minutes ? Dallas 1