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
