[sword-devel] Av11n and coverage

scribe777@gmail.com scribe at crosswire.org
Sun Feb 12 09:07:51 MST 2012

Right, this opens up all kinds of discussion, as you point out.

* if we have scope= in the .conf, what does this mean?
Author intent?
  What does that mean?
    A checksum for their actual content (I don't like this)
    An entire sub- v11n definition (I don't like this)
Simply a cache of the derived actual module content (I don't like this)

So, I think it's safe to say that I don't like anything about having it in the .conf

* if we provide a method in the engine to get the actual scope, what does this mean?

Frontend are strongly advised to only display navigation for actual content?
  As Jonathan pointed out, if the ESV doesn't include 1 verse which is in the KJV v11n scheme, do we really want to limit the user from selecting this verse?

Maybe only suggest using for book display?
... only for book and chapter display?

Dunno. I can whip up a very optimized method to return the actual module scope, so I'd rather not simply cache it in the .conf file with scripts which are yet another requirement for repository maintainers to run.


Jonathan Morgan <jonmmorgan at gmail.com> wrote:

>Hi Troy,
>On Sat, Feb 11, 2012 at 7:39 AM, Troy A. Griffitts
><scribe at crosswire.org>wrote:
>> Hey guys.  I'm remember this thread from a while back am to lazy to
>> back and look.
>> Please remind me why we want a .conf entry and not a call like:
>> SWMgr library;
>> SWModule *kjv = kjv = library.getModule("KJV");
>> VerseKey testKey = "jn.3.16";
>> // ------------------------------**--
>> ListKey range = kjv.getModuleScope();
>> // ------------------------------**--
>> range = testKey;
>> if (range.Error()) cerr << testKey << " is not within the range: " <<
>> range.getRangeText() << endl;
>> The only thing missing is the SWModule::getModuleScope() method which
>> could easily be written to scan the module and produce an appropriate
>> ListKey.
>> The .conf file is an opportunity for inconsistency.  It can be a
>> checksum or a pain in the butt maintenance nightmare and I'm thinking
>> latter.
>As I would see it, a principle difference would be author intention. 
>If we
>have a conf file, then we know that (at some point) the author intended
>limit the range in this way.  However, if we have a module we do not
>that the author deliberately intended particular parts to be excluded,
>whether they left them out by accident.  This is particularly
>if it is just individual verses left out.  Does that mean in any
>we have we should explicitly not display those verses?  For example,
>consider Mark 9:46 in the ESV.  It is not present in the text (though
>gap is there because it was present in the KJV, and the same
>is being used), but arguably you don't want the application to tell you
>"this verse isn't present in the ESV" or to not allow you to select
>9:46 or link to it or anything like that.
>> On 02/10/2012 04:35 PM, David Haslam wrote:
>>> Let's not forget that some modules are for a work in progress by the
>>> translators.
>>> e.g. A New Testament only module may have plenty of cross-references
>to OT
>>> passages, in anticipation that the translation would one day
>eventually be
>>> completed.
>>> And - yes - as DM noted, xrefs for modules that are scope-restricted
>>> should
>>> be linkable for parallel modules that contain the missing books,
>>> David
>>> --
>>> View this message in context: http://sword-dev.350566.n4.**
>>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>>> ______________________________**_________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> Instructions to unsubscribe/change your settings at above page
>> ______________________________**_________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
>sword-devel mailing list: sword-devel at crosswire.org
>Instructions to unsubscribe/change your settings at above page

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

More information about the sword-devel mailing list