[sword-devel] [jsword-devel] Av11n and coverage

DM Smith dmsmith at crosswire.org
Thu Jan 5 08:26:28 MST 2012


Peter,
I think that having a coverage statement is a wonderful idea. For 
JSword, it is a perfect time to have such a definition.

A couple of comments on the implementation.

If we add such a statement to the conf and use an osisRef, I'd like to 
see that it is actually an osisRef. Specifically, an osisRef does not 
use commas to separate ranges, it uses spaces. So it would be:
     Coverage=Gen-Mal Matt-Rev
not
     Coverage=Gen-Mal,Matt-Rev

With it we could get use the KJVA v11n in place of the KJV v11n and it 
would look no different to the end user.

Also, we could mark the NT only and the OT only modules in the download 
managers. This has been a long-standing request and the lack of it has 
been a point of confusion to end users.

I'd also like SWORD to support a valid osisRef. As it is, SWORD requires 
that spaces in an osisRef be replaced with spaces in order for it to 
parse. The same is true for osisID when it refers to more than one 
verse: SWORD requires commas as a separator, but the OSIS spec only 
allows for spaces.

I'd imagine that the SWORD and JSword API would add something like 
module->hasBook(book) returning true or false, and that any iterator 
over the books in a module would skip those not present.

 From an implementation perspective, the SWORD and JSword engines might 
be able to include this today. Deep down in the implementation of the 
storage of a module, there is an index file with a bunch of integers in 
it. When a verse is written to a module, it is appended to the data 
file. The size of that data file before the write is stored as the 
offset in the index file for that verse. The entry of all the verses in 
such a book will have an invalid index of 0. It is a bit more 
complicated for a compressed module, but the idea is the same.

Using this is far slower than a coverage statement in the conf as it has 
to read each index file in it's entirety. But it is less prone to errors.

There are some heuristics that can be used
* Does the book have chapter 1, verse 1.
* Does the book occupy space in the index.
But they rely on unreliable assumptions:
* Chapter 1, Verse 1 is present in all books that exist.
* The module is created all at once. That is, the append mode of 
osis2mod is not used. The append mode puts the verses at the end of the 
module, and updates the index to point to it.
* All the verses are in proper v11n order (osis2mod does not require 
that verse 2 follow verse 1 and will write them in the order that they 
occur, but the index will not be monotonically increasing from one verse 
to the next in the v11n)

In Him,
     DM

On 01/05/2012 07:47 AM, Peter von Kaehne wrote:
> Some of our modules need a certain versification, but do not use all the
> books available in the versification. Sometimes this is the result of
> the translation being incomplete, but sometimes this is the result of a
> theological stance:
>
> Many translations in the former USSR area will use the synodal
> versification, but will at the same time not integrate DC material.
>
> Currently on libsword frontends which support av11n a text with Synodal
> v11n, but no DC material will have empty DC books and the names will
> appear in the menus. This can be a serious detractor in areas where
> people might consider the Bible being corrupted and the same people
> unwilling to listen to lengthy explanations why DC is not meant to be
> part of the Bible.
>
> Alternatively, many translations, while incomplete are meant to be
> incomplete - e.g. are in a small language where people will want to have
> parts of the Bible in their own mother tongue, but will happily use the
> dominant language for more complete Bible study. A number of our Iran
> region translations are of this kind. To have all books appear in the
> menus when in reality there are and will ever only be e.g. Genesis,
> Psalms, Luke, Acts and Romans is detracting.
>
> The best solution for all this would be a coverage entry in the conf file.
>
> Chris suggested that this should be an OSISRef. I concur. It is the most
> flexible way of implementing this and allows finegrained control (if one
> wishes to have this)
>
> Can I propose therefore that we will add to "incomplete" modules (in
> terms of the underlying versification) an entry
>
> Coverage=Gen,Psalm,Luke,Acts,Rom (sorry if the OSIS abbreviations are
> off, but OSIS was meant)
>
> For some nonDC translations this might then be simply
>
> Coverage=Gen-Mal,Mat-Rev
>
> Others nonDC translations (with v111n where DC material is interspersed)
> might require more finegrained references, including chapter and verse
> references.
>
> Frontends then could implement this as part of their work to make av11n
> work.
>
> Underlying is of course the versification of a particular module - which
> will dictate which books are there in the first place, in which order
> and which chapters/verses too.
>
> What does everyone think?
>
> Peter
>
> I am posting this to jsword too as I see that DM has started
> implementing av11n!! Great - thanks DM.
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel




More information about the sword-devel mailing list