[sword-devel] OSIS Users Manual considered confusing

[David Haslam]

Just some brief comments about OSIS and Go Bible.

The fact that Go Bible Creator supports only the container version of
chapters & verses (not the milestone version) is historic.
That's how we inherited the project since Jolon Faichney first created and
developed the Go Bible software.

Go Bible is a simple Bible text viewer, not a fully-fledged Bible study
program. 

How Jolon made use of simple OSIS XML is documented in
http://gobible.jolon.org/developer/OSIS/OSIS.html

We have done virtually no development in the OSIS class (Java) for Go Bible
Creator, choosing instead to focus on the fact that Go Bible Creator became
capable of directly processing USFM files after the valiant work by Dirk K.
in 2009/2010, and continued by Dan H. during 2010.

Whenever I make a Go Bible edition for any translation, I normally choose
either USFM (if the files are available) or making a ThML file (if they are
not). I have tools available to convert a VPL file to ThML.
If I don't have either VPL or USFM, then I decide which is simpler to opt
for, after examining how the translation was supplied or obtained. 

The simple ThML needed to successfully make a Go Bible is documented
inhttp://gobible.jolon.org/developer/ThML/ThML.html

Little has been done on improving the ThML class (Java) for Go Bible
Creator. It was adequate for it's purpose, and not much has changed since.

When Daniel joined us, he was already working on enhancing Go Bible Viewer
(aka GoBibleCore) to work on touch screen only phones. All this is
well-described in this wiki page:
http://crosswire.org/wiki/Projects:Go_Bible/SymScroll

The new features in SymScroll are implementations based on USFM as the input
file format. Little to no consideration has been given to enabling either
OSIS or ThML to be used for the new features available in the SymScroll
branch.

Personally, had I been working from "scratch" on the CzeCSP translation, I
would have devoted all my efforts to converting the work to USFM format, and
then using our existing tools to obtain the OSIS XML file required for a
full-featured SWORD module.  

Despite all the weaknesses and bugs that I and others have encountered in
our process to convert USFM to OSIS by various Perl scripts, we are still
convinced that this is far more likely to minimize difficulties and avoid
issues that would arise by trying to make OSIS directly from legacy format
files such as MS Word or HTML web-pages.

The advent of USX as an XML schema to support UBS Paratext will improve
things too - it will ensure that the USFM files are cleaner and easier to
convert to valid OSIS XML. But that's part of what's now on the horizon. 
Chris and others are looking into how this can help us improve our software
tools.

Hope this helps to clarify the situation.

Best regards,

David 

--
View this message in context: http://sword-dev.350566.n4.nabble.com/OSIS-Users-Manual-considered-confusing-tp4441335p4441587.html
Sent from the SWORD Dev mailing list archive at Nabble.com.