[sword-devel] New Windows SWORD GUI / a design

[Chris Little]

Simon,

(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