[jsword-devel] Mapping verses to a v11n in which the verse does not exist

Chris Burrell chris at burrell.me.uk
Sat Apr 19 10:22:15 MST 2014


I think the client code has to handle this. A verse is specifically tied to
a versification, and presumably its contract is that it represents a
meaningful verse in the versification.

I think what you're after is a name rather than a verse? so that you can
re-use the name/etc. going forward.

Chris



On 19 April 2014 15:13, Martin Denham <mjdenham at gmail.com> wrote:

> Client code can be amended to handle 'invalid verse or passage' responses
> from the mapping code.
>
> Either that or implement an 'all v11n verse' (or passage etc) which can
> hold a verse reference for any v11n.
>
> They are the only ideas I have unless I have misunderstood the issue.
>
> Martin
>
>
> On 19 April 2014 10:27, Chris Burrell <chris at burrell.me.uk> wrote:
>
>> Righto - so isn't it just a question of changing the catch(AIOB) to throw
>> an error?
>>
>> Chris
>>
>>
>>
>> On 19 April 2014 10:22, Martin Denham <mjdenham at gmail.com> wrote:
>>
>>> The mapping code seems to work fine but QualifiedKey is only used within
>>> the v11n mapping code so as soon as the results from the mapping are used
>>> outside of the mapping code, errors will occur.
>>>
>>> Martin
>>>
>>> On 19 April 2014 09:54, Chris Burrell <chris at burrell.me.uk> wrote:
>>>
>>>> There might be a bug, but the framework itself does support it. The
>>>> purpose of the 'qualifiedKey' wrapper is to store this extra information.
>>>> I.e. you should be able to map across versifications that don't contain the
>>>> verse.
>>>>
>>>> But if you're wanting a particular verse that doesn't exist, then it
>>>> looks like perhaps we simply change the getOrdinal() to throw an exception,
>>>> rather than just swallowing it?
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>> On 19 April 2014 09:47, Martin Denham <mjdenham at gmail.com> wrote:
>>>>
>>>>> Conversion of a verse to a v11n in which it does not exist cannot be
>>>>> done using the current framework so this will need to be checked for in
>>>>> front ends or the JSword Verse will need to be enhanced.
>>>>>
>>>>> If a verse is not in a v11n an ArrayIndexOutOfBoundsException is
>>>>> thrown and silently caught and the ordinal is set to 0, which is 'Bible
>>>>> Introduction 0:0'.
>>>>>
>>>>>     public int getOrdinal(Verse verse) {
>>>>>         try {
>>>>>             return
>>>>> chapterStarts[bookList.getOrdinal(verse.getBook())][verse.getChapter()] +
>>>>> verse.getVerse();
>>>>>         } catch (ArrayIndexOutOfBoundsException e) {
>>>>>             return 0;
>>>>>         }
>>>>>     }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18 April 2014 23:02, Martin Denham <mjdenham at gmail.com> wrote:
>>>>>
>>>>>> The v11n mapper does actually map it correctly to Sir.1.1 but when I
>>>>>> try to get the verse out of the returned RangedPassage it comes out as 'Bible
>>>>>> Introduction 0:0'.  I have expanded on the above demonstration of
>>>>>> the problem below:
>>>>>>
>>>>>>         Key kjvSir1_1 = mapper.mapVerse(CathSir1_1, KJV);
>>>>>>         System.out.println(kjvSir1_1); // This is a RangedPassage
>>>>>> containing: Sirach 1:1, so the mapping is apparently correct
>>>>>>         Verse verse1 = KeyUtil.getVerse(kjvSir1_1);
>>>>>>         System.out.println(verse1);     // This is a Verse
>>>>>> containing: Bible Introduction 0:0
>>>>>>
>>>>>> kjvSir1_1 is a RangedPassage and the root of the RangedPassage
>>>>>> TreeSet is Sir.1.1 but when trying to extract the first value the TreeSet
>>>>>> iterator gets confused and 'Bible Introduction 0:0' is returned.  I haven't
>>>>>> managed to work out why yet.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On 18 April 2014 22:32, Chris Burrell <chris at burrell.me.uk> wrote:
>>>>>>
>>>>>>> Reversify just takes a reference and applies it to the other v11n
>>>>>>> without any mapping.
>>>>>>> Mapping to Intro.0.0 seems like a bug. Should either map to empty
>>>>>>> verse range, or null (empty verse range would be my pref).
>>>>>>>
>>>>>>> In your use case, it should map across to Sir.1.1. I suspect it's
>>>>>>> because the reversify attempts to reversify first to KJV. The reason for
>>>>>>> having a 'qualifiedKey' wrapper is exactly for this purpose, to preserve
>>>>>>> the names of keys that aren't recognised, which doesn't seem to happen. We
>>>>>>> should check the output of reversify and cater for this.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 18 April 2014 22:07, Martin Denham <mjdenham at gmail.com> wrote:
>>>>>>>
>>>>>>>> With split screens I try to map all verses in the left v11n to
>>>>>>>> whatever the right v11n is and just display 'Not found in document' if the
>>>>>>>> verse is not in the right v11n but I am having a problem with this approach
>>>>>>>> because the verses not in the right v11n are currently being mapped to
>>>>>>>> 'Bible Introduction 0:0'.
>>>>>>>>
>>>>>>>> This test hopefully shows the problem:
>>>>>>>>
>>>>>>>>         final VersificationsMapper mapper =
>>>>>>>> VersificationsMapper.instance();
>>>>>>>>         Verse CathSir1_1 = new Verse(CATHOLIC, BibleBook.SIR, 1, 1);
>>>>>>>>         // map Sirach.1.1 to KJV where it obviously does not exist
>>>>>>>>         Key kjvSir1_1 = mapper.mapVerse(CathSir1_1, KJV);
>>>>>>>>         // In the debugger the returned RangedPassage appears to
>>>>>>>> contain Sir.1.1
>>>>>>>>         // but however I try to get the verse it gets changed
>>>>>>>> to Bible Introduction 0:0
>>>>>>>>         Verse verse1 = KeyUtil.getVerse(kjvSir1_1);
>>>>>>>>         System.out.println(verse1); // PROBLEM: Bible Introduction
>>>>>>>> 0:0 (not Sir.1.1)
>>>>>>>>
>>>>>>>> Am I trying to do something that can't be done?
>>>>>>>>
>>>>>>>> I notice that the v11n mapping code uses QualifiedKey.reversify
>>>>>>>> which has the warning:
>>>>>>>>     /**
>>>>>>>>       * Convert this QualifiedKey from one Versification to another.
>>>>>>>>      * This is a potentially dangerous operation that does no
>>>>>>>> mapping
>>>>>>>>      * from one versification to another. Use it only when it is
>>>>>>>> known
>>>>>>>>      * to be safe.
>>>>>>>>      */
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jsword-devel mailing list
>>>>>>>> jsword-devel at crosswire.org
>>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jsword-devel mailing list
>>>>>>> jsword-devel at crosswire.org
>>>>>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20140419/460f05e4/attachment-0001.html>


More information about the jsword-devel mailing list