chrislit at crosswire.org
Mon Jan 28 05:58:21 MST 2008
> Being no coder, I can not see how completely new way of encoding Bibles
> should be the right way forward - particularly as it would result in
> a) a possibly long period of breakage/poor implementation on various
> GUIs (+ some GUIs which are perfectly fine now will never get it)
To see new books, it will be necessary to do some work on the GUI end,
but the majority of changes should be API-side, not frontend.
> b) a very different way of creating modules, requiring new tools etc
> (unless I misunderstood you, Chris)
We already have the tools. If you encode an OSIS Bible and run it
through osis2mod, you get a Bible module for the current system. If you
encode an OSIS Bible and run it through osis2gbs, you get a Bible module
for the proposed new system.
The first Bible using the proposed new system was encoded at least 6
years ago. The tools are definitely there.
> c) confuse the user, who often enough is perfectly unaware that his
> particular tradition uses a different scheme (and hence his Bible will
> display not in the ordinary window)
Making an interface from the current (VerseKey-type) Bible system to one
that uses TreeKeys is basically the only piece of work to be done (for
rudimentary support--let's not worry about mapping between systems just
yet). The user wouldn't ever know about internals and shouldn't notice
> There were when I last looked two or three schemes around, but the
> principle was open and flexible - new schemes could easly added by
> programmatically unskilled people like myself.
Significantly, using TreeKeys means you don't have to know about
versification schemes or pick one (unless you need to do mapping).
New modules that use new versification schemes don't require more coding
in the API, they're inherent to the module itself.
More information about the sword-devel