[sword-devel] GenBook osisID and URIs
jonmmorgan at gmail.com
Tue May 13 18:39:31 MST 2008
On Wed, May 14, 2008 at 10:24 AM, Ben Morgan <benpmorgan at gmail.com> wrote:
> > > If you have a link like sword://KJV/Mark.2.10,14 it will give you a
> > > verse list in BibleCS (and you can then click on the individual verses).
> > > (For some reason, sword://KJV/Mark.2.10,Mark.2.14 does the same, but
> > > takes the verses to be Mark 2:10 and 2:2, which is probably a bug in the
> > > verse list parser.)
> > >
> > Sounds very much like a bug.
> It is indeed a bug. The problem is in the parsing logic, and is a problem
> with using .'s with commas
> Either of the following variations will work fine:
> Mark.2.10,Mark 2:14
> To fix this, the following patch will suffice (I think - but the code is a
> *tad* messy).
> Index: src/keys/versekey.cpp
> --- src/keys/versekey.cpp (revision 2156)
> +++ src/keys/versekey.cpp (working copy)
> @@ -669,6 +669,7 @@
> if (!notAllDigits)
> + comma = 0;
> number[tonumber] = 0;
> tonumber = 0;
> if (*number)
> However, even with this patch, the behaviour of the following is unexpected:
> Mark.2.10,2.8 -> Mark 2:10, 28
> Mark 1 1 -> Mark 11
> The code is very messy, and any attempts to change it will probably break
> Also, with the protocol discussion, I think it is worthwhile for each
> application to have a dedicated protocol, plus be able to use the shared
> ones. (probably grab them on a first come first served basis?)
> So for instance, BPBible might natively use bpbible://KJV/Gen.1.1
> Otherwise systems which rely on the correct one being available (kiosword,
> and firebible, for example) will be incompatible with each other. This is
> not a good thing.
> Also, if I was specifying a bible protocol, I wouldn't do the version first.
> I'd do something like bible://Gen.2.5?module=KJV or even
> bible://Gen.2.5?bible=KJV or bible://Gen.2.5?version=KJV
> After all, the user is more likely to want to look up a location than to
> specify which module to use. That should be picked by the application,
> either based on a user setting, or the last one used.
Part of what is at issue here is if we expect the user to be typing or
looking at such URLs directly. If they are, then such things may be
an issue. However, if they are viewing and bookmarking references but
not entering URLs, then we can pick anything we like that is half
> As to doing it for other books - I like the look of sword://Josephus/The War
> of the Jews/Book 1/Chapter 2/Section 3 or encoded equivalent. I don't think
> embedded slashes matter that much - after all, this is what you would expect
> for a url on a website with well-structured content. This is very easy for
> users to understand - an advantage if they are bookmarking it.
Do they need to understand it if they bookmark it? Typically,
bookmarks have a title of some sort, which they will see, rather than
More information about the sword-devel