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

[Ben Morgan]

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,
Ben
-------------------------------------------------------------------------------------------
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>