[sword-devel] osis2mod and container elements

DM Smith dmsmith555 at yahoo.com
Tue Jul 1 11:07:09 MST 2008

I'd like to propose a change to osis2mod and get consensus before making the change.

The goal of osis2mod is to allow any valid OSIS as input and to transform it, if necessary to a form that SWORD apps can handle, and do it in a loss-less manner. However, that is not reality. An encoder needs to create OSIS that the SWORD engine, front-ends and osis2mod expects.

(Yes, those are the same two paragraphs from the WoC email, but they apply here too.)

There has been an on-going debate as to whether one should have verses be containers. To me it seems that sides are taken depending on ones role. Software developers, using the SWORD engine, nearly always fall in the "verse as container" camp or Book, Chapter, Verse (BCV) camp. E.g. I am a BCV proponent.

While document creators nearly always fall in the Book, Section, Paragraph (BSP) camp. E.g. Chris is a BSP proponent and the new Wycliffe beta modules are also BSP structured.

In testing the new Wycliffe beta modules, I have found that osis2mod falls into the BCV input camp and does not handle BSP well. It appears that the modules are *really good* OSIS and that osis2mod should be changed to accommodate them.

I'd like to propose the following change:
Elements that can cross verse boundaries are converted to their milestoned version.

The key container elements for BSP are <div>, <chapter>, <p>, <lg>, <l> and <q>. 

Other container elements that can contain a verse (and thus cross a verse boundary) are are <closer>, <salute>, <speech>.

Of these all but <p> are milestoneable, but osis2mod already handle <p> well.

This change would allow a greater range of OSIS documents to work in all front-ends and I think it would be compatible with SWORD 1.5.9.

In Him,

More information about the sword-devel mailing list