Troy,
My 2 cents.
I see this as a mapping of an external name (i.e. what the user know the
verse as) and an internal name (what the engine knows the verse as).
As you pointed out there are a whole host of issues with taking user
input and deciphering it into the internal name. Especially when you
allow pretty sophisticated ranges and have taught the user that we can
guess what they mean with great accuracy.
I think that there are two basic functions that the engine needs to provide:
translation from the user input into a verse key
translation from a verse key to a external representation that is
appropriate for the work.
Today with the KJV, we number each book from Gen to Rev, in the order
that it appears in the KJV.
Then we know how many chapters are in each book and how many verses are
in each book.
We also know the ordinal value for each verse or can compute it readily.
But today, we assume that the internal and external names for chapters
and verse are the same. In your example, they are not the same for
verses. Everything is fine until verse 31, but after that we have 31a,
32, 33, 33a, 33b, and 33c. Positionally these are 32, 33, 34, 35, 36,
and 37.
What is needed is a mapping function External <=> Internal, 31a <=> 32, ....
I think you have pointed out that all the UIs will need to change no
matter what. If that is the case, then perhaps you can increase the
number of methods in VerseKey.
Essentially you would add
String getVerseName()
String getChapterName()
so
int x = vk.Verse()
would give 37 for 33c. That is the offset from the beginning of the chapter.
char* s = vk.getVerseName()
would give 33c.
As to parsing ranges, I think you may need another algorithm. The
current one assumes a lot about KJV versification and its traditions,
such as using roman numerals as in II Sam 2:1 and using numbers for
chapters and verses.
Having fixed bugs in JSword's parsing of user input, I know how
difficult it is.
As the following is allowed
B[[.C].V][-([[B.]C.]V] | B.[C[.V]]])
where B, C and V stand for book, chapter and verse respectively. And -
represents the set of all allowable range indicators and . represents
the set of allowable part separators (and the separators between B & C
may be different than between C & V).
(I think this is at least close)
And as a shortcut "ff" is allowed, which means to the end of the parent
unit.
This becomes difficult with multipart book names and book names that
begin with numbers and where those numbers can be roman numerals or
digits. As these cause the code to have to do a look ahead or look
behind to determine whether it is the prefix or suffix of a book name.
If the code is going to be generally useful for a BCV kind of scheme,
where C and V may not be integers, then it will require a new algorithm.
So, when it is not KJV, it uses the newer one.
I would suggest that we add a V11N= key to the conf with the default of
KJV. This could be used to get the appropriate algorithm.
Hope this helps,
DM
P.S. My solution from the other day skirted this issue.
Troy A. Griffitts wrote:
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
_______________________________________________
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
