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

DM Smith dmsmith at crosswire.org
Sat Jul 16 15:36:04 MST 2011 

On Jul 16, 2011, at 3:57 PM, David Troidl wrote:

> 
> 
> On 7/16/2011 3:03 PM, DM Smith wrote:
>> It is possible at least in part. Just define a v11n with 200 chapters per book and 200 verses per book. This doesn't handle alternate book order.
> I think you misunderstood.

Rereading your post, I think I did misunderstand. I see you were talking about a v11n that would never be directly used by a Bible, but rather as the arbiter of CMECRI.

>  Haggai has 2 chapters in any v11n I know of.  It would continue to have 2 chapters in the "master".  And unless there were some Bible that disagreed, it would still have 15 verses in the first and 23 in the second.

True. At least as far as the few versifications that I've looked at. But given my ignorance of *all* versifications, the suggestion of arbitrarily large number of chapters and verses was to have way more than enough space for all possibilities and have no need/consideration for rational analysis.

I picked 200 because it was an even hundred, and bigger than the number of verses or chapters in any Bible book.

-- DM

>> 
>> I used 200 but any suitably large number would work.
>> 
>> The other problem is that verse++ at the real end of a chapter would neither advance to the first verse of the next chapter nor throw an error.
> That would depend on what the "real" chapter end is.

This is where my reading of your note went astray. This v11n would not be used by the KJV or any other Bible.

> In some cases the KJV chapter end is offset by a verse, or even a few verses, from the Hebrew Bible.  And the Septuagint is sometimes offset by a whole chapter.  (Though of course, any v11n is simply a reference system imposed on the Bible by a later editor.)
>> 
>> In Him
>> DM
>> 
>> Cent from my fone so theer mite be tipos. ;)
>> 
>> On Jul 16, 2011, at 1:59 PM, David Troidl<DavidTroidl at aol.com>  wrote:
>> 
>>> 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
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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

More information about the sword-devel mailing list