[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 ���� ���������…
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20170618/769e785e/attachment-0001.html>
More information about the sword-devel
mailing list