(adding to what Troy just replied...)
I'm really encouraged by your enthusiasm, but would really like for you to cooperate in development with us. I'm not sure if you know this or not, but your diagram could have names changes and be the SWORD engine.
I wasn't aware of that. I searched the crosswire website for some diagrams, but couldn't find one. But if the Sword Engine does already contain a nice architecture, I can better spend my time in programming with the Sword Engine.
One question about the architecture of the Sword Engine: Does each module knows what it contains? In other words: if I have a bible module, does that module 'knows' which bible books it contains, and how much verses in each chapter? The reason I ask is because I don't want a fixed versification scheme, like that of the KJV, which makes it impossible to have the apocryphia or the book of mormon, or what else people want to add as an addiction to the canonical books (I am a protestant christian, so for me the apocryphia not that important, but there are people who consider them as holy). Another reason for wanting to have that information is to only show the biblebooks the module really contains. Can you please tell me if this problem exists, and what is planned to fix it?
Any problem or deficiency in Sword can be fixed if there are people willing to work on it. :)
A Sword module knows its contents as well as an OSIS document does. Currently there is no method available through the API to ask for a list of books contained in a Bible. You would have to load verses and see whether they are empty or not. (Or, a slight improvement would be to add methods that simply check whether a given verse slot is assigned.) But, eventually, we need a method that can be called for a list that is actually stored somewhere in the module.
As I said, OSIS documents are no better. To know which books an OSIS document contains, you must either hope that the creator identified the scope in its header element, or (to be certain) you must read through the whole document.
This doesn't address the alternate versifications/Apocrypha support dilemma you raise. I think if we keep bringing it up, he might finally decide it's time for us to address the issue just get everyone to shut up about it. :) You can see the task list I drew up recently for this issue at http://www.crosswire.org/ucgi-bin/twiki/view/Swordapi/AlternateVersification . (The abundance of my name is just supposed to be a signature showing that I contributed the tasks--I'm not necessarily taking them on.)
This is just for Apocrypha, which are the only additional books we will be integrating into our Bible type. The Book of Mormon, etc. would be categorized as GenBooks and are handled separately (already).
We've even planned for some time to use OSIS as an intermediate markup, like you describe below (currently, the route is src->dest but would like it to be src->OSIS->dest, possibly: we're still hoping to do a proof of principle to see the speed impact and repercussions).
Well, If nobody's working on it, maybe I can give it a try. The only problem is that I have to relearn C++ (last 4 years I've been working with Delphi and assembly, not much with C++), and get used to the wxWindows library and the Sword Engine, but I think that within a month I am as used to C++ as I am now to Delphi.
The route that currently works is src->ThML->dest. I think this still works for almost all source/destination pairs. Of course, we think OSIS is a better choice, so we want to move to that.
Second, we want to remove the need for non-OSIS src types by transitioning all ThML, GBF, and plaintext data to that format. This just makes everything easier to maintain and should help us eliminate bugs more quickly by focusing on a single data markup format.
Thirdly, I think supporting an well described format (like OSIS) with keeping the original file intact, instead of converting to a own module format, has some advantages. It makes the user more or less independant from the module making communitie, they can download an OSIS file, press the 'create indeces' button, and the document can be used
There's nothing to prevent a "convert document" button from being created that imports a document on the user's computer and installs it at a Sword module.
Fourth, OSIS contains a lot of info about the text which is not saved in the module (correct me if I'm wrong). For example, take the CEV OSIS file, some verses are merged, it contains introductions, etc...
Sword maintains all of that.
Last, I want to write a script that automatically converts HTML/ThML/Text documents to OSIS. A friend of me is working on a program and website that can display and print OSIS files in a eastetic form. The idea behind it is that most theological documents on the internet have a very ugly layout (bold typeface, difficult to read background, unreadable font, etc). If that script is ready, tons of theological documents (mostly books) will be available in OSIS format. It would be nonsense if a user needs to wait until a OSIS text is converted to a module, before he can use it.
Basically the same as the argument in point 3. I do agree that users need to be able to handle document import on their side. And once we get a nice, stable set of OSIS importers finished, we will be ready to integrate them into the Sword API to do import within the frontends. This also alleviates much of the server burden from CrossWire by housing module content on 3rd party servers. Enabling users to import OSIS documents has been part of CrossWire's intentions for involvement with the Bible Technology Group since day one.
(As a side note: you might have your friend get in contact with Harry Plantinga of CCEL. They have XSLTs for converting ThML to OSIS already, and I'm sure they would share.)
* I noticed the Sword Engine uses a unicode library. In what way is that compatible with the wxString type of wxWindows?
There would not be any relation between ICU and toolkit-specific string classes like wxString. Sword gives you strings encoded in either UTF-8 or Windows Codepage 1252. ICU gets used behind the scenes for stuff like Troy mentioned.
Now, if you wanted, your application could also make use of ICU directly for conversion of strings to UTF-16 or whatever wxString uses internally. And ICU provides many other things that we don't use in Sword, but that you could use directly.
--Chris
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
