[sword-devel] Alternate Versification

[Jonathan Marsden]

DM Smith wrote:

> I think there are a few different audiences and perhaps different needs:

> 1) The module developer -- I think such a person needs help identifying
> which of the plethora of av11n to use. I'll be changing osis2mod to
> output the different versifications. If the developer runs the module
> through osis2mod, it will identify if the module contains references
> that are not in the requested canon. With the list of supported ones,
> they can try another and another, .... until one works. It might not be
> "correct" but it will work.

I'd say there are three common cases here:

1a) Text uses KJV versification.  Module developer is happy, this is the
default, everything "just works", regardless of how much knowledge/info
the developer has about versifications :)

1b) Text uses non-KJV versification.  Module developer knows this and
selects appropriate versification.  They may need a list of available
versifications to pick from, but will recognize the name of "their"
versification when they see it.

1c) Text uses non-KJV versification.  Module developer does not know
much about versification at all.  I'd be asking whether this is really
an appropriate state of affairs... shouldn't the module developer be
pretty familiar with the text that they are working with?  But anyway,
they aren't.  At minimum, osis2mod can and should complain, and point
the user at a web page where they can learn more about versification :)

> Ultimately, I think we need someone to write an analyzer that will
> recommend an alternate versification if one exists and will output a
> skeletal definition otherwise. As a diagnostic, it should give for each
> versification, what is in the text that is not in the versification and
> what is in the versification that is not in the text. My thought would
> be to write it for OSIS input.

Do we have a collection of suitable OSIS input documents to use during
development and testing of this?  Are they publically downloadable?
Sounds intriguing.

> 2) The front-end developer - I think such a person needs to know what
> scope of the module given it's versification, at least at a book level.
> (I have seen some apps declare that a verse is missing when it is not
> part of the module.) If the versification includes the apocrypha, but
> the module does not, it should not present those books as missing. This
> also applies for NT only and OT only modules.

This sounds more like a need for modules to specify in their .conf file
the subset of books in their versification that they include.  How else
would the application "figure out" the intent of the module developer in
this regard, with full accuracy?

How would the front ends cope with, for example, a module that contained
only the Pentateuch?  How could the software "know" whether this was a
deliberate decision, or a mistake that omitted the rest of the OT (or
indeed the rest of the Bible)?

> 3) The end user - I don't think it should be at all obvious to an end
> user that we are using one versification or another. I don't think they
> should care and I think the app should help them not care. If a user is
> a theologian, they might have an academic interest. In this case, they
> probably know what Luther's or Leningrad Codex or the LXX versification
> is by name, though not detail.

As soon as the naive end user jots down a reference to Mal 3:24 and then
goes to read it in their paper copy of (say) the NIV, they will care :)
 I suspect that hiding the use of non-KJV versification from the user is
a mistake whenever it results in ambiguous references.  But only time
will tell.

> With this, I think that 1) is what we have been talking about. If so,
> sword-devel and the wiki will have to stand in as a proxy for adequate
> tooling. I think it will be sufficient for now.

Well, osis2mod is only really useful for (1).  But if consideration of
(2) leads to a need for .conf file disambiguation of the intent of the
module creator regarding specifying what a module includes, then that
clearly affects (1) also.

>> The window of opportunity for SWORD 1.6.0 API changes is probably
>> already closed.  So realistically, I'd think this should wait for 1.6.1.
>> For 1.6.0, adding a few fprintf()s to osis2mod is (IMO again) probably
>> sufficient?

> It will be added shortly. Troy has just committed the routine I need to
> finish a first cut at it.

I'm surprised, given we're in RC territory, but that's Troy's choice :)

Jonathan