I would like to chime in briefly with a real world case of option 2
below that I am dealing with right now. I am working on a paper on the
Psalms where versification varies quite a bit between versions
(Leningrad, LXX, and KJV, etc.). I use both BibleTime and Logos because
both offer features I need but neither offers it all. What I would like,
as a biblical scholar, is to have the WLC and my own translation with
Leningrad versification line up in parallel to say the ESV and the LXX
with the correct verse numbers in each text displaying with the correct
content, but the corresponding content appearing side-by-side. Logos
does this pretty well. If I type in Psalm 3:2 in the Hebrew text, the
ESV of Ps 3:1 is next to it. Or if I go to Ps 15 in Hebrew, the LXX
shows Ps 14. When I use BibleTime I wish I could synchronize Bible
windows like I synchronize commentaries with the Bible. That is the best
analogy to what Logos does. Anyway, for what it's worth, that is my real
world case for use case #2 below. I am excited about this conversation!
Daniel
On 11/09/2010 01:12 PM, Troy A. Griffitts wrote:
Hey Konstantin,
Quick comment right now to stir discussion among frontend developers:
On 11/09/2010 05:16 PM, Konstantin Maslyuk wrote:
2. some verses point to ranges of verses. should i change bounds in
this case (UpperBound())?
To answer this, I believe we need to outline our use cases. I can think
of 3:
1) A user is viewing a verse, say Ps 95:5 in the KJV, and then wants to
switch Bibles to one with an alternate v11n, say the LXX. Typically a
frontend will want to do something like:
bible2.setKey(bible1.getKey());
displayChapter(bible2).
2) A user wants to display 4 Bibles in parallel, all with differing v11n
schemes.
3) A developer simply wants to make a call directly to the engine for
whatever purpose to see how one verse maps to another scheme, or one
range of verses maps to another (which might help in case 2).
Are there any other use cases? (I guess #3 isn't necessarily a use case,
I included it because it seems obviously necessary, but still can't
think of a practical application for this information-- except possibly
to solve use case #2)
1 seems easy for a frontend. 2 seems a nightmare so we have to assist
them as much as possible. I haven't even started to imagine how
frontend developers feel the display logic should work. Would be
interested to sample some of the other Bible software out there which
does this and see what they display. But the preference is really for
the frontend develpers to decide and we need to give them the
appropriate data for what they want to build. I can think of easy
solutions that work 95% of the time and wouldn't require likely any code
changes for the frontend developers from their current parallel display
code, but that might not be sufficient enough for some and we want to
give them an interface to assist them with their display logic. So I
guess we need to hear from them.
3. and if target content doesnt exist, what i should do, just set
error?
Maybe again depends on the use cases we finalize on, but this one sounds
like we could probably go with your suggestion and set
KEYERR_OUTOFBOUNDS. Though we might help the API user by positioning
the key to the closest location along with raising the error? If that
even makes sense?
Troy
_______________________________________________
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
_______________________________________________
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
