The issues, if I can remember correctly, are deeper than the utility
mod2osis, and adding lots of checks in mod2osis to account for all the
other issues is only putting a bandaide on the problem.
mod2osis should be a very simply utility. It's logic should be:
set output format to OSIS
grab requested module
dump a header from .conf data
output module intro if necessary
loop through all entries of the module {
output book intro if necessary
output book <div ...> if necessary
output chapter intro if necessary
output <chapter...> if necessary
output <verse ...>
output entry content
}
output footer
One of the reasons this logic no longer works (it mostly did at one
point in time), is that we have some modules which store book <div ...>
<chapter ...> and <verse ...> in the module, and some that don't.
The inconsistency is what makes writing mod2osis complicated now. More
than I want mod2osis to work, I want us to be consistent in how we
create modules.
An aside note:
We do all sorts of non-OSIS things when importing OSIS modules. These
are to help real-time output when using the engine. The RenderFilter
OSIS->OSIS sounds redundant, but this filter is what changes internal
SWORD OSIS back into best practice public OSIS.
Troy
On 02/13/2012 07:51 PM, Greg Hellings wrote:
On Mon, Feb 13, 2012 at 12:36 PM, DM Smith<dmsm...@crosswire.org> wrote:
On 02/13/2012 01:16 PM, David Haslam wrote:
That being the case, it prompts the question,
Why does mod2osis use type="x-testament" ?
I'm not really sure what the utility of mod2osis is at all. The transforms
of ThML and GBF to OSIS are very incomplete. It is best when processing an
OSIS module. Every now and then there are discussions here regarding some
shortcoming of this utility. At this point, I think it is abandon-ware.
This is only because I have never been given commit privileges to it.
I have made extensive changes and updates to it and submitted patches
multiple times but those have always been ignored. I've also
completely rewritten it two separate times to use something other than
a single monolithic for-loop, and both of those times I have been
ignored.
Ergo, four times I have achieved mod2osis -> osis2mod -> DC ad nauseum
on the KJV 2006 module, including OSIS validation at each step and
verification that both the plain text output and the HTML rendered
output was identical between the round trip. Each time that
accomplishment has been ignored. The round-trip produces validation
errors when the original module import has errors in it (there were
some</lg> elements without corresponding<lg> elements in one or two
modules), but when I've reported those I got a, "Thanks, that's great,
but we can't do anything about it" response because we lack the
original OSIS files.
Thus it is only abandon-ware because I was never given commit
privileges to it despite repeated requests (or, if I was given write
privileges it was never told me). I have since deleted the git and bzr
branches where I was working on mod2osis because I gave up hope of
ever being allowed to adopt it.
--Greg
_______________________________________________
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
_______________________________________________
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
