[jsword-devel] Verse 0 in xgen titles - expected behaviour?

Tue Jul 3 02:00:01 MST 2012

I think from a user's point of view, he doesn't know about verse 0, so the
reference of verse 0 should never be shown.

When he enters the references of a whole chapter, he probably wants the
whole chapter, even if he specifies verse numbers. So if you start at verse
1, I would be tempted to include verse 0 in the lookup. The problem that I
see is that verse 0 isn't really a verse from a semantics sense. The user
knows about "intros" so perhaps having an option to toggle the intro on/off
would then include/exclude verse 0.

For scenario 1, this probably doesn't change. You can store based on the
"intro" option whether or not to include verse 0.  Scenario 2 can then
leverage this "option", in that the user has specifically chosen to show or
not show this in the passages he is looking up, and therefore the search
happens on the same context. Same applies to blurring, in that we show
verse 0 if selected.

Perhaps that just means a bit of clever logic in the xslt that BibleDesktop
uses? in the same way headers, etc. are specified...

Chris

On 3 July 2012 00:42, DM Smith <dmsmith at crosswire.org> wrote:

> Sorry for the empty post. Was going to muse whether Chapter n:1 should
> implicitly include all verse 0 before it.
>
>
> On Jul 2, 2012, at 7:39 PM, DM Smith wrote:
>
>
> On Jul 2, 2012, at 12:54 PM, DM Smith wrote:
>
>  The work is done by VerseRange.getName() which calls
> VerseRange.getName(Verse base) which ultimately calls VerseRange
> doGetName(Verse base).
>
> The purpose of this routine is to get a user friendly representation of
> the VerseRange. It is used in more places than just x-gen titles. Here are
> a few more scenarios:
>
> First scenario:
> It is used in a bi-directional context. That is the user can input Gen
> 1:1-31, which is not the same as Gen 1, since Gen 1 can include intros if
> present.
>
> So in BibleDesktop, we allow a user to input verses freeform and we try to
> figure out the best we can what they mean.
>
> In preferences they can either preserve original values in which case we
> only show them what they type, but behind the scenes we store it as we see
> fit.
>
> Or they can choose to have their input normalized into their preferred
> form. This will result in calls to VerseRange.getName(Verse base).
>
> This normalized form is then used to do whatever work is needed. So the
> normalized form needs to be equivalent to what the user originally
> specified.
>
> Second scenario:
> The user performs a search and the answer is included in verse 0. Should 0
> be shown to the user?
>
> Third scenario:
> Blurring: The user has Gen 1:4 in their list and blurs it by 10 verses,
> which results in Gen 1:0-14. Should it show 0? Should it show the intro?
>
> In each of these scenarios, the output is the textual representation of a
> bit map. They need to match.
>
> There may be others, but I know of these off the top of my head.
>
> So how do we change it for your scenario? What should we do for the other
> scenarios?
>
> In Him,
>     DM
>
>
> On 07/02/2012 12:18 PM, Chris Burrell wrote:
>
> Hi DM
>
>  The problem is that a user may type in Exodus 3-4:17 and somehow from
> his point of view gets verse 0 for chapter 4 (and no 0 for chapter 3 (note
> the slight difference from before - same symptoms/results with Ex 3-... and
> Ex 3:1-...  Verse 0 is omitted for this chapter).
>
>  From a user's point of view, he doesn't know about a verse 0 and so
> verse 0 should never be in a title. Or at least, that's my take...
> Chris
>
>
>  On 2 July 2012 17:11, DM Smith <dmsmith at crosswire.org> wrote:
>
>>   On 07/02/2012 11:53 AM, Chris Burrell wrote:
>>
>> Hi
>>
>>  With the introduction of verse 0, the xgen titles sometimes now contain
>> this. I used to use this to display the demarcations between passages if
>> multiple passages are being entered. However, this now gives the following
>> xgen titles:
>>
>>  <title type="x-gen">Exodus 3:1-22</title>
>> <title type="x-gen">Exodus 4:0-17</title>
>>
>>  The above example is for "Exodus 3:1-4:17".
>>
>>  I was just wondering if this *expected *behaviour. If so, I'll code
>> something to work around this. It doesn't however happen for "Exodus  3-4"
>>
>>  I'm not sure how it should work. It is certainly the way it is coded.
>> Chapter 0 and Verse 0 are full fledged references.
>>
>> That is for Genesis
>> Gen.0.0 is the Book intro/title
>> Gen.1.0 is the Chapter intro/title
>>
>> In your example, Exodus 3:1-4:17 explicitly excludes the Chapter 3 intro,
>> if present, but explicitly includes it for chapter 4, if present.
>>
>> So if you want all of Genesis, chapter 1, do you want the title as well?
>> Then Gen.1 will work. But if you don't and headings are turned on, what
>> then? Gen.1.1-Gen.1.21?
>>
>> If you want part of the chapter, say the first 10 verses, what do you
>> want? Gen.1.0-Gen.1.10 or Gen.1.1-Gen.1.10?
>>
>> Right now, the code makes no distinction between one chapter number and
>> another or one verse number and another. Should it?
>>
>> If not, what should it do?
>>
>> In Him,
>>     DM
>>
>>
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>>
>>
>
>
> _______________________________________________
> jsword-devel mailing listjsword-devel at crosswire.orghttp://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
>
>
>
> _______________________________________________
> 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/20120703/2f20a62a/attachment.html>