<p dir="ltr"><br>
28.02.2014 23:42 ÐÏÌØÚÏ×ÁÔÅÌØ "Troy A. Griffitts" <<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>> ÎÁÐÉÓÁÌ:<br>
><br>
> ëÏÓÔÑ,<br>
><br>
><br>
> IOn 02/28/2014 08:14 AM, ëÏÓÔÑ íÁÓÌÀË wrote:<br>
>><br>
>> Ok.<br>
>><br>
>> I have got following:<br>
>> <a href="http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html">http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html</a><br>
><br>
><br>
> Amazing! šThis looks really great! šDaniel 3 is a nice test chapter. šYour output looks very nice. I will play around with your updates to the test and send mine.<br>
><br>
><br>
>> /me cant get rid of feeling that Troy still did not disabled his<br>
>> screen filter that rips everything i write to him<br>
><br>
><br>
> ëÏÓÔÑ, no, I'm sorry for not replying inline in my last email. šMuch of what I wrote was in response to your emails, but it wasn't obvious because I did not post inline. (notice the repentance with this email)<br>
> I read everything you wrote and was excited to start the conversation again, and concluded that if we can just prove that one implementation CAN handle pretty well a majority of the cases, then we can move forward and commit to this API interface we're trying. The theoretical conversation wasn't going anywhere and a proof of concept seemed to be the best way forward. šAs far as the implementation, I am concerned about your same points, that SWORD and JSword need to have a common set of mapping data and ideally a common storage format for that data. šI'm not concerned about the size and speed immediately as we can always improve the implementation.<br>
></p>
<p dir="ltr">I had noticed that you answering directly to my message and had addressed me, but only after i sent message.</p>
<p dir="ltr">> I just would like the programming interface and how we intend for it to be used by consumers to be solid; I don't want frontend developers to have to change their code. šI think our proof of concept should satisfy this.<br>
><br>
> As for the shared mapping data and storage mechanism, we need to collaborate with JSword.<br>
><br>
> Conceptually, I have always been leery of a 'superset meta v11n' concept to do this mapping. šIt seems the most straightforward way if we can establish this superset, but conceptually it practically prevents things like mappings between the different versifications of Josephus-- which is a very real problem we'd like to solve with the same mechanism.<br>
><br>
> I believe you are going from X -> KJV+ -> Y right now.<br>
><br>
> I think this logic is fine but was hoping for the internal data to be boiled down generically to optimized deltas somehow,e.g.,: X->KJV { verseShift(Ps.9.21-:10.1); chapterShift(Ps.10-112:+1) ... }<br>
> and then when asked to map from X -> Y, we could look at our mappings and find the most optimized path. šIt may still be X->KJV->Y, but it may also be X->Y or JosephusLoeb -> JosephusWhiston.</p>
<p dir="ltr">I think no need to flow down implementation details. Generally i agree that we could add mapping sets. So there will be several sets available as well as KJVA set, that is default and implementation will select shortest path to find corresponding data.</p>
<p dir="ltr">But i suggest to delay this as it will complicate whole system, that is undesired at this stage. I would like to make current implementation to work correctly on current module set. We could create improvement request in jira as we commit this.<br>
</p>
<p dir="ltr">><br>
> If we force the concept of a superset KJV+ v11n scheme into our mapping concept, I am afraid it will limit us and we will continually have to update this meta v11n when we create new modules and find new strange things.</p>
<p dir="ltr">We are foredoomed to meet new strange places. I think it is normal to solve problems as they have place to be.</p>
<p dir="ltr">><br>
> Chris can comment, but simply mapping the various LXX editions to each other, alone, can be daunting to think about.</p>
<p dir="ltr">I m too hope on his participation.</p>
<p dir="ltr">><br>
> This all is aside from the API mechanism on which we are working presently, but just offered for discussion between JSword and SWORD and others when considering how we wish to represent and persist these mappings.</p>
<p dir="ltr">I m too would like to hear thoughts about of how JSword people would like mapping data to persist, because if we ever supply mapping data with module, i want that data to be convenient to work with for them.<br>
</p>
<p dir="ltr">Blessings.<br>
</p>