OSIS TECHNICAL COMMITTEE MINUTES

May 23, 2003

TC members present:
Steve DeRose, BTG, chair
Kees Deblois, UBS, vice-chair
Patrick Durusau, SBL
Troy Griffits, Crosswire Bible Society
Kirk Lowery, Westminster Hebrew Institute, secretary pro tem
Mike Perez, ABS
Todd Tillinghast, ContentFrameworks.com

Others present:
John Walker, SIL
Darrel Eppler, SIL
Chris Little, Crosswire Bible Society
Nathan Miles, UBS
Nick Garbidakis, ABS

Corrections to Yesterday’s Minutes

1. Spelling changes to item 6: majorSection, subSection

   There should be only one type of each <index>, e.g., only one <index type=“gazetteer”>

   impremature changed to imprimatur, map changed to maps, gazetter to gazetteer

   An index is to be defined as a list of distinct heading with a list of references back into the text. The list is generated from the <index> element instances. In an index element, the index attribute is used to identify the particular index under which this entry is to be listed. Document well that the <index> element has an index attribute would be the subtype value that goes on the subtype value of a div whose type is “index.”

2. Note the discussion of changing <index> to something like <indexEntry> is counter to TEI practice. The semantics of this is that <index> is verbal (“index this place”) and the index attribute is a noun (which index in the back matter is specified.

   Index will be done via <div type= “index”> and must have an ID. Individual index elements use their index attribute to specify the ID of the index <div> they’re associated with.

<index index=“ind37” level1=“sin”/>

....

<div type=“index” ID=“ind37”>

....

The index attribute on the index element is not of type IDREF.

3. Two possible 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.

Revised wording: BCV: Academics like it. BFBS likes it. UBS/ABS/SIL like BSP. One way is better than two. A single approach is preferred. Can satisfy the BCV camp using osisRefs using BSP. So, instead of “either/or”, we have a workable “both/and.”

APPROVED

Issues and Decisions

10. [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

11. [2.6] Should osisRef be allowed as a <list>?

    Are there discontinuous references?

    DEFERRED for now

12. “Best Practice” approvals

    1. [3.1.1]

    2. [3.1.2]

    3. [3.1.3] BSP (book/section/paragraph) rather than BCV (book/chapter/verse) is preferred.

    4. [3.1.4] Use the <q> container element whenever possible; and unlike chapter the user is free to mix <mileStone>s and <q> elements in the same document. Documentation needs to warn application developers to cover both cases. The level attribute on <q> starts at “1”. Applications are free to assume that unmarked <q> are level 1. It doesn’t matter what type of quote it is, they all “count” for purpose of counting nesting levels.

       <q type=“block”> is a best practice, but not enforced by validation. If one does not specify “block”, it might be rendered as an ordinary quote. If you want to force inline rendering, then one must specify type= “inline”. Just do it the “TEI way”.

    5. [3.2.1] What’s the difference – if any – between “speech” and “quote”? Especially as to how one counts levels in nesting. The fundamental difference between speech and quote is performance context: the criteria is not audience presence, but the style (rhetoric) appropriate to speaking before an audience. Speech does not impact level of quotes with respect to nesting. There are various places (such as Deuteronomy) where speechs cross section and paragraph boundaries and so speeches in such case should be marked up with mileStones.

    6. Add new element <discourseMarker>, same children as <divineName>, appliesTo= “preceeding” or “following”

    7. [3.2.2] Step 1: document the divTitle attribute of the <div> element as being used for the short title to be used in menus, page headers, etc. For <title> elements, define main and sub for the type attribute. In some cases, typesetters need book titles in their own language. To do this, best practice is to have the applicable stylesheet grab the osisID and display it as desired. The title directly within a <div> of a particular type should not be given a type attribute that is redundant with the type of the <div> that it is in.

       <div type= “section”>

       <title type=“section title”>

       </title>

       </div>

       is deprepcated as redundant.

       <div type= “section”>

       <title type=“main”>

       </title>

       </div>

       is the correct way.

       We will add the list of best practice title type attribute value = “psalm”.

    8. [3.1.5] Because we now have the canonical attribute, it is not required that all and only the canonical text be enclosed in <verse> elements.

    APPROVED

13. [2.3] & [2.7]

    http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=CharEncInPT6

    In regard to 2.7: yes, we delete the lang attribute and instruct people to use the xml:lang attribute. For languages not covered by the relevant RFCs we want to adopt the practices of OLAC (Open anguage archives community: http://www.language-archives.org/OLAC/OLAC-Language.xsd).

    Input from peter constable re. script vs. writing system: writing sys a way in which a language is written: language plus set of characters for writing it.For example, Ajerbaijani can be written with Arabic, Cyrillic, Latin --> 1 language with 3 writing systems. Can a unicode char behave differently depending on the writing system? Yes, within small limits. For example, English has two capital forms, unicode considers them the same character, same code point. Probably used in 2 different language communities. If within one community, that's their problem. thai dam, serbian,.... this is not a "script" phenomenon. Script can be perceived in isolation from language – and can be rendered legibly, though maybe not precisely for a given language community.
    
    A writing system is a language plus a script. Is language plus script enough? Problem: is English in phonetic transcription a separate script? Peter Constable doesn't think we need an additional attribute for script. What does IETF 3066 provide? 'language' tags; but when it says 'language', it really means distinguishing written as well as spoken forms. E.g. en-us vs. en-gb – what’s being distinguished is spelling, mainly.... 18 months ago, people asked for IANA registrations to distinguish German spelling pre/post 1996; so new tags. Then 6 months ago, request to distinguish Yiddish written in Hebrew vs. written in a Latin script. Now there’s a debate with IBM, with several more being requested. Likely 3066 will deal with this. As you can now combine language and country code, it will probably have 4-letter script identifiers added.
    
    Resolved: delete ews attribute.

14. [3.2.25] Poetry

    Meaning of the <l> element is for linguistically determined poetic lines. Within the <l> element you are allowed any number of new <lb> elements (“line breaks”). Indented groups of lines are managed in an embedded/nested <lg>s (line group).

    APPROVED