[sword-devel] French versification schemes
DM Smith
dmsmith at crosswire.org
Sat Jun 10 07:30:14 MST 2017
Circling back around to this.
There are two parts to the problem:
1) AV11N
2) Mapping to KJV
AV11N:
In JSword, we don’t yet have a form for external AV11N. There are two parts to this: Books and Verse/Chapter counts. Books have presence and ordering. Chapters have verse counts, answering "What is the highest verse number in the chapter?” JSword and SWORD differ a bit on internal representation of chapter counts, but the biggest difference is that we have one representation for the OT and one for the NT, allowing reuse of a testament’s chapter counts. The other is a slight difference where we don’t have a separate array of the counts of chapters.
In canon.h there is:
struct sbook ntbooks[] = {
{"Matthew", "Matt", "Matt", 28},
JSword doesn’t have the chapter count, 28, present in its book order array.
The canon.h vm[] array is:
int vm[] = {
// Genesis
31, 25, 24, 26, 32, 22, 24, 22, 29, 32,
32, 20, 18, 24, 21, 16, 27, 33, 38, 18,
34, 24, 20, 67, 34, 35, 46, 22, 35, 43,
55, 32, 20, 31, 29, 43, 36, 30, 23, 23,
57, 38, 34, 34, 28, 34, 31, 22, 33, 26,
// Exodus
22, 25, 22, 31, 23, 30, 25, 32, 35, 29,
10, 51, 22, 31, 27, 36, 16, 27, 25, 26,
36, 31, 33, 18, 40, 37, 21, 43, 46, 38,
18, 35, 23, 35, 35, 38, 29, 31, 43, 38,
The difference for JSword is that we use a doubly nested array:
/* protected */ static final int[][] LAST_VERSE_OT =
{
// Genesis
{
31, 25, 24, 26, 32, 22, 24, 22, 29, 32,
32, 20, 18, 24, 21, 16, 27, 33, 38, 18,
34, 24, 20, 67, 34, 35, 46, 22, 35, 43,
55, 32, 20, 31, 29, 43, 36, 30, 23, 23,
57, 38, 34, 34, 28, 34, 31, 22, 33, 26,
},
// Exodus
{
22, 25, 22, 31, 23, 30, 25, 32, 35, 29,
10, 51, 22, 31, 27, 36, 16, 27, 25, 26,
36, 31, 33, 18, 40, 37, 21, 43, 46, 38,
18, 35, 23, 35, 35, 38, 29, 31, 43, 38,
},
We’ve maintained the comments as the same and the number of elements on a line the same, allowing us to diff the corresponding canon.h for verification.
The practical difference is that we use sizeof to get the chapter count rather than a lookup in a 2D book array.
Looking at Костя’s file his representation, while easy to generate from a module’s original OSIS xml is too verbose. It has one XML element per verse. We only need chapters/book and verses/chapter. The above representations are sufficiently compact. The python script that is used to generate the canon file can be adapted to create any format we choose.
The format we choose should be:
easy to read
easy to parse and convert into the internal format needed
compact
The book names being standardized to OSIS is sufficient.
The array of chapters having 10 per line make it easy for people to read.
I’ve also spaced it so commas line up even for chapters with over 99 verses.
I’d suggest JSON over XML as it can represent arrays in a more compact form.
E.g. (off the top of my head, can be otherwise)
KJV = [
[
[ "Gen",
[
31, 25, 24, 26, 32, 22, 24, 22, 29, 32,
32, 20, 18, 24, 21, 16, 27, 33, 38, 18,
34, 24, 20, 67, 34, 35, 46, 22, 35, 43,
55, 32, 20, 31, 29, 43, 36, 30, 23, 23,
57, 38, 34, 34, 28, 34, 31, 22, 33, 26
]
],
[ "Exod",
[
22, 25, 22, 31, 23, 30, 25, 32, 35, 29,
10, 51, 22, 31, 27, 36, 16, 27, 25, 26,
36, 31, 33, 18, 40, 37, 21, 43, 46, 38,
18, 35, 23, 35, 35, 38, 29, 31, 43, 38
]
],
... rest of OT ...
],
[
... NT spec ...
]
]
Of course we could come up with a proprietary format. E.g.
KJV 29 27
Gen 50
31 25 24 26 32 22 24 22 29 32
32 20 18 24 21 16 27 33 38 18
34 24 20 67 34 35 46 22 35 43
55 32 20 31 29 43 36 30 23 23
57 38 34 34 28 34 31 22 33 26
Exod 40
22 25 22 31 23 30 25 32 35 29
10 51 22 31 27 36 16 27 25 26
36 31 33 18 40 37 21 43 46 38
18 35 23 35 35 38 29 31 43 38
I favor a standard format over proprietary. For JSword, if standard, we'd use a 3rd-party parser. But writing a parser is fairly trivial.
Response on standardizing mapping file next.
In Him,
DM
> On Oct 2, 2016, at 6:13 AM, Troy A. Griffitts <scribe at crosswire.org> wrote:
>
> Thanks for bringing this up Dominique. Костя, what do we need to move forward into this next release?
>
> I also, with you, would like to have one common format shared with JSword to store our mappings. Do you have any comments about their format? Is it something we should simply adopt and write a generator utility to our .h mappings? Does JSword's format include anything we don't support? or vice versa?
>
> Troy
>
>
>
> On 10/02/2016 09:08 AM, Dominique Corbex wrote:
>> On Sun, 24 Jul 2016 01:45:00 +0300
>> Костя Маслюк <kostyamaslyuk at gmail.com> wrote:
>>
>>> It is still important to place all we have for av11n schemes and mappings
>>> in one place.
>> I agree..
>>
>>>> At http://crosswire.org/~kalemas/work/v11nmapping there are examples
>> I'd like to submit sword mappings to these French versification schemes
>> before the next release of Sword.
>>
>> So, I just need to write 3 Bible xml files with all the <OsisIDs>
>> related to these schemes and the mappings <refMap> at the end, and run:
>> $ python refMap2cpp.py Bible.<versification>.xml
>>
>> and then add the resulting code to the associated .h file.
>>
>> Am I right?
>>
>> In Christ
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20170610/863c99a6/attachment-0001.html>
More information about the sword-devel
mailing list