[sword-devel] the future of OSIS support (importer/filters)
chrislit at crosswire.org
Tue Apr 26 03:07:18 MST 2005
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.
More information about the sword-devel