[sword-devel] apocrypha

Stephen Denne sword-devel@crosswire.org
Sun, 8 Jul 2001 13:47:59 +1200

> > There should be a way to query which books are available. At 
> the Moment BT
> > uses a workaround (checks for nt and ot files and displays / hides the
> > corresponding books). As we are in the 1.5.x tree api changes 
> are possible,
> > right?
> I thought about this a bit after writing my first message and 
> here are my thoughts.  There should be a way to define which 
> books are in a Bible along with their order.  And the list of 
> possible books should be able to grow.  So, books 1-66 are 
> Gen-Rev.  Books 67-86(?) are apocrypha.  BUT... for the KJV, for 
> example, we would define the order as 1-39 then 67-81 then 40-66 
> (and 82-86 are books not included in the KJV at all, so they're 
> omitted from the list).  We could do this as a simple integer 
> list in the .conf file.  Or as a more complex one if we want to 
> do parsing, such as "1-39,67-81,40-66".  It allows for all the 
> different ordering standards that we might locate, such as the 
> standard Hebrew ordering of the Tanakh.

How about including more of canon.h & locales into the module, maybe into module.conf, or in a new file with a format conducive to loading it in and using it... so that each module gets to specify it's book ordering, chapters per book, verses per chapter, original book name, sword project unique book number) This could be designed to work with any kind of book.

> The KJV is going to present an interesting issue. :)  On the one 
> hand, I feel we should only distribute the KJV with the Apocrypha 
> included since that is how it was presented by its authors.  On 
> the other hand, I don't really feel like answering the complaints 
> we will get for doing this.  (At least with the KJV there is no 
> Daniel chapter 13, only a Susanna chapter 1, and likewise the 
> other additions to Daniel & Esther are segregated from their 
> canonical cousins.)

Two modules with names like "KJV with Apocrypha" and "KJV without Apocrypha"?

Stephen Denne.