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 _______________________________________________ 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
