[sword-devel] Which is preferred in OSIS Bibles? bookGroup or x-testament?

[Greg Hellings]

On Mon, Feb 13, 2012 at 3:08 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
> 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

I had this working flawless for OSIS modules (again, provided the
module had been valid when imported). No, it didn't work completely
for ThML or GBF or other types of modules, but it worked. I even had
it working great for both those modules with AND without the excess
content - all I needed to do was properly parse the output of the
testament header where the import SVN value was stored for osis2mod
imported content. That logic is not difficult, to be sure, it just
never was implemented.

And, of course, my patch that even made OSIS content reasonably
well-formed for the vast majority of our modules was never landed, nor
was I given permission to land it myself.

That is the only reason mod2osis is "abandon-ware".

Yes, to be fully compatible with our entire module set would require
expansion of the GBF and ThML filters. But that's not addressing the
basic |: osis2mod -> mod2osis :| process (pardon the musical notation
for repeat there). That worked with my patch. Flawlessly.

--Greg


>
>
> 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<dmsmith at 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page