On Wed, Jan 7, 2009 at 11:49 AM, Greg Hellings <greg.helli...@gmail.com> wrote: > On Tue, Jan 6, 2009 at 11:58 PM, Jonathan Morgan <jonmmor...@gmail.com> wrote: >> On Tue, Jan 6, 2009 at 3:08 PM, Jonathan Morgan <jonmmor...@gmail.com> wrote: >>> On Tue, Jan 6, 2009 at 2:51 PM, Greg Hellings <greg.helli...@gmail.com> >>> wrote: >>>>> 4. Bible references from commentaries, etc. use this master versification. >>>> >>>> Then the module creator needs to go through and convert all of their >>>> references to that master versification. Why would we do that when we >>>> can just tell them they have the right to specify a preferred module? >>>> One front-end might decide that the user is free to over-ride that, to >>>> their own possible confusion, but that allows the module creator to >>>> create the module correctly, instead of having to transfer it to a >>>> master versification. Think of how confused a user would be if they >>>> click on a reference that says, "Matthew 3:17" and are taken instead >>>> to their favorite Bible module to the key "Matthew 2:27." Sure, it >>>> might have the right content, but they would think the system was >>>> broken - and I don't blame them. Likewise if I see a print copy of >>>> Matthew Henry's that refers me to Psalm 150:1 and then open SWORD and >>>> want to read the passage there some other day and it has been changed >>>> to Psalm 151:1 because of the differences in Psalm numbering - I'd be >>>> utterly confused and would report invalid module content. >>> >>> Think how confused they would be likewise if the verse didn't say >>> anything like what the commentary said it did. Which would you >>> prefer? >> >> Also, it is quite possible to overcome this by displaying a status >> message somewhere informing the user that it has gone to Psalm 151:1 >> because it is equivalent to Psalm 150:1 in the other versification. >> The status message could even allow them to go to Psalm 150:1 in that >> module if they decide that is really what they want (it isn't, unless >> the module author encoded it badly, but that's besides the point). >> >> The exact form of such a message is open to debate, but the fact >> remains that this way is the only way to overcome both forms of >> confusion (Psalm 150:1 doesn't say what the commentary said, and I >> didn't want to go to Psalm 151:1). > > And I keep advocating that there's lots of untapped potential in the > config files. You could put this together as the front-end developer, > and communicate to the module developer the config entry to have. > From what I understand the engine exposes every entry in the config > file, whether or not its part of the standard SWORD entries. If you > want them to point you to a file that maps out differences between > their version and any other version, you could have them put that > entry in the config file, and then read it into your own front end. > > The question of course, exists as to why you wouldn't make a patch for > the library itself to expose the functionality and conversion to > everyone else's front ends - which is something I think most people > would advocate for. That seem the most simplistic and straightforward > method of doing it to me - though not necessarily the best. Then, > perhaps, include a flag in the config file that indicates something > like "Versification=KJV" or "Versification=Luther" or have some > standards that are built-in to the library for a module which adheres > to a "standard." Then you could have "Versification=Custom" along > with "VersificationSpec=modules/text/ztext/myversion/myspec.conf" and > that conf file could specify that it maps differences between the > module and, say, the Vulgate (or LXX or whatever other one of the > built-in versions the module creator chooses). They could include > omissions, duplications, divisions, combinations, etc. That leaves > the module creator free to use any versification they want, and free > to specify how it deviates from the nearest "standard" if they wish, > for maximum interoperability with other SWORD content. This also > means that backward compatibility is maintained (a big issue, it would > seem, for SWORD modules, for some reason incomprehensible to me) with > modules, by not adding anything to the actual module format itself, > but exposes the issue of mapping between different modules and > versions and versifications.
As to why backwards compatibility is maintained: in general, I would agree with you, but if a person has a CD with lots of modules on or several hundreds of megabytes of modules installed they aren't going to be too happy upgrading them all when they get a new copy of the software. There are two related questions: 1. How do you register the versification of the module? Your way sounds fine to me (it's probably worth at least considering using the format of http://www.ccel.org/refsys/refsys.html). 2. How do you refer to a verse in a particular versification? (again, I would use the extensions to osisref from the above link, probably extending to bible:module.ref to refer to a module's versification). As to why I don't do it: I don't like C++ (though I used to use it a lot) and I have enough work for BPBible to keep me busy for months on end which I view as far higher priority than alternate versification. Jon _______________________________________________ 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
