[sword-devel] Parallel display of modules with varying v11ns

[Костя Маслюк]

28.02.2014 23:42 пользователь "Troy A. Griffitts" <scribe �� crosswire.org>
написал:
>
> Костя,
>
>
> IOn 02/28/2014 08:14 AM, Костя Маслюк wrote:
>>
>> Ok.
>>
>> I have got following:
>> http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html
>
>
> 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.
>
>
>> /me cant get rid of feeling that Troy still did not disabled his
>> screen filter that rips everything i write to him
>
>
> Костя, 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)
> 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.
>

I had noticed that you answering directly to my message and had addressed
me, but only after i sent message.

> 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.
>
> As for the shared mapping data and storage mechanism, we need to
collaborate with JSword.
>
> 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.
>
> I believe you are going from X -> KJV+ -> Y right now.
>
> 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) ... }
> 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.

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.

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.

>
> 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.

We are foredoomed to meet new strange places. I think it is normal to solve
problems as they have place to be.

>
> Chris can comment, but simply mapping the various LXX editions to each
other, alone, can be daunting to think about.

I m too hope on his participation.

>
> 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.

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.

Blessings.
----------- ???????? ????? -----------
???????? ? ??????? HTML ???? ?????????&hellip;
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140305/fdad292b/attachment.html>