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 <DataPath>/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