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-de...@crosswire.org
http://www.crosswire.org/mailman/listinfo/jsword-devel
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
