[sword-devel] verse parsing

[Troy A. Griffitts]

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.