[sword-devel] OSIS feature support and questions

[Troy A. Griffitts]

Yeah yeah,  I know we need more support for everything.... :)

It is largely a frontend issue on what to do with the data, but the
engine could make it easier to know what the data is (as DM has pointed
out).  I'd like maybe an SWMgr::parse method that would return
module/key pairs in a ListKey somehow.  Dunno.  Please don't think we're
abandoning supporting more stuff.  It's just a matter of priority and
interest.  Of course I'd like to see everything supported better.  We're
still working on getting the long sought av11n support to the end user
and actually have any useful modules using it.  I suspect if we get some
useful modules which have advanced <reference> entries, that would be a
great motivator to get something in the engine to assist frontends to
look these things up.  But, as this conversation has pointed out, the
feature in the engine also motivates module dev.  So we are kindof in a
motivational catch22 :)

Anyway, please don't think we've abandoned the idea of making things
easier for frontends.  When one implements a feature, it is often eye
opening for me to see how they've done it and what the need was that
prompted it.  This sometimes leads to the _lifting_ of the ideas and
even sometimes part of the impl into the engine. :)

Thanks for the insightful discussion and suggestions.

Troy



DM Smith wrote:
> On 10/02/2009 04:18 PM, Matthew Talbert wrote:
>>> It "seems" straightforward.
>>> Does it handle "self"? (Which will be in dictionaries.)
>>>      
>> Doesn't appear to.
>>
>>   
>>> 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.
>>>      
>> Looks like it does something with things like Bible.Vulgate, etc, but
>> it doesn't look very sophisticated.
>>
>>   
>>> Does it handle all valid osisRefs? E.g.
>>> osisRef="ESV:Matt.1.1-Matt.2.3,Gen.1.1" (discontiguous range)
>>>      
>> Yes and no. It appears it will get output as
>> sword://Matt.1.-1-Matt.2.3,Gen.1.1 which will then get interpreted by
>> the frontend. In the case of Xiphos, we'd just hand this back to SWORD
>> to parse. I don't know if you would always get expected results here.
>>
>>   
>>> 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.
>>>      
>> I don't disagree. I just wanted to point out that basic support
>> already exists (it would be trivial for BT to provide the same level
>> of support that Xiphos already has). If people start using it, perhaps
>> there will be more pressure to make it better. If no one actually
>> needs or uses the more advanced concepts, then it will be unnecessary
>> to add more functionality.
>>    
> I think we already have the need. We have module writers asking what
> they can do and whether SWORD supports it. Having support in the engine
> encourages module writers to write OSIS according to the spec.
> 
> Additionally, we have some commentaries and gen books with references to
> verses that are not in the KJV versification. Even our KJV module's
> notes have references to verses that are deuterocanonical. We should at
> least mark those that are not in the KJV versification as to which v11n
> that they use.
> 
> Some of the commentaries on my bookshelf have a note such as "all
> Biblical references and quotes are to the XXX version, unless otherwise
> noted." I imagine that some of the commentaries.
> 
> I think there is some utility in having the type of work be part of the
> key. That way if a module is not installed, the lookup can be done in
> the default work for that type. E.g. Dict.ABC:xxx. With just ABC:xxx,
> one cannot know that the reference is to a dictionary and offer to look
> up the word elsewhere.
> 
> In Christ,
>     DM
> 
> 
> _______________________________________________
> 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