[jsword-devel] [sword-devel] Method to find if BibleBook is contained in a Book
John Austin
gpl.programs.info at gmail.com
Wed Apr 16 06:31:12 MST 2014
All IBT modules do contain the Scope param. Reading the Scope param
requires knowledge of the versification, but it can accurately return
which books/chapters/verses are present in a module.
Here's a snippet of PHP code from IBT's server which reads the scope
param and builds an array of books present in a module:
$scope = preg_split("/ /", $scope);
for ($i=0; $i<count($scope); $i++) {
$bks = preg_split("/\-/", $scope[$i]);
$lst = -1;
for ($x=0; $x<count($bks); $x++) {
$bks[$x] = preg_replace("/\..*$/", "", $bks[$x]);
$idx = indexOfBook($vsys, $bks[$x]);
if ($idx == -1) continue;
if ($lst == -1) {$lst = $idx;}
else {
for ($y=$lst+1; $y<$idx; $y++) {
$books['b'.$y] = $Booki[$vsys][$y];
}
}
if (!in_array($bks[$x], $books)) {
$mi = indexOfBook($vsys, $bks[$x]);
if ($mi != -1) $books['b'.$mi] = $bks[$x];
}
}
}
Even after IBT's modules are re-worked according to current best
practice, they will likely retain the Scope param. The Scope param is
the only way of determining what is present within a module without
having to install the module first. This is useful for servers,
repository managers and probably other things that want to know what's
in a module only from its conf file.
-John
On 04/16/2014 05:46 PM, Martin Denham wrote:
> In my opinion the IBT patch I implemented is good enough for a front end
> but not for a shared library. A better solution would be to implement
> Scope because, I think, IBT have also added Scope to (all?) their conf
> files. Then we could avoid the current verse length checks and the
> logic could be like:
>
> if (scope exists in conf) {
> get list of books from scope
> } else {
> calculate list of books by verse checks
> }
>
> *Example scopes from IBT modules*
>
> Scope for kaz:
> Scope=Gen-Josh.24.33 Judg-2Chr Ezra-Neh Esth-Ps.150 Prov.0-Prov.4.27
> Prov.5-Prov.13.25 Prov.14-Prov.18.24 Prov.19-Song Isa-Lam Ezek-Dan.3.33
> Dan.4-Dan.12 Hos-Mal Matt-Rev
>
> Scope for kylsc:
> Scope=Matt-Rev
>
> A simple initial implementation might just look at the first and last
> characters e.g. Gen.*Rev, Matt.*Rev. Although that implementation would
> be flawed it may well be good enough for IBT books and may not be used
> or required elsewhere. I have not checked all IBT books for Scope.
>
> Martin
>
>
> On 15 April 2014 19:19, Chris Burrell <christopher at burrell.me.uk
> <mailto:christopher at burrell.me.uk>> wrote:
>
> Thanks Martin - now I see what you mean about IBT!
>
> DM, Martin's code simply checks existence of verse 1 & 2 (my option
> 2 above), using the code I wrote to work out if a verse is present.
> The IBT stuff seems like a dirty hack for a poor module structure.
>
> I'd be happy to integrate that into JSword. I'm presuming the option
> suggested doesn't really add much to this?
>
> I think integrating it, we would possibly want to make it part of a
> AbstractPassageBook, and have it lazy init. Do we need want to
> retain a list? Or would a HashSet be better? or even a LinkedHashSet?
>
> Most of my use cases rely on asking whether a book is contained
> within the Book, as opposed to obtaining a list of books.
>
> Chris
>
>
>
> On 15 April 2014 09:43, Martin Denham <mjdenham at gmail.com
> <mailto:mjdenham at gmail.com>> wrote:
>
> I took a stab at this here
> <https://github.com/mjdenham/and-bible/blob/development/AndBible/src/net/bible/android/control/navigation/DocumentBibleBooks.java>.
> It was elegant until I catered for IBT module anomalies.
>
> My initial experiments seem to show it works really well in
> being fast and giving a quick 'heads-up' regarding which Bible
> books are in a module which is useful not only for partial dc
> support which seems the norm, but also for partial Bibles and
> commentaries e.g. NT only or developing modules.
>
> I have integrated this into the Passage selector and also page
> prev/next.
>
> Cheers
> Martin
>
>
> On 14 April 2014 23:50, DM Smith <dmsmith at crosswire.org
> <mailto:dmsmith at crosswire.org>> wrote:
>
> It still is manual. I think there's a fairly optimal way to
> compute this, but it is not perfect.
>
> The problem is that a module does not have to be laid down
> in order. Osis2mod has an "append" flag that allows for
> additional material to be appended to a module. This is
> useful for doing a book at a time. It it also useful to fix
> a verse and append the fix to the module. Both the old and
> the new will be in the module but only the new will be in
> the index.
>
> Also, if the module has books, chapters or verses out of
> order, these will be reassembled into the right order (it is
> the nature of the index file), but the data files will have
> the content in the order that is in the module.
>
> The following is true about the index and data files:
> Each verse in the data file is laid down in the order that
> it is read from the input file.
> The index contains the start of each verse in the data file.
> There are separate index files for the OT and the NT. DC
> when present is in one or the other.
>
> If the data is laid down in the proper order then we can use
> that knowledge to figure out if the book or chapter has content.
> The difference between the starts of the books (or chapters)
> can be used to guess what is present. For example, if
> Genesis has a start of 10 and an end of 4000, Exodus has a
> start and end of 0, and Lev has a start of 4000 and end of
> 10000, then we can guess that Genesis and Lev exist but
> Exodus does not.
>
> Alternatively other sample points could be used. E.g. middle
> of the chapters.
>
> This is only a heuristic.
>
> We can also note that the OT files don't exist or the data
> file has 0 size, then the module is NT alone. Or the other
> way around.
>
> I do think we need to make the module's conf be "immutable"
> as downloaded, but have a "sidecar" conf file with settings
> we want to have. I think once computed, it should be stored
> there. Maybe it can be computed on the server and stored
> there for download.
>
> -- dm
>
>
> On Apr 14, 2014, at 4:42 PM, Chris Burrell
> <christopher at burrell.me.uk
> <mailto:christopher at burrell.me.uk>> wrote:
>
>> Hi
>>
>> What's the latest on this? At the moment, STEP looks up
>> auto-suggestions based on versifications but this is
>> annoying for Greek texts that do offer the OT, but the
>> OSMHB (OSHB) or WLC don't.
>>
>> What I'm really looking for is to query a book for it's
>> BibleBooks, rather than have to rely on the Versification.
>> The versification is not great from that point of view. It
>> tells the frontend what might be in the book, rather than
>> what is in the book.
>>
>> If there's nothing there at the moment, I could settle for:
>> 1. calculate once and store scope (as an OSIS, or read it
>> from conf file). Then read the key and do some kind of
>> parsing to get all books.
>> 2. check for all Bk.1.1 on start-up/first call and check
>> for that
>> 3. Do a combination of both, i.e. calculate once and store
>> on install (or store if not stored before), then use that
>> to check for all Bk.1.1 first time round.
>> 4. Store a number of flags such as Gen.1.1=true,
>> Ex.1.1=true, etc.
>>
>>
>> Bar 4, none of these options are efficient however. All of
>> them require at least 66 lookups for a standard module.
>> And on small devices, this may be an issue.
>>
>> Chris
>>
>>
>>
>> On 28 March 2014 20:50, DM Smith <dmsmith at crosswire.org
>> <mailto:dmsmith at crosswire.org>> wrote:
>>
>> It will be performant with Bibles.
>>
>> JSword is stable at the tip. I've just checked in the
>> bug fix that Chris supplied.
>>
>> This change will be stable.
>>
>> -- DM Smith
>>
>> On Mar 28, 2014, at 4:34 PM, Martin Denham
>> <mjdenham at gmail.com <mailto:mjdenham at gmail.com>> wrote:
>>
>>> I was only thinking of using it with
>>> SwordBook/AbstractPassageBook but if it is not
>>> performant then maybe it is not worth continuing and
>>> we should look at Scope. I thought that it was
>>> already being calculated in ZVerseBackend.contains()
>>> using the idxRaf.
>>>
>>> btw is it safe to get the tip of JSword yet?
>>>
>>> Martin
>>>
>>>
>>> On 28 March 2014 20:19, DM Smith
>>> <dmsmith at crosswire.org
>>> <mailto:dmsmith at crosswire.org>> wrote:
>>>
>>> I think it would be good to support Scope
>>> formally, even if it never makes it into SWORD.
>>> As a different issue, we'll be changing JSword to
>>> keep a module's conf pristine and the things that
>>> we write to it, will be put into a side-car conf.
>>> This will be the perfect place for us to compute
>>> the value once for all time per module.
>>>
>>> The getRawTextLength is not as easy as I'd like.
>>> It's mostly done. A bit more to do. For a couple
>>> of module types, both compressed, it is not
>>> performant. It merely calls getRawText and then
>>> length. The problem is that one has to uncompress
>>> the text to see how long it is.
>>>
>>> -- DM
>>>
>>> On Mar 28, 2014, at 3:31 PM, Martin Denham
>>> <mjdenham at gmail.com <mailto:mjdenham at gmail.com>>
>>> wrote:
>>>
>>>> An alternative method might be to use the Scope
>>>> value which IBT have placed in the .conf file,
>>>> but I can't seem to get access to it via JSword.
>>>>
>>>> This is printed:
>>>> WARNING: Extra entry in kaz of Scope
>>>>
>>>> And in ConfigEntryTable:
>>>> log.warn("Extra entry in {} of {}",
>>>> internal, configEntry.getName());
>>>> extra.put(key, configEntry);
>>>>
>>>> But I can't see any way to get the value from
>>>> the extra map? Is it possible - I am a bit
>>>> confused by the initialisation and retrieval of
>>>> metadata and properties in JSword.
>>>>
>>>> *Example scopes from IBT modules*
>>>>
>>>> Scope for kaz:
>>>> Scope=Gen-Josh.24.33 Judg-2Chr Ezra-Neh
>>>> Esth-Ps.150 Prov.0-Prov.4.27 Prov.5-Prov.13.25
>>>> Prov.14-Prov.18.24 Prov.19-Song Isa-Lam
>>>> Ezek-Dan.3.33 Dan.4-Dan.12 Hos-Mal Matt-Rev
>>>>
>>>> Scope for kylsc:
>>>> Scope=Matt-Rev
>>>>
>>>> I don't know if the strings used are compatible
>>>> with PassageKeyFactory but if we only look at
>>>> the start and end of the scope we may be able to
>>>> deduce all that is required because I think IBT
>>>> are the only people who use scope.
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> On 28 March 2014 14:12, DM Smith
>>>> <dmsmith at crosswire.org
>>>> <mailto:dmsmith at crosswire.org>> wrote:
>>>>
>>>> I'll add the method
>>>> SwordBook.getRawTextLength(Key key), or
>>>> something like it.-- DM
>>>>
>>>> On Mar 26, 2014, at 6:47 PM, Martin Denham
>>>> <mjdenham at gmail.com
>>>> <mailto:mjdenham at gmail.com>> wrote:
>>>>
>>>>> Given the above explanations and that many
>>>>> users have already downloaded such modules
>>>>> I have experimented with a work-around by
>>>>> adding some extra logic to And Bible to
>>>>> specifically cater for the IBT Synodal
>>>>> modules. I did this by making the
>>>>> assumption that all the empty verses start
>>>>> with: "<chapter eID=" which appears true
>>>>> and unique. It is a bit of a hack but it
>>>>> almost worked.
>>>>>
>>>>> The only problem is that after adding the
>>>>> extra getRawText checks it takes too long,
>>>>> even on my Nexus 4, to load the book list
>>>>> for IBT modules. However, a simpler way to
>>>>> avoid the getRawText calls would be to add a
>>>>> public int
>>>>> SwordBook.getRawText*Length*(Key key)
>>>>> which would be identical code to
>>>>> contains(Key key)
>>>>> (->ZVerseBackend.contains) but return verse
>>>>> length instead of a boolean (contains()
>>>>> calculates verse length to determine if a
>>>>> verse exists). What do you think? This
>>>>> would help because IBT empty verse stubs
>>>>> are very short and so normally the
>>>>> getRawText would not be required as part of
>>>>> the elaborated contains() check in And Bible.
>>>>>
>>>>> *Note:*
>>>>> I have discovered that this problem does
>>>>> not just affect deuterocanonical books in
>>>>> IBT Synodal modules, it also affects OT
>>>>> books in IBT NT-only modules e.g. KYLSC,
>>>>> which return text like "<chapter eID="gen4"
>>>>> osisID="Gen.1"/>".
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>> On 26 March 2014 14:49, DM Smith
>>>>> <dmsmith at crosswire.org
>>>>> <mailto:dmsmith at crosswire.org>> wrote:
>>>>>
>>>>> John,
>>>>>
>>>>> Putting this up on sword-devel, since
>>>>> that is a more appropriate location for
>>>>> the discussion to continue. This is
>>>>> really not about JSword, but rather
>>>>> about module making.
>>>>>
>>>>> The nature of osis2mod is to retain all
>>>>> markup except <verse> and </verse> (or
>>>>> their equivalent milestoned version.)
>>>>> This means that the markup for a
>>>>> chapter is put in the module's storage
>>>>> for that chapter and noted in the
>>>>> index. In the case of the chapter that
>>>>> is given below, it is split into 2
>>>>> parts, Verse 0 and Verse 1.
>>>>> Verse 0 will get the preamble of the
>>>>> chapter:
>>>>> <chapter osisID="EpJer.1">
>>>>> Verse 1 will get:
>>>>> </chapter>
>>>>> (These will have been transformed into
>>>>> their milestoned versions.)
>>>>>
>>>>> Also, verse 2 to 72 will be "linked" to
>>>>> verse 1, meaning that in the index they
>>>>> are given the same location as verse 1.
>>>>>
>>>>> So, verse 0 has chapter start content
>>>>> and verse 1 to 72 have chapter end content.
>>>>>
>>>>> Also, osis2mod does not complain if a
>>>>> verse is missing. Never has, never
>>>>> will. It does "complain" of a verse
>>>>> being present that is not in the
>>>>> versification. Always has, always will.
>>>>>
>>>>> That emptyvss indicates that all verses
>>>>> are present means exactly that: All
>>>>> verses are present. This is not good if
>>>>> the module is in fact incomplete.
>>>>>
>>>>> That JSword indicates that these
>>>>> "empty" verses are present means that
>>>>> they have non-zero length in the module.
>>>>>
>>>>> JSword is graceful in handling this. It
>>>>> determines that the module has content
>>>>> for the verse by examining the index.
>>>>> What Martin is trying to do is find out
>>>>> which books, chapters and verses should
>>>>> be displayed to users in pick lists.
>>>>> The only way this can be done at this
>>>>> time, by either SWORD or JSword with
>>>>> the module in question, is to render
>>>>> each verse and determine that it
>>>>> renders nothing. This is far too
>>>>> expensive an operation to consider.
>>>>>
>>>>> The only way to efficiently determine
>>>>> scope is to examine the index for each
>>>>> verse and see if the length is 0. The
>>>>> Scope entry in the conf has been ruled
>>>>> out. It would have been computed using
>>>>> the reverse logic of emptyvss. Go
>>>>> through the v11n from first verse to
>>>>> last and rather than noting what is
>>>>> missing, note what is present.
>>>>>
>>>>> Today, most of our frontends display
>>>>> pick lists based on the v11n not on the
>>>>> module content. It has long been
>>>>> confusing to end users of modules that
>>>>> don't contain verses in the v11n.
>>>>>
>>>>> In my view, this is a module problem.
>>>>> It is far easier and faster to rebuild
>>>>> and redistribute a module. We can tell
>>>>> a user to upgrade to the most recent
>>>>> version of a module far easier than
>>>>> making and releasing a code change and
>>>>> having them get a new version of the
>>>>> program. When the change is a
>>>>> work-around for something that
>>>>> shouldn't be in module, I think we
>>>>> should avoid that. For example, the NET
>>>>> Bible has some bugs that should be
>>>>> fixed. But instead we have some special
>>>>> code that is essentially: if module is
>>>>> NET then fix such-and-so when it occurs.
>>>>>
>>>>> Together in His Service,
>>>>> DM Smith
>>>>>
>>>>>
>>>>>
>>>>> On Mar 25, 2014, at 11:43 PM, John
>>>>> Austin <gpl.programs.info at gmail.com
>>>>> <mailto:gpl.programs.info at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> There has been a lot of discussion
>>>>>> about how missing material in a v11n
>>>>>> should be treated (the discussion of
>>>>>> the meaning and use of Scope was part
>>>>>> of that). Tools such as osis2mod
>>>>>> generated warnings whenever OSIS files
>>>>>> lacked any part of the chosen v11n.
>>>>>> The Scope conf param was, for a time
>>>>>> at least, the recommended method of
>>>>>> describing what part of a v11n was
>>>>>> covered by a module. For these
>>>>>> reasons, many existing modules (IBT
>>>>>> alone has at least 26 such modules)
>>>>>> are currently encoded so as to
>>>>>> encompass the entire v11n, returning
>>>>>> empty-string verse content for all
>>>>>> verses in the v11n that are not
>>>>>> included in the module, and using the
>>>>>> .conf Scope param to define exactly
>>>>>> what is present in the module.
>>>>>>
>>>>>> So even though current module making
>>>>>> best practice may be different, it
>>>>>> would be good for JSword to be
>>>>>> graceful with modules that are encoded
>>>>>> somewhat differently if at all
>>>>>> possible, at least for a time. There
>>>>>> are many modules out there, old and
>>>>>> new, which don't contain the complete
>>>>>> v11n, so determining book coverage is
>>>>>> important.
>>>>>>
>>>>>> -John
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 03/25/2014 08:19 PM, DM Smith wrote:
>>>>>>> Those verses exist since they are
>>>>>>> defined in the OSIS input file to
>>>>>>> osis2mod. Osis2mod retains everything
>>>>>>> in its input. This is a well
>>>>>>> documented behavior of osis2mod.
>>>>>>>
>>>>>>> The end chapter markup will be put in
>>>>>>> the last verse that is in the
>>>>>>> chapter, which might be verse 0.
>>>>>>>
>>>>>>> They should use xslt to strip empty
>>>>>>> verses, chapters and books out of
>>>>>>> their file into an intermediate file
>>>>>>> and give that as input to osis2mod.
>>>>>>>
>>>>>>> Alternatively they can use <!-- ...
>>>>>>> --> to comment out huge swaths of
>>>>>>> the input file.
>>>>>>>
>>>>>>>
>>>>>>> -- DM
>>>>>>>
>>>>>>> On Mar 25, 2014, at 7:48 AM, Martin
>>>>>>> Denham <mjdenham at gmail.com
>>>>>>> <mailto:mjdenham at gmail.com>
>>>>>>> <mailto:mjdenham at gmail.com>> wrote:
>>>>>>>
>>>>>>>> IBT have just passed me more
>>>>>>>> information regarding their handling of
>>>>>>>> empty verses to help clarify if this
>>>>>>>> is an IBT module issue or not.
>>>>>>>> The following is an extract from
>>>>>>>> IBT's e-mail:
>>>>>>>>
>>>>>>>> Here are examples of how IBT's
>>>>>>>> OSIS source defines empty verses in
>>>>>>>> the markup:
>>>>>>>>
>>>>>>>> Empty book (Epistle of Jeremiah):
>>>>>>>> <div
>>>>>>>> type="x-Synodal-non-canonical"__><div type="book"
>>>>>>>> osisID="EpJer"><chapter
>>>>>>>> osisID="EpJer.1"><verse
>>>>>>>> sID="EpJer.1.1-72"
>>>>>>>> osisID="EpJer.1.1 EpJer.1.2
>>>>>>>> EpJer.1.3 EpJer.1.4 EpJer.1.5
>>>>>>>> EpJer.1.6 EpJer.1.7 EpJer.1.8
>>>>>>>> EpJer.1.9 EpJer.1.10 EpJer.1.11
>>>>>>>> EpJer.1.12 EpJer.1.13 EpJer.1.14
>>>>>>>> EpJer.1.15 EpJer.1.16 EpJer.1.17
>>>>>>>> EpJer.1.18 EpJer.1.19 EpJer.1.20
>>>>>>>> EpJer.1.21 EpJer.1.22 EpJer.1.23
>>>>>>>> EpJer.1.24 EpJer.1.25 EpJer.1.26
>>>>>>>> EpJer.1.27 EpJer.1.28 EpJer.1.29
>>>>>>>> EpJer.1.30 EpJer.1.31 EpJer.1.32
>>>>>>>> EpJer.1.33 EpJer.1.34 EpJer.1.35
>>>>>>>> EpJer.1.36 EpJer.1.37 EpJer.1.38
>>>>>>>> EpJer.1.39 EpJer.1.40 EpJer.1.41
>>>>>>>> EpJer.1.42 EpJer.1.43 EpJer.1.44
>>>>>>>> EpJer.1.45 EpJer.1.46 EpJer.1.47
>>>>>>>> EpJer.1.48 EpJer.1.49 EpJer.1.50
>>>>>>>> EpJer.1.51 EpJer.1.52 EpJer.1.53
>>>>>>>> EpJer.1.54 EpJer.1.55 EpJer.1.56
>>>>>>>> EpJer.1.57 EpJer.1.58 EpJer.1.59
>>>>>>>> EpJer.1.60 EpJer.1.61 EpJer.1.62
>>>>>>>> EpJer.1.63 EpJer.1.64 EpJer.1.65
>>>>>>>> EpJer.1.66 EpJer.1.67 EpJer.1.68
>>>>>>>> EpJer.1.69 EpJer.1.70 EpJer.1.71
>>>>>>>> EpJer.1.72"/><verse
>>>>>>>> eID="EpJer.1.1-72"/></chapter>__</div></div>
>>>>>>>>
>>>>>>>> I'm not sure how osis2mod handles
>>>>>>>> all this when importing to the
>>>>>>>> module, but it works perfectly
>>>>>>>> without warnings or errors. Also,
>>>>>>>> when the resulting module is
>>>>>>>> passed to the "emptyvss" tool, it
>>>>>>>> passes this test without warnings.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25 March 2014 11:38, Martin
>>>>>>>> Denham <mjdenham at gmail.com
>>>>>>>> <mailto:mjdenham at gmail.com>
>>>>>>>> <mailto:mjdenham at gmail.com>> wrote:
>>>>>>>>
>>>>>>>> I am having problems getting a
>>>>>>>> list of BibleBooks contained in
>>>>>>>> some AV modules which we know do
>>>>>>>> not contain certain books. I
>>>>>>>> can't work out if the problem is
>>>>>>>> with JSword, the modules, or
>>>>>>>> osis2mod.
>>>>>>>>
>>>>>>>> There are 2 related problems I
>>>>>>>> can see:
>>>>>>>>
>>>>>>>> 1.
>>>>>>>> book.contains(nonExistingVerse)
>>>>>>>> returns TRUE
>>>>>>>> 2.
>>>>>>>> book.getRawText(nonExistingVerse)
>>>>>>>> returns <chapter end tag>
>>>>>>>>
>>>>>>>> Here is a simple test to show the
>>>>>>>> problem using KAZ which has
>>>>>>>> Synodal v11n but does not contain
>>>>>>>> any deuterocanonical books:
>>>>>>>>
>>>>>>>> SwordBook kaz =
>>>>>>>> (SwordBook)Books.installed().getBook("KAZ");
>>>>>>>> Verse esd11Verse = new
>>>>>>>> Verse(kaz.getVersification(),
>>>>>>>> BibleBook.ESD1, 1, 1);
>>>>>>>> System.out.println(kaz.contains(esd11Verse));//
>>>>>>>> prints: *true*
>>>>>>>> System.out.println(kaz.getRawText(esd11Verse));//
>>>>>>>> prints:
>>>>>>>> *<chapter eID="gen7"
>>>>>>>> osisID="1Esd.1"/>*
>>>>>>>> Verse esd12Verse = new
>>>>>>>> Verse(kaz.getVersification(),
>>>>>>>> BibleBook.ESD1, 1, 2);
>>>>>>>> System.out.println(kaz.contains(esd12Verse));//
>>>>>>>> prints: *true*
>>>>>>>> System.out.println(kaz.getRawText(esd12Verse));//
>>>>>>>> prints:
>>>>>>>> *<chapter eID="gen7"
>>>>>>>> osisID="1Esd.1"/>*
>>>>>>>>
>>>>>>>> So how does "<chapter eID="gen7"
>>>>>>>> osisID="1Esd.1"/>" get into verse
>>>>>>>> content unexpectedly?
>>>>>>>>
>>>>>>>> It seems to me like it could be
>>>>>>>> either:
>>>>>>>>
>>>>>>>> 1. a module problem; but IBT say
>>>>>>>> they do not add empty verse slots
>>>>>>>> 2. Sword osis2mod issue
>>>>>>>> 3. JSword issue: why is JSword
>>>>>>>> returning a chapter end tag
>>>>>>>> instead of verse content
>>>>>>>>
>>>>>>>> Any ideas what might cause this
>>>>>>>> problem?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11 March 2014 12:15, DM Smith
>>>>>>>> <dmsmith at crosswire.org
>>>>>>>> <mailto:dmsmith at crosswire.org>
>>>>>>>> <mailto:dmsmith at crosswire.org>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> We haven't pushed this down
>>>>>>>> into JSword. So far it is the
>>>>>>>> responsibility of the
>>>>>>>> front-end. Chris B has made it efficient
>>>>>>>> to ask a Book whether it
>>>>>>>> contains a Verse.
>>>>>>>>
>>>>>>>> Essentially, when it comes to
>>>>>>>> asking a module if it has
>>>>>>>> meaningful content, you want
>>>>>>>> containsAny(Key verses, boolean
>>>>>>>> includeIntros) and
>>>>>>>> containsAny(Key verses) { return
>>>>>>>> containsAny(verses, false); }
>>>>>>>>
>>>>>>>> I think it should ignore
>>>>>>>> verse 0 by default. If it doesn't
>>>>>>>> have verse content, then does
>>>>>>>> the content really mean something?
>>>>>>>>
>>>>>>>> As you have noted
>>>>>>>> contains(Key) is confusing. There
>>>>>>>> are a few
>>>>>>>> places where it means
>>>>>>>> containsAny. Usually it means
>>>>>>>> containAll. The name,
>>>>>>>> contains, was chosen early as we derived
>>>>>>>> from a container class where
>>>>>>>> the argument was an element of
>>>>>>>> the container. That is,
>>>>>>>> contains is supposed to mean
>>>>>>>> isMemberOf. Later we changed
>>>>>>>> the inheritance as it wasn't an
>>>>>>>> "is a" relationship.
>>>>>>>>
>>>>>>>> But we need to be careful of
>>>>>>>> not introducing more confusion.
>>>>>>>>
>>>>>>>> By the way, the list serve
>>>>>>>> was holding mail for a few days.
>>>>>>>>
>>>>>>>> In Him,
>>>>>>>> DM
>>>>>>>>
>>>>>>>> On Mar 8, 2014, at 5:26 PM,
>>>>>>>> Martin Denham <mjdenham at gmail.com
>>>>>>>> <mailto:mjdenham at gmail.com>
>>>>>>>> <mailto:mjdenham at gmail.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Is there an efficient way
>>>>>>>> to find if a BibleBook is
>>>>>>>> contained in a Book (Bible or
>>>>>>>> commentary) using JSword?
>>>>>>>> >
>>>>>>>> > I recall this subject being
>>>>>>>> discussed but can't recall the
>>>>>>>> outcome.
>>>>>>>> >
>>>>>>>> > Thanks
>>>>>>>> > Martin
>>>>>
>>>>> _______________________________________________
>>>>> sword-devel mailing list:
>>>>> sword-devel at crosswire.org
>>>>> <mailto:sword-devel at crosswire.org>
>>>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your
>>>>> settings at above page
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jsword-devel mailing list
>>>>> jsword-devel at crosswire.org
>>>>> <mailto:jsword-devel at crosswire.org>
>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> jsword-devel mailing list
>>>> jsword-devel at crosswire.org
>>>> <mailto:jsword-devel at crosswire.org>
>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> jsword-devel mailing list
>>>> jsword-devel at crosswire.org
>>>> <mailto:jsword-devel at crosswire.org>
>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> <mailto:jsword-devel at crosswire.org>
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>
>>>
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> <mailto:jsword-devel at crosswire.org>
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> <mailto:jsword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org <mailto:jsword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org <mailto:jsword-devel at crosswire.org>
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
More information about the jsword-devel
mailing list