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. Anyone have a better suggestion for how it could be handled? --Greg _______________________________________________ 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
