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

Reply via email to