[sword-devel] French versification schemes
DM Smith
dmsmith at crosswire.org
Sun Jun 18 14:40:19 MST 2017
Good idea. I’ll look into how we can markup an OSIS text with a mapping to the KJV. If we can do that, then the form that SWORD/JSword needs is merely a form that the two can agree upon.
DM Smith
> On Jun 18, 2017, at 3:45 PM, Костя Маслюк <kostyamaslyuk at gmail.com> wrote:
>
> 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 at crosswire.org <mailto:dmsmith at 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 at crosswire.org <mailto: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 <mailto: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 <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 <mailto:sword-devel at crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/sword-devel <http://www.crosswire.org/mailman/listinfo/sword-devel>
>> Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org <mailto:sword-devel at crosswire.org>
> http://www.crosswire.org/mailman/listinfo/sword-devel <http://www.crosswire.org/mailman/listinfo/sword-devel>
> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> 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/20170618/d7e5660a/attachment-0001.html>
More information about the sword-devel
mailing list