[sword-devel] Links in OSIS GenBooks

[Daniel Hilton]

I just submitted a BibleTime bug, and realized that some of the issues might
also need to be addressed in Sword.

In my case specifically, I am dealing with a GenBook module, from an OSIS
original, and am encountering many problems with cross-references.

BibleTime makes the assumption that the prefix for an osisRef attribute is a
sword module name.  I realize that that it is BibleTime's problem if
BibleTime makes an unsafe assumption, but I do belive that Sword could make
more information available to frontends, so that they would not have to make
such unsafe assumptions.

In reality, the prefix of an osisRef must match the osisWork attribute of a
<work> element declared in the <header> (which would not necessarily
coincide with the module name).  Unfortunately, when an osis document is
converted into a GenBook module, all of the osis header information is
lost.  Without that information, frontends are left with no other choice but
to make an educated guess (and frequently be wrong).

A possible solution would be to provide means in the module.conf file to
preserve that information.  It would be easy to define an OsisWork
identifier that would allow the module to identify itself in the .conf file:

OsisWork=IAmABook

but it would be more difficult to map *external* osisWork values to module
names, unless we allow for arbitrary identifiers in the .conf file, i.e. :

OsisWork[osisWork]=[moduleName]
OsisWorkABSGoodSam=abs_essay_goodsam_swb

In the above scenario, any frontend encountering <reference
osisRef="ABSGoodSam:[osisID]">...</reference> could determine from the
module's info to look for the referenced key ([osisID]) in the
abs_essay_goodsam_swb module, or alert the user that the referenced module
isn't present.

Along the same lines, frontends have difficulty with internal references in
OSIS GenBooks, because the documents osisID's are lost when the module is
created ( a valid osisID like I.am.an.ID is converted to a GBS key
/I/am/an/ID ).  However, the osisRef's still contain osisID's.  The ideal
solution (especially considering Sword's plans to support OSIS completely)
would be to key OSIS based GenBooks (or anything else) with osisID's rather
than /GBS/keys.  An alternate solution would be for the frontend to
translate osisID's into GBS keys in cases where the target module is a
GenBook (I actually made that suggestion to BibleTime)... But on further
consideration I think it would be best to address the issue in Sword.

Any thoughts?  Let's discuss..

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20061114/4ef42240/attachment.html