Hey guys (especially frontend writers),
I've been working on providing a VerseKey key interface for traversing
modules like the LXXM:
http://crosswire.org/study/bookdisplay.jsp?mod=LXXM&gbsEntry=%2FJoshB%2F24%2F1
I'm having some difficulty fitting this into the exposed VerseKey
interface.
Obviously, my goal was to save everyone as much modification as
possible, but there just doesn't seem like there is a good fit for
modules like these.
Here's a little background of what I was trying and were I ran into
troubles, and why I've come to this conclusion:
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.
The next thing I began to realize is that this module uses a,b,c type
suffixes on verses (click on the first link in this email again and
scroll to the bottom of the page). This does not fit nicely into our
integer concept for verses. I considered adding a 5th level:
Testament/Book/Chapter/Verse/Sub. But this really breaks the whole
paradigm anyway, as sub will mostly be blank except when there might be
a letter tacked to the end. It really doesn't solve any problems, e.g.
key.Verse(key.Verse()+1) still will break. key++ would work, I guess,
but you'd have to always check if Sub was set to anything. And who
knows what Sub really means. Is it a replacement? Is it really a
subdivision of the verse? It just doesn't seem like it solves any
problems nicely. It seems like the LXX really is sequentially 31, 31a,
32, 33, 33a, 33b. When I know that other Bibles and commentaries mean
the first part of 33 when they say 33a. So adding Sub doesn't seem like
it gives us much except keeping Verse an integer.
So, I have a few ideas, and would like to hear from you.
Basically, I think the way we present and display the LXXM with swordweb
(the link above) is actually pretty ok. There are a few deficiencies:
The 'reference' is display like:
/JoshB/24/1
We could add a flag which says to display using a BK CH:VS format. I
was thinking about adding a pattern, like letting the modules.conf file
specify something like:
KeyDisplay=%1 %2:%3
but I think this is more work for everyone than it benefits. Besides,
other languages probably prefer other formats (BK CH.VS). So I think
we'd like to just say something like KeyFormat=BCV
The other problem is parsing...
Currently VerseKey provides all the nice parsing functionality that
figures out:
Ijn2-3:12
It can do this because it has a set of books that it know about, along
with all kinds of abbreviations and translated into a number of
languages. Our current parser also drops suffixed letters.
Finally, if we solve these problems, and place an entry in LXXM:
Category=Biblical Texts, it will probably break most frontends which
expect all Biblical Texts to use a VerseKey. I don't know how to solve
this problem.
I also considered a major change to VerseKey which would make all levels
strings and not integers. I realize many frontends use integer spin
controls to increase/decrease chapter and verse. There may also be
linear logic regarding these things.
I guess the real question is, would it be easier for everyone to add
parsing and display support to treekey and leave versekey alone? This
is the direction I'm leaning right now. Any thoughts to sway me would
be appreciated.
-Troy.
_______________________________________________
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
