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, Костя Маслюк <kostyamasl...@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" <dmsm...@crosswire.org > <mailto:dmsm...@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 <scr...@crosswire.org >> <mailto:scr...@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 >>> Костя Маслюк <kostyamasl...@gmail.com <mailto:kostyamasl...@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@crosswire.org >> <mailto:sword-devel@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@crosswire.org > <mailto:sword-devel@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@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
