[sword-devel] [sword-support] deuterocanonical support

Ben Morgan benpmorgan at gmail.com
Sun Mar 15 22:10:50 MST 2009

On Mon, Mar 16, 2009 at 3:43 PM, Chris Little <chrislit at crosswire.org>wrote:

> Ben Morgan wrote:
>> On Mon, Mar 16, 2009 at 10:41 AM, Chris Little wrote:
>>    Barry Drake wrote:
>>        Hi Chris .......
>>        Chris Little wrote:
>>            We plan to have this ready for our next release
>>        This is the most fantastic exciting news.  I've been carefully
>>        following all Troy's and your recent svn commits.  Thanks for
>>        all the great work.
>>    It's all coming along very nicely, and I should be able to make an
>>    announcement and post some example content using a non-KJV
>>    versification "Real Soon Now".
>> Can I please plead not to have this in this release?  Please? I want to
>> see a release.  Currently trunk seems relatively stable for usual modules,
>> so I'd like to see a release (once a couple of patches of mine have been
>> committed...)
> I guess I don't see the logic to postponing a new feature that is much
> desired and adds a lot of capability, considering that it is basically done
> and shouldn't require very extensive testing. I say that it shouldn't
> require much testing because the KJV v11n is now using the same kind of v11n
> plugin system as we plan to use for non-KJV v11ns.
> The new v11n architecture is the biggest new feature of 1.5.12, and I think
> finishing its implementation represents a sufficiently significant milestone
> for the release of 1.5.12.

But the whole point of 1.5.12 was to be a quick bug-fix release - surely we
can leave a big feature like that for 1.6.0/2.0? And anyway, it isn't really
properly finished, I don't believe.

>  A major problem with alternate versification is there currently isn't any
>> way to map between different versification schemes - which is very important
>> for parallel views, etc. Also, quite a lot of code assumes things like 2
>> testaments - I'd like to give these a little time to migrate.
> As has been mentioned, there are no plans to address mapping between v11ns
> in the first release. That will come later. It's important, but not as
> important as simply supporting other v11ns at the most basic level, which
> will allow basic display, lookup, search, etc. Besides, we don't support
> mapping between v11n systems at the moment for Bibles from different v11n
> systems that have been wedged into the KJV system.
That's true, I suppose. But I'm afraid that once different v11n systems are
available, lots of material will be created using them which is missing out
on mapping completely - some of which may never then get it. This is why I
would like to have it presented as a complete fix.

> The 2 testament system will remain and there are no plans to change that.
> We're not going to add additional testaments. We'll simply contract or
> extend them, as necessary, for a given v11n. Testaments are primarily an
> issue of storage location since each testament gets a separate set of files.
> The only other significant aspect of testaments is that they host a
> testament introduction. At present, I'm simply assuming that the NT begins
> with Matthew, so all preceding books are in the OT and all following in the
> NT. Thus, if deuterocanonicals appear following the OT books, they will be
> included with the OT, and if they appear as an appendix after the NT, they
> will be included with the NT.
That sounds better for the moment than adding new testaments. But still I do
not like to have this in.

I still think too much code is assuming (now) flawed assumptions -  that
VerseKeys can live by themselves, for example. I know BPBible creates a lot
of versekeys and assumes that it can construct one from another by merely
setting the text. It also keeps other data around about the shape of the
canon. I don't want this broken in a minor point release of the software. It
will be even worse if the number of verses in chapters, and things like that
change. This could be disastrous.

I think that if you allow creation of books in different v11n systems it
will break lots of code. So I think that a release 1.5.12 should be quickly
released which does this. Otherwise I am going to distribute BPBible 0.4.1
with Sword SVN, patched. And I'd rather not do that.

God Bless,
Multitudes, multitudes,
   in the valley of decision!
For the day of the LORD is near
   in the valley of decision.

Giôên 3:14 (ESV)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20090316/9e323d19/attachment.html>

More information about the sword-devel mailing list