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

[Chris Burrell]

Hi

I think I mentioned this before, but the files that JSword use are here:
https://github.com/crosswire/jsword/tree/master/src/main/resources/org/crosswire/jsword/versification

It would indeed be nice if we could use the same format specifications.

The documentation lines 80-ff of the following file outlines the semantics
that we adopted for JSword:
https://github.com/crosswire/jsword/blob/master/src/main/java/org/crosswire/jsword/versification/VersificationToKJVMapper.java

The following file outlines some simple use cases:
https://github.com/crosswire/jsword/blob/master/src/test/java/org/crosswire/jsword/versification/VersificationToKJVMapperTest.java

We mainly use the range notations at present (not the offsets).

Shout if things are not clear.
Chris



On 4 March 2014 20:26, Костя Маслюк <kostyamaslyuk at gmail.com> wrote:

>
> 28.02.2014 23:42 пользователь "Troy A. Griffitts" <scribe at 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.
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140304/9afd69eb/attachment-0001.html>