I've been working on providing a VerseKey key interface for traversing
modules like the LXXM:
Is this really about v11n in Sword?
Hi Martin! Yes. This has been the way we've planned to implement v11n
in sword for the past year. You can see all the previous emails in the
archive and current summary at the end of http://crosswire.org/~scribe/todo/
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).
This is good information! Thank you. I'm still not sure what you are
suggesting. Are you suggesting merging the 3 chapters in JoshA with
JoshB? And somehow provide variant toggling? I looked at JoshA and
tried to compare it to JoshB, but I couldn't find similaries. Maybe you
can.
We should not mix v11n with General Book handling! v11n is about Bibles only.
I'm not sure your purpose behind this general suggestion. Maybe you can
explain further, but it seems wrong to me for at least 2 reasons.
1) other things besides Bibles need versification translation, e.g.
Josephus, which has 2 dominant v11n schemes.
2) You might consider re-reading all the email where we've discussed
this implementation and also the suggested outline in the todo. The
intent is to use the genbook driver with its index scheme for storage,
which nicely supports any level of BCV and expose the module with the
same VerseKey interface, so clients of the engine use it just the same
as any other Bible (if it is a Bible). Clients won't know the
difference, just like they don't know if a module uses the RawText or
zText driver.
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.
Translating between schemes hasn't been brought up in any emails
recently. This is an entirely different problem. We have had some
discussion as to the interface we'd like to expose. I believe it would
be a little less intrusive than requiring a user to manually do a
translation. If I remember correctly, past discussions involved a key
knowing what v11n scheme it was, and if you set, say the NASB with a
VerseKey{KJV} it would do any translation necessary. If a user manually
wanted to do conversions, this is obviously still an option by using
keys directly: verseKey{NASB} = verseKey{KJV}.
The interface isn't so much the issue. It's the storage of conversion
tables and a super-fast implementation that we need to consider.
OSIS, at the last meeting, did define a preliminary format for saving
conversion information, so we'll need to, at least, import this data format.
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.
I am worried about an extreme shift (supporting other than int) to
support a very small minority of texts. My worries may be unfounded, I
understand. For books like Josephus and the LXX, I think it's best to
slowly add functionality like parsing and nicer display of keys. Then,
if everything works really great, maybe it might be an option to use all
Bibles with the same mechanism.
Thanks for giving me Bibletime's perspective. It is very appreciated.
Blessings,
-Troy.
mg
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
