|
OK, I hear two votes for me to continue
generating OSIS files, so I won't rip that part of the code out of
Haiola and reclaim the server space. Instead, I'll help put OSIS
on life support in light of the rather inconvenient disappearance
of http://www.bibletechnologies.net by offering
http://eBible.org/osis/ as a stable point of documentation
distribution and http://ebible.org/osisCore.2.1.1.xsd as a stable
home for the OSIS schema.
Contrary to the impression some have of me, I don't hate OSIS. I do see better ways to encode Scripture for most uses, but unless The Sword Project were to decide to move away from OSIS as a supported import format and OSIS-like fragments as part of the internal module structure, I don't want to see OSIS die. That is because I like The Sword Project for all of its virtues. The Sword Project is a useful set of free and open source Bible study programs, some of which I use regularly. The World English Bible and The Sword Project kind of grew up together. Obviously, The Sword Project isn't the only similar project, but it is good, and still improving. I have just modified Haiola to renumber Psalm 151 as chapter 1 of AddPs when generating OSIS files. That chapter number remains the same (151) in the USFM source. I have regenerated the WEB and WEBBE OSIS files with that change, and another typo correction. The in the files I generate, the USFM and USFX files are equivalent, and equally reliable, always generated from the same source (which can be either USFM or USFX), and round-trip tested in the conversion. They both contain all available text and formatting for the Bible or Scripture portion they represent. The OSIS file is always generated from the USFX file, but may omit some noncanonical USFM/USFX features that The Sword Project does not support. The only significant difference between my modified OSIS and pure standard OSIS is that character styles and Word of Jesus formatting stop and restart at all verse and paragraph boundaries, like USFM and Paratext require. Since the internal Sword format does the same thing, this is not an issue at all for Sword use. This sort of modified OSIS still fully validates against the OSIS schema. The USFX to OSIS conversion in Haiola has been tested against 305 real world Scripture projects, and generates valid OSIS from every one of them. It maps all USFM 2.4/USFX markers to appropriate OSIS markers that are used in actual reader's edition Bibles and that have corresponding support in the Sword Project. It also supports extensions to USFM (which are part of standard USFX) to encode Strong's numbers and morphological data. If Sword utilities can't handle these OSIS files for input, then they can't handle OSIS. Period. When I wrote Haiola's OSIS conversion, no other acceptable USFM/USFX to OSIS conversion existed. Currently, usfm2osis.pl is close to acceptable. It worked on one of two test cases I gave it, but failed miserably on one. I didn't try all 305 of my projects on it. (I did alter the pointer to the schema to point to ebible.org instead of www.bibletechnologies.net, so that wasn't the cause of the failure.) So... take your pick. You may choose to use the OSIS files I generate with Haiola (or generate some yourself, since Haiola is free and open source). Or you may improve usfm2osis.py and use it. Either way, I recommend that proprietary extensions and tweaks to the modified OSIS format you import as Sword modules be created in a separate step, just in case others take advice given previously that OSIS be used to author Sword Bible modules. (That might actually happen, although the best and most-used Bible translation editing tools use USFM.) Either way, it is no skin off of my nose. May God bless you.
|
_______________________________________________ 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
