[sword-devel] French versification schemes

Костя Маслюк kostyamaslyuk at gmail.com
Sun Jun 18 12:45:04 MST 2017


Having one file for canon defnition and mappings is preffered in my point.
Having source(reference) text in that file as well is best.

So would OSIS gurus say whether it is possible to store all data required
to build canon and mappings in valid OSIS document?

As i realize convenience of readable formats my point is still the same. So
i count on some sort of authoritative desision.


10 июня 2017 г. 5:31 PM пользователь "DM Smith" <dmsmith �� crosswire.org>
написал:

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 �� 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 �� 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 �� crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page



_______________________________________________
sword-devel mailing list: sword-devel �� crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
----------- �������� ����� -----------
�������� � ������� HTML ���� ���������&hellip;
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20170618/769e785e/attachment-0001.html>


More information about the sword-devel mailing list