[sword-devel] verse parsing

[Martin Gruner]

Hi Troy.

> 	I've been working on providing a VerseKey key interface for traversing
> modules like the LXXM:

Is this really about v11n in Sword?

> First, I attempted to redo this module using OSIS book names for
> everything, and discovered that there just wasn't a nice book list we
> could display to the user.  For example, JoshB (from the link above)
> seems to be the standard book of Joshua we'd all expect, but then JoshA
> (browse to it using the left index) contains 3 chapters: 15, 18, 19  Not
> sure exactly what these are, but I'm guessing they are replacements or
> additions to Joshua or some other book.  Actually, I just have no idea.

If you look at the printed LXX, you will note that in some parts it is divided 
into two sections. Each represents a different textual tradition (A=Codex 
Alexandrinus, B=Codex Vaticanus). JoshB basically has the standard text where 
there is no separation, and the Codex Vaticanus text from the divided 
passages, and JoshA only has the Codex A. text of these passages.

So the solution in this case is not to allow for non-OSIS booknames like JoshA 
and JoshB, but to encode the module correctly. That's what I am planning for 
the upcoming (if we get permission) MT-LXX-parallel module. If you get Josh 
15, every verse will contain a table, the first column being codex A and the 
second one being codex B. So for the booknames, no modification is required 
as the current module structure is already a workaround (from the CATSS 
files).
We should not mix v11n with General Book handling! v11n is about Bibles only.

The sub-verse issue: My suggestion would be to implement an internal, absolute 
reference scheme which is not exposed to the outside. This would translate a 
reference from a given v11n system to an integer number, giving the 
possibility to map different v11n schemes together. B, C and V would all be 
strings, and frontends could use VerseKey.nextChapter() or the like to 
iterate through them and could use the translator object to map them between 
modules.
I can explain more if you like, and I'd be curious to see if I can help with 
this as well.

>From a BibleTime developers perspective, I'd say: We don't care if you break 
the current VerseKey/Treekey structure. Let's make a real cool and clean 
implementation, even if we have to choose a completely different 
layout/design. We'll adapt to that as soon as it is released. Good v11n 
handling is FAR more important than backwards compatibility here.

mg