[sword-devel] OSIS and xi:include ?

[David Haslam]

This is something for SWORD developers to carefully consider...

I wonder if our use of OSIS could be "tweaked" such that the XML could make use of the xi:include element that I've seen used in one TEI project. Here's an example to whet your appetite:

        <!-- Genesis -->
         <xi:include href="books/Gn.xml"/>
         <!-- Exodus -->
         <xi:include href="books/Ex.xml"/>
         <!-- Leviticus -->
         <xi:include href="books/Lv.xml"/>


That's taken from the French Vulgate Glaire project (main branch).
NB. The GitHub repo is owned by Marjorie Burghart.

The top level XML file includes this line before the teiHeader element.

<TEI xmlns="http://www.tei-c.org/ns/1.0" xmlns:xi="http://www.w3.org/2001/XInclude">

We could then have a top level OSIS XML file for building the KJVA module that "includes" the OSIS XML files for KJV and KJVDC, albeit slightly trimmed for compatibility as "included" XML files.

NB. The suggested concept may require that most of the header would need to be removed from the two big XML files for the KJV and KJVDC, but that could be be accommodated by using the same "include" construction for both KJV and KJVDC - each having the main content wrapped in a div element with type="bookGroup", (or two such elements if we desire a separate bookGroup for the OT and NT).

cf. The French Vulgate Glaire project, the "included" TEI XML files each start with a line that's like this, (this example is for Obadiah)

<div xmlns="http://www.tei-c.org/ns/1.0" type="book" xml:id="VULGFR_Abd">

The equivalent in OSIS should not be too difficult to get right.

This would obviate having to run a script to combine two OSIS XML files into one, which is what Fr Cyrille would do otherwise.

Then, assuming we could have a valid top level OSIS XML file along the lines of my thinking, the question for SWORD developers is whether osis2mod would need to be changed to cope with such a construction?

The advantage of my proposal is that Dom would not need to change his script for module build.

Looking ahead, and assuming this concept can be made to work with our module tools, longer term, we could make large projects easier to manage for changes by having a separate XML file for each book div, should we so desire. 

Aside: We might even ask Adyeths to consider having an option in u2o.py for keeping each book as a separate OSIS file, and generating a top level OSIS XML file that "includes" all the books. Each USFM file would correspond to a single OSIS file with a single div element with type="book".


Best regards,

David

Sent with Proton Mail secure email.