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 <davidtro...@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@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@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@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
