[sword-devel] SUMMARY TO DATE [load v11n from file]
DM Smith
dmsmith at crosswire.org
Sat Jul 16 12:03:15 MST 2011
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 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.
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
More information about the sword-devel
mailing list