[bt-devel] [sword-devel] Judges: Judg or Jud? and the handling of invalid references

[Jonathan Marsden]

Chris Little wrote:

> There's no mention of which version of ISBE was tested here, but I'll
> address this as if it were the latest edition that is being discussed
> since the problem does exist there. (But it's my suspicion that this
> report is actually based on the previous version.)

I only got involved a couple of months ago, so I have no SWORD modules I
downloaded earlier than that.  I used the ISBE, downloaded from
CrossWire, that says in isbe.conf that it is:

  Version=1.6
  SwordVersionDate=2008-11-26

I'm retesting now on a fresh download from the CrossWire repository,
just in case something "unique" happened earlier.

> The problem, in any event, is in the module (at least for now).

OK... I think it would be "nice" (helpful, and appropriate) if the front
end software could warn the end user of such problems (since this would
both make the user aware of the immediate issue, and also probably lead
to feedback to module creators fairly quickly, and so to getting the
relevant modules fixed).

Since I expect SWORD can take a reference of the form Book X:Y and
convert it to some internal SWORD key format, and also convert that
internal format back again into a textual reference... testing whether
any given Book X:Y reference is canonical could be as simple as
converting to internal form and back, and comparing the two strings for
equality??

If that is too computationally expensive to do every time a link is
hovered over or clicked on, it could at least be done during module
import, I would think?

Of course, once the norm for input source is an OSIS XML document, then
one can (and should!) validate that XML; but even before that becomes
the norm, surely the above simpler approach, or something like it, could
be run over the existing module set and catch this kind of thing,
improving overall accuracy and utility of the module collection?

>>> (a) References to books of the Bible should use some standard form for
>>> the names of books.  MHC uses Judg for Judges, which works fine in BT.
>>> ISBE uses Jud for Judges, which does not work correctly in BT.  Where is
>>> the standard defined, and which one is correct (I'd guess ISBE is
>>> correct) according to that standard?

>> I believe Jud for Jude and Judg for Judges is considered correct.

I found what is probably "the standard".  On the OSIS web site, per the
OSIS 2.1.1 User Manual, Appendix C, Judg and Jude are apparently
considered "normative".

>> In Sword, Jude X:Y, is Revelation X - 1: Y when X > 1.  I don't think
>> that behaviour desirable, but some people seem to like it.

> Verse normalization can be disabled.

That behaviour makes no sense to me as a (naive? casual?) reader of the
texts concerned, either, and leads in this case to effectively
random-seeming references.  Is there a preference in BibleTime (and
Xiphos) that can toggle this on and off?  If not, how hard would it be
to add one?

>>> (c) I'd expect that a quick fix would be to change all the references
>>> that start with "Jud " in the ISBE into "Judg " and then compile the
>>> resulting text back into a module again.  That's theoretically a simple
>>> one liner:
>>>
>>>  mod2imp ISBE |sed -e 's/>Jud />Judg /g' |imp2ld ISBE ISBE
>>>
>>> On my system that takes up 100% of one CPU core...

> I believe the old ISBE has a key sorting error that will result in an
> infinite loop.

OK.  You didn't provide a version number for "old ISBE" or "the latest
version", so I am now trying a little shell script to make sure I use
what should be the latest one from CrossWire:

#!/bin/bash
# Fixes ISBE refs to Jud X:Y to be Judg X:Y so they work in BibleTime

installmgr -u ISBE		# Uninstall whatever ISBE we may have
installmgr -r CrossWire		# Refresh Crosswire source
installmgr -ri CrossWire ISBE	# Install the latest ISBE from CrossWire
mod2imp ISBE |sed -e 's/>Jud />Judg /g' |imp2ld ISBE	# Fix refs

I'm seeing the same kind of CPU busy looping in imp2ld as the first
time.  It has been running on one core of my CPU for over 30 minutes
now... so I'm pretty sure this is not the expected/desired behaviour of
imp2ld.

Maybe the key sorting error persists in the version currently being
distributed by CrossWire's repository?  Or perhaps the version of ISBE
in the CrossWire repository is "old"?

Thanks,

Jonathan