This is exactly the thing I was thinking about this weekend! I propose a TWiki space already dedicated for v11n as a perfect place to put such a document together.
Take a look here http://www.crosswire.org/ucgi-bin/twiki/view/Swordapi/AlternateVersification
I'll also be more than happy to contribute to it!
Greetings,
Christopher.
----- Original Message ----- From: "DM Smith" <[EMAIL PROTECTED]>
To: "SWORD Developers' Collaboration Forum" <sword-devel@crosswire.org>
Sent: Saturday, April 23, 2005 8:51 PM
Subject: Re: [sword-devel] How about the OT's standard versification at Sword ?
Since this is a developers mailing list, I would like to suggest that we create a whitepaper on v11n that outlines the goals, the scope, the challenges/caveats and the high level design and perhaps low level design that Sword will use. I think that such a paper can minimize this frequent thread. I realize that this may need to wait until 1.5.8 is released.
To be transparent, my motivation is to start work on it in JSword, to minimize these long and mostly unproductive threads, IMHO (I think the rest of the world calls them flame wars) and to participate in the design of the mechanism.
(These are not necessarily correct or complete, but let me put out something as a starting point)
Goals:
1) Accurately markup in the module the Book/Chapter/Verse (bcv) according to the published Bible, using an authoritative, original source.
2) Create a lookup mechanism where by one can ask for a verse by any valid bcv in the module. This would allow for the richness of the current mechanism of specifying the bcv, including but not limited to OSIS forms of the book, abbreviated forms of the book, alternate forms of the book, locale specific forms of the book, ...
3) Facilitate parallel rendering of different v11n. This will require the ability to map passage to passage between different v11n. (I deliberately did not say verse here as verse boundaries may differ)
4) Facilitate red-lining of parallel passages in the same language. (Given a base, show the markup of the changes necessary to create another passage)
5) Semi-backward compatible. Earlier versions of the SwordAPI will be able to access verses from modules with new v11n as represented in canon.h today.
A goal I would like to see, but may be too far out of scope.
6) a general purpose mechanism that can be extended to any book that can be rendered hierarchically, e.g. Work/Section/Chapter/Paragraph/Sentence... where the hierarchy is particular to the work.
The scope: New bible modules and new version of API.
Challenges/caveats:
1) performance should be on par with existing modules based on canon.h.
2) new modules are not backward compatible with older SwordAPI. (Perhaps they are partially compatible?)
3) old modules are compatible with new Sword API.
Design:
I have heard that there have been a few experiments so far with varying degrees of success. Can people share what they were and what the strengths and shortcomings of them were?
_______________________________________________ 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
