[sword-devel] osis2mod problems

DM Smith dmsmith at crosswire.org
Sat May 23 06:09:36 MST 2009


The bug is now fixed in SVN.

On May 19, 2009, at 8:32 AM, DM Smith wrote:

> I've verified that this is a bug and entered a bug report. I'm  
> working on a fix.
>
> I also added a feature request for handling comments.
>
> In Him,
> 	DM
>
> On May 18, 2009, at 6:55 PM, DM Smith wrote:
>
>>
>> On May 18, 2009, at 12:06 AM, Ben Morgan wrote:
>>
>>> osis2mod doesn't handle comments - is this known/cared about?
>>
>> So far it does not know about comments. It would be a nice  
>> addition. I think the behavior should be to skip all content (i.e.  
>> exclude it from the module)from an opening <!-- to a closing -->.  
>> While this does not match the xml spec, it probably would be  
>> adequate. The xml spec does not allow for nesting comments in  
>> comments. I suppose that we could also look for a --> and if we are  
>> not in a comment that it would be an error.
>>
>>> osis2mod currently assumes that a <div eID="..."> that appears  
>>> outside a verse, but inside a chapter is a chapter-closing div  
>>> (presumably because that is how commentaries close chapters).
>>
>> I don't think it should. Osis2mod has a stack that it uses to pair  
>> start tags with end tags. Basically, it should, upon finding a </ 
>> div>, consult the stack to see what the opening element is. If it  
>> is a chapter div, then it closes the chapter.
>>
>>
>>> This breaks the pre-verse logic when you have this type of thing  
>>> (inside a chapter):
>>> <div type="section">
>>> <title>Genesis 1.1 title</title>
>>> <verse osisID="Gen.1.1" osisRef="Gen.1.1">Verse 1 text</verse>
>>> </div>
>>
>> This closing div should be matched, via the stack, with <div  
>> type="section">.
>>
>>> <div type="section">
>> The intended behavior of osis2mod upon seeing an opening tag  
>> between two verses is to mark it as starting pre-verse material.  
>> This <div type="section"> should be attached to the beginning of
>>> <title>Genesis 1.2 title</title>
>>> <verse osisID="Gen.1.2" osisRef="Gen.1.2">Verse 2 text</verse>
>>> </div>
>>>
>>> This should put Genesis1.2 title in Genesis 1:2. However, it  
>>> currently puts it at the end of Genesis 1:1 due to the closing div.
>>
>> So, if it doesn't do what it should do, the way it should, then it  
>> is a bug and needs to be fixed.
>>
>>>
>>> I have fixed two other problems today with osis2mod:
>>> 1) due to typo, the default storage was LZSS compression
>>> 2) pre-verse material which was handled was not matching the sID  
>>> with the eID
>>
>> Thank you so much.
>>
>>>
>>> I wonder if we need to release some of the important utilities at  
>>> different times from the engine. (i.e. have a osis2mod release  
>>> once problems are fixed with it)
>>
>> I can go both ways on this. It is important that osis2mod builds  
>> modules that can be read by a particular version of the SWORD  
>> engine. Even with SWORD 1.5.11, osis2mod built modules that would  
>> work with 1.5.9 front-ends. The current osis2mod requires a 1.6.0  
>> engine.
>>
>> As to bug fixes, my recommendation is almost always to use SVN  
>> head. The only exception to this was during the development of  
>> av11n, which broke osis2mod for a while. In that case, getting  
>> osis2mod from head and building against 1.5.11 would have been great.
>>
>> I realize that this is generally beyond Windows users. And most  
>> users of a distribution expect the code there to be current with  
>> the latest release, even though that has not been true. Perhaps the  
>> old days are gone, where recommending to Linux users to build  
>> something is typical.
>>
>> I think we need to start a regression test case. Perhaps the  
>> following would work. An OSIS xml input file, like above that does  
>> not have real text, but gives a suitable placeholder. And a raw  
>> file built from the input. I think we can stick with either NT or  
>> OT references so that we only have one file.
>>
>> Running it with DEBUG compiled in and with the -d 2 flag to produce  
>> verse milestones would help identify where the problems occur.
>>
>> Then as someone reports a problem, it can be added to the input  
>> file, and the output file could be updated too. The regression test  
>> case would not catch unrepresented, problematic constructs, but it  
>> would prevent regression due to either improvements to osis2mod or  
>> to the SWORD engine that it uses.
>>
>> I've got a start of such a file and we have a spot on the wiki for  
>> it too. Now to meld them together.
>>
>> In Him,
>> 	DM
>>
>>>
>>> God Bless,
>>> Ben
>>> -------------------------------------------------------------------------------------------
>>> Multitudes, multitudes,
>>>  in the valley of decision!
>>> For the day of the LORD is near
>>>  in the valley of decision.
>>>
>>> Giôên 3:14 (ESV)
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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




More information about the sword-devel mailing list