[jsword-devel] Versifications and key absence

[Chris Burrell]

On the fix up, I don't think we really want that behaviour.

I don't think "your two things that are needed" would solve this case. The
behaviour I have working correctly is for verses that are in a
versification but not in a module. (not sure I can explain why, but I don't
get a NoSuchKey exception). The problem we need to solve is for OSMHB, for
which Mat 1 is neither in the versification, nor in the module. (so, we
presumably need a third check to see if it's in any other versification?)

As an aside, while we decide on a way forward for JSword, my current
workaround is:

- get the key for book X
- if NoSuchKeyException, attempt to get it for KJVA (if installed), if this
works, then return an empty key
- if still NoSuchKeyException, or KJVA not installed, attempt to do the
same in the ESV (which is NRSV now).

For me, returning an empty key is similar to the case where a module
doesn't contain the key in question.

Cheers
Chris



On 6 August 2013 12:59, DM Smith <dmsmith at crosswire.org> wrote:

> Another comment: JSword differs from SWORD in that it does not try to fix
> up an invalid chapter:verse. In SWORD, Gen 1:9999999 would parse this as
> the last verse in Revelation. We have such fix up code in JSword, but don't
> use it.
>
> In Him,
>         DM
>
> On Aug 6, 2013, at 7:53 AM, DM Smith <dmsmith at crosswire.org> wrote:
>
> > Couple of thoughts.
> >
> > When we only had the KJV versification, it made sense to throw out
> non-KJV references as invalid.
> >
> > With v11n, we have v11ns w/ just the OT and those with OT and NT. There
> are none that have only the NT. Though you'd think that a Greek one would
> have an NT only versification.
> >
> > This explains what you are seeing.
> >
> > There are two things that are needed (which I think are in there):
> > A check to see if the module contains a verse.
> > A check to see if a verse is in the versification.
> >
> > I agree w/ parsing not failing except when unparseable. I do think that
> it no longer complains about chapters and verses that are not in the v11n.
> So it is only an issue w/ book names.
> >
> > Regarding parsing, I think it should use most book names, not just those
> in the v11n. But should it be all? Should it always include the apocrypha
> book names? If a user mistypes a book name should it get a hit on an
> apocrypha or only on the canon?
> >
> > One of the things I think have been needed for a long time is a parser
> that doesn't try to guess the book name. This would be for osisID/osisRef.
> Most references that JSword deals with are encoded within modules.
> >
> > Aside: Today, we do a lenient parse which fails on osisIDs. Upon
> failure, it mungs the osisID and re-parses. If we had an osisID parser,
> we'd reverse this.
> >
> > In Him,
> >       DM
> >
> > On Aug 5, 2013, at 12:42 PM, Chris Burrell <chris at burrell.me.uk> wrote:
> >
> >> Hi
> >>
> >> I'm having a strange behaviour due to how our versifications are
> implemented.
> >>
> >> If I'm looking at the OSMHB module, then looking up Mat 1 gives me a
> NoSuchKeyException
> >> If I'm looking at the TR module, then looking up Gen.1 gives me an
> empty passage.
> >>
> >> STEP shows a message saying the module doesn't cover the passage in the
> latter case. The former case is tricky, since the reference could be
> anything at all...
> >>
> >> What are your thoughts? Ideally, I'd want to say "invalid" when the
> reference is something completely unparseable. However if it's simply not
> present in the versification, then I'd probably want to say that module
> doesn't cover the passage.
> >>
> >> We get similar issues for Apocryphal books. Any thoughts?
> >> Chris
> >>
> >> _______________________________________________
> >> 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/20130806/2fd09cb5/attachment.html>