[jsword-devel] Wrapping non OSIS-ID in next cell

[DM Smith]

Ignoring the JSword added headings, but looking only at the "missing" verses:

I was looking at the code that does the parallel view. It calls getOsisIterator for each Book, for the Key that is requested. Those iterators don't produce contain parallel arrays.

The valuable part of getOsisIterator is that it can cache the requested content. In any solution, this needs to be kept.

So a few choices:
1) Have a special, internal, JSword specific, this verse is missing content. E.g. <verse osisID="real osisID" type="x-missing"/>. Front-ends could handle this as they like.
2) Change the return of the iterator to return keyed content. Then the routine would advance through each of the iterators handling missing content as it sees fit. It would have a row for each key, where that key has content in at least one module.
3) Don't use an getOsisIterator, but rather request a keyed map of OSIS. Iterate over the Key and pull the content out of the cache.

It'd be nice if this would handle the linked verse problem, too. This occurs when the module has
<verse osisID="Matt.1.1 Matt.1.2 Matt.1.3" n="1-3">verse content of Matthew 1:1-3</verse>
Today, looking up and displaying this causes it to appear 3 times.

In Him,
	DM

On Sep 9, 2012, at 6:51 AM, Chris Burrell <chris at burrell.me.uk> wrote:

> Agreed. I think there are two issues... One is with the headers that JSword adds as you read the file in. The other with the missing verses. One of the suggestions from Tyndale is that it wouldn't take too long to amend the modules to have those verses in there if that makes sense. For example, I'm getting the impression the "missing" verses in Acts in the ESV are actually present with 0-content. 
> 
> The other option is that we can try and track the "current reference" as best we can. Store the anything that seems ahead of time in memory until we output it. That would add a bit of a performance overhead (parsing of keys) and a bit of memory overhead, but I'm guessing not that much in the grand scheme of things. 
> 
> Chris
> 
> 
> On 6 September 2012 23:33, DM Smith <dmsmith at crosswire.org> wrote:
> Chris,
> A module only has verse content. In order to have module, testament, book and chapter introductions we have a notion of testament 0, book 0 and verse 0, using SWORD notation. Actually, JSword has special books for module and testaments. This is new to JSword in the av11n work.
> 
> I think the title was verse 0 of the chapter you were grabbing. It is an open question in my mind what we do with verse 0. I think the consensus is that we don't show verse 0 to the end user but we allow it to be input. For that reason it was not wrapped in a verse element.
> 
> When the user requests a chapter, they'll get verse 0, if present in the module. I think you'd find that if you had a module with some verses missing and another with other verses missing in the same chapter, that few of the verses line up.
> 
> My guess is that it is using two or more iterators and assumes that they are parallel arrays. This is not a good assumption. It might very well be my code, my bad.
> 
> In Him,
>         DM
> 
> 
> On Sep 6, 2012, at 2:15 PM, Chris Burrell <chris at burrell.me.uk> wrote:
> 
> > Hi all
> >
> > I'm having a situtation where I'm using multiple Book objects in BookData. Unfortunately, because there are elements like "title" that are not wrapped into any verse, the cells get out of sync (see example below).
> >
> > I suggest to mitigate that, we insert any element without a key of osisId in the same cell as the following osisId key. This would resolve the issue below. It may however not resolve the issue where some modules do not have a Key, but I think that is catered for elsewhere?
> >
> > Chris
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/jsword-devel/attachments/20120909/0f315362/attachment.html>