On Apr 26, 2009, at 3:52 PM, Jonathan Marsden wrote:
Jonathan Morgan wrote:
I think that the versification should be shown as part of the module
information (after all, it is part of the module configuration), and
possibly it should have a more presentable name or more information
about a versification. If so, this should also be available from the
API in some form, and it seems to me that it would be useful to have
similar things in osis2mod, so that you don't just get:
Available versifications:
KJV
Leningrad
Luther
OK. Are you proposing a new .conf file field, something like:
VersificationDescription=A sentence or two about this
versification ...
which would mean that every module could include this description
info,
and that different modules with the same versification could have
differing VersificationDescription text? This is a simple change, but
is not ideal because of the duplication that results, and the ensuing
difficulty in obtaining a single description per versification system
from the set of installed .conf files.
Or, are you suggesting in effect some sort of "Versification
Information
Database" which is more central to the SWORD library setup, that has
one
(optional) description per versification system, and to which this
information would be added at the time versifications are registered?
I think there are a few different audiences and perhaps different needs:
1) The module developer -- I think such a person needs help
identifying which of the plethora of av11n to use. I'll be changing
osis2mod to output the different versifications. If the developer runs
the module through osis2mod, it will identify if the module contains
references that are not in the requested canon. With the list of
supported ones, they can try another and another, .... until one
works. It might not be "correct" but it will work.
Ultimately, I think we need someone to write an analyzer that will
recommend an alternate versification if one exists and will output a
skeletal definition otherwise. As a diagnostic, it should give for
each versification, what is in the text that is not in the
versification and what is in the versification that is not in the
text. My thought would be to write it for OSIS input.
2) The front-end developer - I think such a person needs to know what
scope of the module given it's versification, at least at a book
level. (I have seen some apps declare that a verse is missing when it
is not part of the module.) If the versification includes the
apocrypha, but the module does not, it should not present those books
as missing. This also applies for NT only and OT only modules.
3) The end user - I don't think it should be at all obvious to an end
user that we are using one versification or another. I don't think
they should care and I think the app should help them not care. If a
user is a theologian, they might have an academic interest. In this
case, they probably know what Luther's or Leningrad Codex or the LXX
versification is by name, though not detail.
With this, I think that 1) is what we have been talking about. If so,
sword-devel and the wiki will have to stand in as a proxy for adequate
tooling. I think it will be sufficient for now.
The latter approach seems more logical to me, but needs more work and
probably requires a (minor) API change to allow an extra optional
parameter to the registerVersificationSystem() method, as well as a
way
to get this info back out again, perhaps a listVersificationSystems()
method. Presumably these strings would be internationalized, so you
get
a locale-appropriate result.
Could each versification system also have a URL associated with it
that
points to a web page describing it in more detail?? Or is that
overkill
-- would it be better to make that "very" optional, by including any
such URLs in the VersificationDescription string concerned?
This kind of API definition and enhancement is IMO something that
should
probably have happened a while ago, early in the av11n design stage,
well before 1.6.0RC* releases started to emerge :) I've not seen the
av11n design documentation, so I have no idea if something like this
was
considered earlier and has already rejected.
The window of opportunity for SWORD 1.6.0 API changes is probably
already closed. So realistically, I'd think this should wait for
1.6.1.
For 1.6.0, adding a few fprintf()s to osis2mod is (IMO again) probably
sufficient?
It will be added shortly. Troy has just committed the routine I need
to finish a first cut at it.
Could someone please propose the one-or-two-sentence descriptions of
each versification system? That would be a helpful step forward with
this, I think.
A good place for this would be: www.crosswire.org/wiki/Alternate_Versification
.
Just add a section that gives:
The name of the versification, the description of the versification
and the date that it was added to the SWORD engine.
In Him,
DM
_______________________________________________
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
