[sword-devel] verse parsing

[Troy A. Griffitts]

>> 	I've been working on providing a VerseKey key interface for traversing
>> modules like the LXXM:
> 
> Is this really about v11n in Sword?

Hi Martin!  Yes.  This has been the way we've planned to implement v11n 
in sword for the past year.  You can see all the previous emails in the 
archive and current summary at the end of http://crosswire.org/~scribe/todo/


> If you look at the printed LXX, you will note that in some parts it is divided 
> into two sections. Each represents a different textual tradition (A=Codex 
> Alexandrinus, B=Codex Vaticanus). JoshB basically has the standard text where 
> there is no separation, and the Codex Vaticanus text from the divided 
> passages, and JoshA only has the Codex A. text of these passages.
> 
> So the solution in this case is not to allow for non-OSIS booknames like JoshA 
> and JoshB, but to encode the module correctly. That's what I am planning for 
> the upcoming (if we get permission) MT-LXX-parallel module. If you get Josh 
> 15, every verse will contain a table, the first column being codex A and the 
> second one being codex B. So for the booknames, no modification is required 
> as the current module structure is already a workaround (from the CATSS 
> files).

This is good information!  Thank you.  I'm still not sure what you are 
suggesting.  Are you suggesting merging the 3 chapters in JoshA with 
JoshB?  And somehow provide variant toggling?  I looked at JoshA and 
tried to compare it to JoshB, but I couldn't find similaries.  Maybe you 
can.


> We should not mix v11n with General Book handling! v11n is about Bibles only.

I'm not sure your purpose behind this general suggestion.  Maybe you can 
explain further, but it seems wrong to me for at least 2 reasons.

1) other things besides Bibles need versification translation, e.g. 
Josephus, which has 2 dominant v11n schemes.

2) You might consider re-reading all the email where we've discussed 
this implementation and also the suggested outline in the todo.  The 
intent is to use the genbook driver with its index scheme for storage, 
which nicely supports any level of BCV and expose the module with the 
same VerseKey interface, so clients of the engine use it just the same 
as any other Bible (if it is a Bible).  Clients won't know the 
difference, just like they don't know if a module uses the RawText or 
zText driver.


> The sub-verse issue: My suggestion would be to implement an internal, absolute 
> reference scheme which is not exposed to the outside. This would translate a 
> reference from a given v11n system to an integer number, giving the 
> possibility to map different v11n schemes together. B, C and V would all be 
> strings, and frontends could use VerseKey.nextChapter() or the like to 
> iterate through them and could use the translator object to map them between 
> modules.

Translating between schemes hasn't been brought up in any emails 
recently.  This is an entirely different problem.  We have had some 
discussion as to the interface we'd like to expose.  I believe it would 
be a little less intrusive than requiring a user to manually do a 
translation.  If I remember correctly, past discussions involved a key 
knowing what v11n scheme it was, and if you set, say the NASB with a 
VerseKey{KJV} it would do any translation necessary.  If a user manually 
wanted to do conversions, this is obviously still an option by using 
keys directly: verseKey{NASB} = verseKey{KJV}.

The interface isn't so much the issue.  It's the storage of conversion 
tables and a super-fast implementation that we need to consider.

OSIS, at the last meeting, did define a preliminary format for saving 
conversion information, so we'll need to, at least, import this data format.


> I can explain more if you like, and I'd be curious to see if I can help with 
> this as well.
> 
>>From a BibleTime developers perspective, I'd say: We don't care if you break 
> the current VerseKey/Treekey structure. Let's make a real cool and clean 
> implementation, even if we have to choose a completely different 
> layout/design. We'll adapt to that as soon as it is released. Good v11n 
> handling is FAR more important than backwards compatibility here.

I am worried about an extreme shift (supporting other than int) to 
support a very small minority of texts.  My worries may be unfounded, I 
understand.  For books like Josephus and the LXX, I think it's best to 
slowly add functionality like parsing and nicer display of keys.  Then, 
if everything works really great, maybe it might be an option to use all 
Bibles with the same mechanism.

Thanks for giving me Bibletime's perspective.  It is very appreciated.

	Blessings,
		-Troy.


> 
> mg
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page