Re: [sword-devel] load v11n from file
Indeed, possibility to use module-supplied v11n can seriously simplify process of development multiple v11ns. If was discovered that any built-in v11n or mappings contain errors we can update that module with module-supplied v11n, then after new version of engine and applications will be released with fix, we can update module back on built-in v11n. Process of module update is much simpler than updating engine. ___ 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
Re: [sword-devel] Alternate Versification for (Protestant) French Bibles?
Chris, Yes - I'm talking about each single translation in its own right. See also http://fr.wikipedia.org/wiki/Traductions_de_la_Bible_en_fran%C3%A7ais My own printed French Bible is Version Synodale 1962, but I'm pretty sure it is in a long line of tradition that follows the same v11n, which includes the David Martin translation. Many of the subsequent Protestant translations are descended from David Martin's revision of the Geneva Bible in 1707. I think our FreMartin module was "squeezed into KJV v11n" by the persons who digitized the text source (http://www.biblemartin.com/) that we derived it from in July 2008 . This sort of thing happens all over the world wide web, as there are so few folk who really appreciate the complexities of av11n. On some websites, this has even meant the loss of certain passages, those that fall outside the KJV v11n. Earlier this week, I analysed the v11n of the 150 Psalms, with the results tabulated in an Excel worksheet. Available on request. 126 Psalms have a CT. For 59 of these, the CT is all of verse 1. For 4 of these, the CT is verses 1-2. For the other 63, the CT is only part of verse 1. Your suggestion about adapting \d to become \d_...\d* is a sensible workaround. We ought to discuss it with the USFM experts in UBS. btw. Peter has already made contact with someone at UBS for initial advice on this topic, but this was before my detailed analysis, when we both thought that every one of the CTs was the whole of verse 1. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Alternate-Versification-for-Protestant-French-Bibles-tp3653812p3671558.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ 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
Re: [sword-devel] Alternate Versification for (Protestant) French Bibles?
Here is a french page describing versification for some translations, mostly french. There nothing about psalms headers. http://bibliquest.org/Bibliquest/Bibliquest-Discordances_de_numerotation_des_versets.htm Some points from the header of this page: - Versification came from english bishop Stephen Langton (12th century) for chapters and french Robert Étienne in 1551 for verses. - Athias (from Nederland) published in 1661 a Hebrew Bible using versification according to common paragraph usage by jewish people. Most european hebrew bibles published after that were following the same versification. And after that, many european bible translation where using the same versification. -- Seb, autocuiseur ___ 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] SUMMARY TO DATE [load v11n from file]
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): > > > > osisRef="Gen.1.2-Gen.1.3"/> > > > > > 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 tes
Re: [sword-devel] Alternate Versification for (Protestant) French Bibles?
Thanks Seb. Very useful page, though as he states in the header paragraph, "The comparison below of the various versions of the Bible in terms of divisions into chapters and verses was made on a selection of Bibles somewhat arbitrary, some quite common translations were not analyzed." No mention of the David Martin translation. I knew about Psalm 13 verese 5 & 6, but not about Psalm 29:11 (Zadoc Kahn). Further research is required in regard to the CTs. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/Alternate-Versification-for-Protestant-French-Bibles-tp3653812p3671668.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
I've been following the thread and I think that's a fair summary, Troy. Though we have not yet come across such a translation, it's also conceivable that in future we may receive a set of USFM files that make some use of the *\va* and *\ca* tags. I've described this in the wiki, when I added the new section the other day. http://crosswire.org/wiki/Alternate_Versification#Bibles_with_more_than_one_Versification We probably don't have any thoughts on this yet. David -- View this message in context: http://sword-dev.350566.n4.nabble.com/osis2mod-unhappy-with-New-Testament-osisIDs-tp3663231p3671673.html Sent from the SWORD Dev mailing list archive at Nabble.com. ___ 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
Re: [sword-devel] load v11n from file
On 16/07/11 12:33, Troy A. Griffitts wrote: > 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. I am basically in agreement with you and acknowledge the benefit for supporting modules which v11ns not yet established in the engine, but here is a brief summary of our current situation with its pain, and my concerns about moving forward with what we've discussed: I. Currently 1) We force module developers to choose a v11n. This is painful for them, but in their own interest, as it will enable their module to work within the future utopia of a cross-module equivalent content reconciliation implementation (CMECRI, pronounced: see-me-cry) 2) The downside for the module developer is: a) their module sometimes has verses concatenated together if they choose a v11n which doesn't have enough 'slots'; b) worse, they don't have a v11n yet available to choose II. If we enable the ability for a module to supply something like /v11n.conf, which defines a custom v11n, I fear: 1) PEOPLE WILL ACTUALLY USE IT... always... because they are shortsightedly of the opinion it is 'right'. a) Module developers will never accept I.2.a, but instead will always define their own v11n so their verses will never be merged with another verse. b) I can see module repositories existing which publish Bibles and Commentaries which always include a v11n.conf. We cannot optimize for this and cannot easily move forward with CMECRI in this hypothetical scenario. 2) WE LOSE MOTIVATION a) for module developers to do the hard work and give us the information we need about their module, for us to move forward with CMECRI. e.g., we need to know with which v11n their module best fits, and we need to know where the exceptions lie. I realize we can still ALLOW them to provide this data, but if they are not forced to make these decisions, like they are currently forced to do, they will not make these decisions. b) for us to continue to define v11n systems. If we don't need to define a common denominator v11n for a set of modules before we can release them, we won't... well, we won't as quickly as we would if we had to. ___ Just to be sure we both have the save vision of module v11n utopia, I think we both have similar desires like: All the world's v11n systems defined internally in the engine in under 50 v11ns. CMECRI between any 2 systems. Module developers have to choose the best match, and provide exceptions, (which even allows verses to exist which otherwise might be merged, and which CMECRI takes into account). Yes? Troy > > > 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). >>
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
On Sat, Jul 16, 2011 at 6:04 AM, David Haslam wrote: > I've been following the thread and I think that's a fair summary, Troy. > > Though we have not yet come across such a translation, it's also conceivable > that in future we may receive a set of USFM files that make some use of the > *\va* and *\ca* tags. I have only ever encountered a single Bible that made use of such technology - the Jerusalem Bible. Such an ability would be germane to development of that (not that we can, due to copyright). And it is also possibly of interest to your other discussion as the JB is a French-based translation. --Greg ___ 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
For JSword, I'm planning on having the v11n in external resources. If the performance is not good, then it'll be moved internally. Can we define the format of the file? That way, we won't need to change it if SWORD ever externalizes it. In Him, DM On Jul 16, 2011, at 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 >>
[sword-devel] Prevent setKey from 'Leaking' into overlapping chapters/books
Hi folks, I'm just getting started with Sword, and Im working through the included examples. How can I prevent the verse parser from mapping a non valid reference to the next logical book/chapter? For example if I run verserangeparse (in /examples) with "jn22:1" I get acts 1:1, which is the next logical chapter/verse since jn22 doesn't exist. Verserangeparse jn243:1 yields revelation 22:1 Any help? Sorry for the noob question... Also, is there more extensive API documentation than the API primer on the crossword site? Regards, Alex ___ 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
Re: [sword-devel] Prevent setKey from 'Leaking' into overlapping chapters/books
Hey Alex, Well, it depends on what behavior you want to happen when parsing an 'invalid verse reference'. 1) Error() should be raised when parsing is completely misunderstood 2) You can set VerseKey::Normalize to false, and arguably Error() should be raised when parsing chapters and verses outside of the versification system, but I'm not sure Error() is raised currently. 3) if Normalize is false, you can check chapter and verse against VerseKey::getChapterMax() and VerseKey::getVerseMax() to see if it is outside the versification system. Hope this is slightly useful. You'll find the wrapping useful for things like: // show a context window int contextWindow = 5; for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow; verseKey++) ... // show previous chapter verseKey.setChapter(verseKey.getChapter() - 1) ... etc. Regarding more API help and more examples. There is some documentation pulled from the comments in the code as doxygen here (but not as concise or helpful for a beginner as could be): http://www.crosswire.org/~ghellings/1_6_2classdocs/ But I think your best bet is the examples/ and tests/ directory in the source tree. If there is an example you would like to see, please shout and we can write one up together and improve the resources of example out. Troy On 16/07/11 17:36, Alex S wrote: > Hi folks, > > I'm just getting started with Sword, and Im working through the included > examples. How can I prevent the verse parser from mapping a non valid > reference to the next logical book/chapter? > > For example if I run verserangeparse (in /examples) with "jn22:1" I get acts > 1:1, which is the next logical chapter/verse since jn22 doesn't exist. > > Verserangeparse jn243:1 yields revelation 22:1 > > Any help? Sorry for the noob question... > > Also, is there more extensive API documentation than the API primer on the > crossword site? > > > Regards, > Alex > > > > ___ > 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
Re: [sword-devel] Prevent setKey from 'Leaking' into overlapping chapters/books
Sorry, infinite loop typo... On 16/07/11 17:56, Troy A. Griffitts wrote: > // show a context window > int contextWindow = 5; - for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow; verseKey++) ... + for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow; verseKey++,contextWindow--) ... -Troy > > // show previous chapter > verseKey.setChapter(verseKey.getChapter() - 1) > ... > > etc. > > > Regarding more API help and more examples. There is some documentation > pulled from the comments in the code as doxygen here (but not as concise > or helpful for a beginner as could be): > > http://www.crosswire.org/~ghellings/1_6_2classdocs/ > > But I think your best bet is the examples/ and tests/ directory in the > source tree. > > If there is an example you would like to see, please shout and we can > write one up together and improve the resources of example out. > > Troy > > > > > > > On 16/07/11 17:36, Alex S wrote: >> Hi folks, >> >> I'm just getting started with Sword, and Im working through the included >> examples. How can I prevent the verse parser from mapping a non valid >> reference to the next logical book/chapter? >> >> For example if I run verserangeparse (in /examples) with "jn22:1" I get acts >> 1:1, which is the next logical chapter/verse since jn22 doesn't exist. >> >> Verserangeparse jn243:1 yields revelation 22:1 >> >> Any help? Sorry for the noob question... >> >> Also, is there more extensive API documentation than the API primer on the >> crossword site? >> >> >> Regards, >> Alex >> >> >> >> ___ >> 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
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 en
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
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 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 kn
Re: [sword-devel] Prevent setKey from 'Leaking' into overlapping chapters/books
Troy, Thanks so much for the reply. I added parser.setAutoNormalize(false) before the result = parser.ParseVerseList() in verserangeparser.cpp. Now when I run the program with an invalid reference like jn22:1, I don't get any output but it looks like it errors out, even if I have some valid references in the list, such as jn3:16,jn22:1. Could you give me a few pointers on how to skip over the bad values in the for loops and continue execution wit the valid references? Regards Alex On Jul 16, 2011, at 11:56 AM, "Troy A. Griffitts" wrote: > Hey Alex, > > Well, it depends on what behavior you want to happen when parsing an > 'invalid verse reference'. > > 1) Error() should be raised when parsing is completely misunderstood > > 2) You can set VerseKey::Normalize to false, and arguably Error() should > be raised when parsing chapters and verses outside of the versification > system, but I'm not sure Error() is raised currently. > > 3) if Normalize is false, you can check chapter and verse against > VerseKey::getChapterMax() and VerseKey::getVerseMax() to see if it is > outside the versification system. > > Hope this is slightly useful. > > You'll find the wrapping useful for things like: > > // show a context window > int contextWindow = 5; > for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow; > verseKey++) ... > > // show previous chapter > verseKey.setChapter(verseKey.getChapter() - 1) > ... > > etc. > > > Regarding more API help and more examples. There is some documentation > pulled from the comments in the code as doxygen here (but not as concise > or helpful for a beginner as could be): > > http://www.crosswire.org/~ghellings/1_6_2classdocs/ > > But I think your best bet is the examples/ and tests/ directory in the > source tree. > > If there is an example you would like to see, please shout and we can > write one up together and improve the resources of example out. > > Troy > > > > > > > On 16/07/11 17:36, Alex S wrote: >> Hi folks, >> >> I'm just getting started with Sword, and Im working through the included >> examples. How can I prevent the verse parser from mapping a non valid >> reference to the next logical book/chapter? >> >> For example if I run verserangeparse (in /examples) with "jn22:1" I get acts >> 1:1, which is the next logical chapter/verse since jn22 doesn't exist. >> >> Verserangeparse jn243:1 yields revelation 22:1 >> >> Any help? Sorry for the noob question... >> >> Also, is there more extensive API documentation than the API primer on the >> crossword site? >> >> >> Regards, >> Alex >> >> >> >> ___ >> 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
On 7/16/2011 12: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 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 An auto advance through blank verses, or auto advance only if it leads to a new chapter, may be a fix if it doesn't break something else. Jerry ___ 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
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. 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. 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. 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 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 al
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
I think it would be just a binarized canon header file: string, string, string, int, string string, string, int, . . . DM Smith писал(а) в своём письме Sat, 16 Jul 2011 18:07:21 +0400: For JSword, I'm planning on having the v11n in external resources. If the performance is not good, then it'll be moved internally. Can we define the format of the file? That way, we won't need to change it if SWORD ever externalizes it. In Him, DM On Jul 16, 2011, at 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): <вырезано> this way work proper without collisions and non-coordination <вырезано> v11n from module II) I expressed concern about the "no dynamic shared v11ns" aspect of #2, stating that it: <вырезано> Bibles of differing v11ns to the same content. and stressed the unhappy need for the extra work <вырезано> so module developer can avoid defining how their Bible maps to all other Bible modules, but instead can say: <вырезано> 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: <вырезано> ___ 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
Re: [sword-devel] load v11n from file
I. Currently 1) We force module developers to choose a v11n. This is painful for them, but in their own interest, as it will enable their module to work within the future utopia of a cross-module equivalent content reconciliation implementation (CMECRI, pronounced: see-me-cry) 2) The downside for the module developer is: a) their module sometimes has verses concatenated together if they choose a v11n which doesn't have enough 'slots'; b) worse, they don't have a v11n yet available to choose I would agree here, for the sake of few places that can be forced to any existent v11n there is no need to define and use module-supplied v11n. Except definition of 'future utopia', at least because i have everything to define and get the same content for such unlike modules as KJV and RusSynodal. II. If we enable the ability for a module to supply something like /v11n.conf, which defines a custom v11n, I fear: I hope that i persuaded you that path #2 is preferred, because in relation of user repositories with path #1 collisions are inevitable. 1) PEOPLE WILL ACTUALLY USE IT... always... because they are shortsightedly of the opinion it is 'right'. a) Module developers will never accept I.2.a, but instead will always define their own v11n so their verses will never be merged with another verse. b) I can see module repositories existing which publish Bibles and Commentaries which always include a v11n.conf. We cannot optimize for this and cannot easily move forward with CMECRI in this hypothetical scenario. I m not sure, define v11n with mappings is not a simple thing. If you make changes in canon you also need to define how this changes are mapped. It is additional work that need a lot of attention to make every thing work right. I'm not sure that for module maker way to contract or expand a few of verses is simpler then to define own v11n. Even in regard of that module maker thinks that his source is the most right. I can share concerns of that tomorrow every module maker will make own v11n. But i also was witnessed that engine changes would destroy a module, when in Synodal canon in Psalms was added one verse, and i got skipped first verse in every chapter across the rest of OT. It is great if module maker forced to use any standard v11n for his module, but it will be terrible if one day in that v11n something will change. If we change something in canon in engine then, we need to synchronously update all existing modules of that canon. With external v11n displayed result will always be the same. Summarize, we may need external v11n to avoid desynchronization of v11n in engine and module, but we may need to close access to the tools. 2) WE LOSE MOTIVATION a) for module developers to do the hard work and give us the information we need about their module, for us to move forward with CMECRI. e.g., we need to know with which v11n their module best fits, and we need to know where the exceptions lie. I realize we can still ALLOW them to provide this data, but if they are not forced to make these decisions, like they are currently forced to do, they will not make these decisions. b) for us to continue to define v11n systems. If we don't need to define a common denominator v11n for a set of modules before we can release them, we won't... well, we won't as quickly as we would if we had to. Agree, centralized work over v11ns is still necessary. You have very strict policy of accepting modules even not regarding to copyright issues. I have Russian Commentary that was ignored twice on mod...@crosswire.org (i cant remember, at least ones). Open Source gives ability to do every thing to anyone with preservation of centralized development. ___ Just to be sure we both have the save vision of module v11n utopia, I think we both have similar desires like: All the world's v11n systems defined internally in the engine in under 50 v11ns. CMECRI between any 2 systems. Module developers have to choose the best match, and provide exceptions, (which even allows verses to exist which otherwise might be merged, and which CMECRI takes into account). Yes? I do not see difference internally or externally if we talk about final. Internally it is normal for me and i can agree with this. But this thread is more about how we will achieve this 50 v11n with correct transitions between. And would i consider this as lets delay publication of Russian modules for years yet, to ensure we have correct mappings to other v11ns? ___ 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
Re: [sword-devel] Prevent setKey from 'Leaking' into overlapping chapters/books
Ok, I did what Troy initially recommended, i.e. Checking if VerseKey.getVerse()>VerseKey.getMaxVerse, ditto for the chapter. If this is true, I used ListKey.SetToElement() and ListKey.Remove() to remove the invalid reference(s). Works great. I can see the utility of wrapping for interactive GUI apps, but it's not useful for single command-line reference lookups, such as in the example I referred to originally. Thanks for the help. Regards, Alex On Jul 16, 2011, at 11:56 AM, "Troy A. Griffitts" wrote: > Hey Alex, > > Well, it depends on what behavior you want to happen when parsing an > 'invalid verse reference'. > > 1) Error() should be raised when parsing is completely misunderstood > > 2) You can set VerseKey::Normalize to false, and arguably Error() should > be raised when parsing chapters and verses outside of the versification > system, but I'm not sure Error() is raised currently. > > 3) if Normalize is false, you can check chapter and verse against > VerseKey::getChapterMax() and VerseKey::getVerseMax() to see if it is > outside the versification system. > > Hope this is slightly useful. > > You'll find the wrapping useful for things like: > > // show a context window > int contextWindow = 5; > for (verseKey-=(contextWindow/2); !verseKey.Error() && contextWindow; > verseKey++) ... > > // show previous chapter > verseKey.setChapter(verseKey.getChapter() - 1) > ... > > etc. > > > Regarding more API help and more examples. There is some documentation > pulled from the comments in the code as doxygen here (but not as concise > or helpful for a beginner as could be): > > http://www.crosswire.org/~ghellings/1_6_2classdocs/ > > But I think your best bet is the examples/ and tests/ directory in the > source tree. > > If there is an example you would like to see, please shout and we can > write one up together and improve the resources of example out. > > Troy > > > > > > > On 16/07/11 17:36, Alex S wrote: >> Hi folks, >> >> I'm just getting started with Sword, and Im working through the included >> examples. How can I prevent the verse parser from mapping a non valid >> reference to the next logical book/chapter? >> >> For example if I run verserangeparse (in /examples) with "jn22:1" I get acts >> 1:1, which is the next logical chapter/verse since jn22 doesn't exist. >> >> Verserangeparse jn243:1 yields revelation 22:1 >> >> Any help? Sorry for the noob question... >> >> Also, is there more extensive API documentation than the API primer on the >> crossword site? >> >> >> Regards, >> Alex >> >> >> >> ___ >> 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
Re: [sword-devel] SUMMARY TO DATE [load v11n from file]
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 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 tr
