[sword-devel] OSIS feature support and questions

[DM Smith]

On 10/02/2009 03:06 PM, Matthew Talbert wrote:
>>>   I thought there was a long discussion about
>>> this previously and we discovered that there was indeed support for
>>> this, just the OSISHTMLHREF filters needed updated to output something
>>> for it. As of 1.6.0, the filters have been modified to output sword://
>>> style links for these references, which works in Xiphos and BPBible
>>> (which are the only ones using these filters as far as I know).
>>>        
>> Is the code to handle it part of Xiphos and BPBible? or is it part of the
>> SWORD engine? (If so, please point me to the file and line.)
>>      
> Well, we handle the sword:// references in Xiphos, but they are
> created in the filter. See osishtmlhref.cpp starting in L307. It
> appears all that is being done is that tag.getAttribute("osisRef")
> returns the entire reference, which is then split on ':' to get the
> work and reference. It seems fairly straightforward.
>    

It "seems" straightforward.
Does it handle "self"? (Which will be in dictionaries.)

Does it handle Bible.KJV:reference or Bible.ref-system.work:reference? 
(I.e. where the workID is not merely the name of the module but contains 
other info?) At least it should then split on '.' and take the last part.

Does it handle all valid osisRefs? E.g. 
osisRef="ESV:Matt.1.1-Matt.2.3,Gen.1.1" (discontiguous range)


>    
>> Short of that I'd expect routines to give back the parts (work, v11n,
>> category, grain, reference, ...) of an osisID.
>>      
> Well, it's just splitting on ':' so I guess it wasn't considered
> necessary to make it any fancier.
>
>
>    
>>>   <reference osisRef="ISBE:MIZRAIM">Mizraim</reference>
>>>
>>> does exactly what you would expect.
>>>        
>> That's good. Is this true of all front-ends (other than those based on
>> JSword, which does not handle it.)
>>      
> No, the front-ends would have to a) be using the HTMLHREF filters, and
> b) implement support in their application for following these links.
>
>    
>>> Anyway, this works fine for me in Xiphos, so I guess I'm unclear where
>>> the lack of support is.
>>>
>>> Matthew
>>>
>>> PS It looks like these links cause a segfault in BibleTime, so
>>> apparently they don't have support for this in their filters after
>>> all. Still, it's a filter issue, not an engine issue.
>>>
>>>        
>> The filters are part of the SWORD engine. I'm aware that at least one
>> frontend has their own render filters. But they are or were based on the
>> filters in the SWORD engine.
>>      
>    
>> I think that common handling of lookup should be pushed into the SWORD
>> engine.
>>      
> This is certainly a different perspective than has been shared before. See
> http://www.crosswire.org/pipermail/sword-devel/2008-November/029892.html
> http://www.crosswire.org/pipermail/sword-devel/2008-November/029724.html
> http://www.crosswire.org/pipermail/sword-devel/2008-November/029762.html
>    
I remember that. And since I'm not much of a SWORD programmer, I didn't 
say much.

My point: By having a workable mechanism in the engine that is updated 
as needed to handle more and more of the osisRef spec, more front-ends 
can share the fruits of labor.

Troy and Chris stated, in those email threads, it is essentially a 
front-end issue. I won't argue that. But it is one that has to be solved 
by each front-end. It would be nice for the solution to be done once and 
shared.

In Him,
     DM