[sword-devel] the future of OSIS support (importer/filters)

[Chris Little]

At the moment, I'm working on a number of new modules. I'm encoding them 
as OSIS documents, but have avoided actually importing them to Sword 
because of the mess that osis2mod currently is. It needs to be fixed and 
I'll probably have to do it myself, but I think we need to 
discuss/debate exactly what our expectations are for what will be copied 
from an OSIS document to a Sword module.

I have one introductory comment: at present, our OSIS support targets a 
hodgepodge of OSIS 1.1, 1.5, 2.0, and proprietary extensions. This is 
what the OSIS filters target when you specify SourceType=OSIS in your 
.conf file. As an initial recommendation, I would suggest that we break 
away from this and create new, strictly-conformant, OSIS 2.0 filters, 
which we would signal with either SourceType=OSIS2.0 or (preferably) 
OSISVersion=2.0. This would, for example, eliminate the need to handle 
deprecated elements/types (like <div type="chapter"> as a Bible chapter 
container). It also permits us to adopt other changes to the way we 
interpret OSIS (which I discuss below). This does NOT mean that we 
necessarily drop proprietary extensions that conform to OSIS (e.g. 
x-types), though proprietary tags would have to be translated to 
appropriate <seg>/<milestone>-type tags.

I've brought this up before, but it seems like it might be a good time 
to discuss it more fully. Going forth, I would like to encode the full 
(or nearly full) content of an OSIS document within a Sword module, when 
it is imported.

Towards that end, I would like osis2mod to copy <verse> tags (both open 
and close, whether container or milestone). I would like this to be used 
as a means for indicating what verse number should be rendered as well 
as where it should be rendered. Verse numbers are not necessarily a 
single digit and do not necessarily flow in numerical order. Encoding 
<verse> elements (along with their n attributes, when present) permits 
us to render lettered verses and range verses easily. It affords us the 
possibility of rendering out-of-order verses (though this will require 
some additional thinking/work). And until multiple versifications are 
actually supported, it allows us to fake them.

Since it will also mark the starting position of a verse, this also 
permits us to know when to render material preceding a verse before the 
verse number itself (including titles, notes, & introductory material).

I also recommend copying <chapter> and <div> tags (open and close, 
container or milestone) to modules. This also permits access to 
non-numeric chapter numbers (e.g. chapters A-F of Esther, once we 
support them through multiple versification).

We also have the option of normalizing OSIS to a form of our choosing. 
Towards that end, we CAN require that all book/chapter/verse tags be 
milestones. I know Joachim has some reservations with copying the </div> 
tag for a book since you can't easily tell whether it is the closing tag 
of a book (and thus not rendered by them) or some other </div>. If we 
require all book/chapter/verse tags to be milestones, we can put a type 
on it (e.g. <div type="book" eID="Gen"/>)--this isn't a normal thing to 
do, but I think it's valid (correct me if I'm wrong).

I also think we should cease support of OSISqToTick. Quotation marks 
should be encoded as <q> elements. There aren't even many modules that 
uses OSISqToTick, and I don't encode new modules with them. We should 
include some style-sheet-type information in the .conf files (with 
syntax to be determined) to indicate how to render <q> tags.

Comments encouraged.

--Chris