[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