[sword-devel] SUMMARY TO DATE [load v11n from file]

[David Troidl]

Wouldn't it be possible to have one "master" v11n, that all the others 
could map to (linear growth), rather than trying to map them all to each 
other (exponential growth)?

For example:
1) Psalm 3 could retain the Hebrew Bible numbering, and KJV map the 
heading to 3:1, and 3:1 to 3:2, etc.
2) Psalm 23, the Hebrew could be subdivided: 23:1a being the header 
(23.1!a in OSIS), and 23:1b the KJV 23:1.  Then of course the HB would 
have to map 23:1 to the range 23:1a-23:1b.

It would probably be best to start with the Hebrew Bible, and work off 
of it to accommodate the others.

This would require a study of the existing v11n's, but would probably be 
worth the effort (for some volunteer who had the time).

Peace,

David

On 7/16/2011 6:33 AM, Troy A. Griffitts wrote:
> OK, to summarize where we are, for those who haven't read all the
> details and would like to jump in this weekend on the conversation
> (Konstantin, please correct me if I've misrepresented your position).
>
> I) Konstantin proposed 2 possibly paths and outlined the benefits and
> drawback for both, favoring #2 (path and initial summary, quoted):
>
>> 1. module installation may also install v11n to common folder
>> 1: there is need of a lot attention from crosswire developers, to get
> this way work proper without collisions and non-coordination
>
>> 2. each module may have its own v11n, no dynamic shared v11ns
>> 2: create, test, deliver is simple. just tell in *.conf file to load
> v11n from module
>
>
> II) I expressed concern about the "no dynamic shared v11ns" aspect of
> #2, stating that it:
>
>> disregards our objective to ultimately provide a way to position
> Bibles of differing v11ns to the same content.
>
> and stressed the unhappy need for the extra work
>
>> to enumerate and define versification systems
> so module developer can avoid defining how their Bible maps to all other
> Bible modules, but instead can say:
>
>> "I am basically "Synodal", but have these 5 exceptions, and here is
> how these 5 exceptions should be handled in relation to "Synodal."
>
> III) Konstantin clarified/proposed a hybrid system where we still seek
> to define 'canonical' (no pun intended) internal v11ns, but if an
> internal v11n doesn't yet exist for a module, then the module developer
> can provide a private v11n used only for his/her own module.  The
> primary benefit being that  Primary benefit is that module development
> can move forward before internal v11n is supported in engine.
>
>
> Troy
>
>
> On 15/07/11 17:50, Konstantin Maslyuk wrote:
>>> You make a great and convincing case for proceeding down path #2.
>>>>      2. each module may have its own v11n, no dynamic shared v11ns
>>> Path #2, though, disregards our objective to ultimately provide a way to
>>> position Bibles of differing v11ns to the same content.
>>> I would love to forget about trying to enumerate and define
>>> versification systems (I'm sure Chris would as well), and to stop asking
>>> each Bible module maker to pick which system best represents their data.
>>>
>>> We currently have 13 systems in our engine.  Eventually we need to
>>> extend VerseMgr with a facility to map these between one another
>>> (possibly your implementation).
>>>
>>> You have stated that you have tried with your code
>>>
>>>> KJV(A)<->  Synodal<->  Vulg<->  NRSV v11ns
>>> This implies there exists such a thing as a named list of versification
>>> system in our engine (i.e., NOT path #2).
>> Of cource, most common v11ns must be hard coded! I can not understand
>> here why
>> path #2 can not have mixed v11ns: several built-in and several
>> module-supplied.
>>
>> Except without remark that module name with module-supplied v11n can not
>> be same
>> as built-in v11n.
>>
>> This would be problem of bad statement of thoughts, i didn't meant that
>> all modules
>> should have module-supplied v11n. Sorry.
>>
>>
>> I do not see a problem in making mapping through v11n other than KJV,
>> but verse
>> mapping must always be thought built-in v11n. One v11n for mapping would be
>> enought, or one meta-v11n.
>>
>> Though i do not know yet all problem case with v11n mappings, and i know
>> that there
>> are questionable parts of the Scripture, where in one source one chapter
>> should have
>> one content and second source under the same chapter have different
>> content. But in
>> Sword such parts should be known under unified name (even like v1:Esd.34 =
>> metav11n:Esd.110, v2:Esd.34 = metav11n:Esd.34).
>>
>>> If you allow a module developer to bypass naming which versification
>>> system their module uses, you would still somehow like them to define
>>> how it maps to other Bibles.  I don't see how this is practical without
>>> a named set of known v11n system in the engine.
>>>
>>> I cannot imagine a module developer ALWAYS defining how their module
>>> maps to every other system.
>> Of course if module maker do not use built-in v11n, he should use
>> module-supplied.
>> In any case #1 or #2 he can take ready binary v11n from repository of
>> av11s (that
>> we must provide in any case) and put within module. Or he can take
>> source file for
>> v11n, edit and convert to binary format, and use this binary file as
>> many times as
>> needed. Of course for engine it will be different v11ns, but this is a
>> pay for order.
>>
>> It is also advantage of external v11ns: we can create and test v11ns
>> separate from
>> engine, and if v11n is popular enough or well tested it can be made
>> built-in, and
>> vice versa.
>>
>> Source for v11n would be just an OSIS file (of course, i'm not sure that
>> this is correct):
>> <div type="book" osisID="Gen">
>>      <chapter osisID="Gen.1">
>>          <verse osisID="Gen.1.1"/>
>>          <verse osisID="Gen.1.2"><reference
>> osisRef="Gen.1.2-Gen.1.3"/></verse>
>>          <verse osisID="Gen.1.3"><reference osisRef="Gen.1.4"/></verse>
>>      </chapter>
>> </div>
>>
>> Or add method VerseMgr::saveVersification(const char *file), that will
>> save static
>> arrays of v11n data in to file. So, module maker should write header
>> file with v11n
>> compile and test it, and then call saveVersification, i would agree it
>> is not trivial.
>>
>>
>>> I can imagine a module maker saying, "I am basically "Synodal", but have
>>> these 5 exceptions, and here is how these 5 exceptions should be handled
>>> in relation to "Synodal."
>>>
>>> And then our future mapping system can do it's best with this
>>> information.
>> My mapping system would be flexible with preservation of back
>> compatibility.
>> It is a list of data (rules)
>> 1 1 1 0 1 1 1 2
>> 1 1 2 0 1 1 2 3
>> book/chapter/verse/end_verse/...(same to target)
>>
>> on initialization VerseMgr parses whole data and remembers pointers to
>> the first
>> entry of rule, i would use here magic numbers (245-255) to reserve any
>> kind of
>> specific rules, old version of engine would throw away such rules,
>> because them
>> are not supported.
>>
>> BTW i want to discuss base size for mappings: char, short or int. With
>> char mappings
>> for Synodal it is 1,3 kb, but it is limited up to 255 books/chapter/verses.
>>
>>> But I believe we still need to enumerate a list of officially supported
>>> v11n systems and have module developers choose which one to use.
>> I do not urge to run and make new system for external v11n. Everything
>> should be well
>> discussed and accepted.
>>
>> But for now i see that possibility to load v11n from file would be
>> useful, in process of
>> moving to conception of multiple v11ns. And it is not hard to implement
>> (one function
>> to load v11n from file and add load logic for SWMgr). We do not need
>> tools now.
>>
>>> I'm not happy about the extra work, but do you agree it is necessary?
>> Please, precise what kind of work is necessary now?
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page