[sword-devel] verse parsing
mg.pub at gmx.net
Sun Mar 26 03:48:16 MST 2006
> 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
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
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.
More information about the sword-devel