[sword-devel] SWORD link, and other misc. comments

[DM Smith]

Troy,

I think as a new version of Strong's dictionary is being worked upon and 
as people are contemplating the creation of OSIS commentaries, that we 
need to decide how to mark up self referential links should be done. I 
agree with you that we can hold off on the implementation of a more 
general reference mechanism.

For a practical case, Biblical dictionaries often reference verses and other
In Strong's Hebrew Dictionary:
00011
11 Abraam ab-rah-am'  of Hebrew origin (85); Abraham, the Hebrew 
patriarch:--Abraham. (In Acts 7:16 the text should probably read Jacob.) 
see HEBREW for 085

Also in TCR (Thompson's Chain Reference)
ABIGAIL
wife of Nabal, becomes David's wife  1Sa 25:3; 27:3; 30:5; 2Sa 2:2; 1Ch 
3:1  --SEE Notable Women, WOMEN

The Webster's dictionary is full of self references. (Who has ever read 
a dictionary where a word is not defined in terms of another? :)

Troy A. Griffitts wrote:
> Hey DM.  Thanks for pointing out the error in the manual.  Regarless of 
> the manual, the specification clearly states:
>
> <xs:attribute name="osisRefWork" type="osisWorkType" use="optional" 
> default="Bible"/>
>   

I did not think of looking there.

>   
>> There is a deprecation of the osisRefWork in favor of a new mechanism 
>> workPrefix, which allows one to associate specific paths with a workID. 
>> However, it is, in my opionion, an unnecessary complication for this 
>> discussion.
>>     
>
> Where did you hear that "There is a deprecation of the osisRefWork"?
>
> I might understand such a thing with the inclusion of a new generic 
> defaulting mechanism which we've been discussing, but I don't think 
> anything has made it into the specification yet.
It is in the manual. In the OSIS manual it states the following:

"In OSIS versions through 2.0, specific attributes were provided to set 
a default work prefix for osisIDs
(osisIDWork on the osisText element) and for osisRefs (osisRefWork on 
the osisText element). These
attributes remain available in OSIS 2.1, but a more general defaulting 
mechanism has been added.

In OSIS version 2.1 and later, the workPrefix element was added to make 
it possible to specify a default
work prefix for the attributes on any element in an OSIS document."

The phrase "These attributes remain..., but...." to me indicate that the 
latter mechanism is able/intended to replace the former. Perhaps, it was 
badly worded.

Even as such, I don't like having multiple default mechanisms, because 
it is harder to code and because Sword modules don't keep the OSIS 
document header.


>   The ideas for it began 
> when we made an attempt to address Michael Paul Johnson's concerns 
> regarding quote transformation for author preference and odd languages. 
>   I think we included the ability to give defaults for the quote tags, 
> with intention to open it up to any tag, but didn't think we had gone 
> that far yet.
>
> There is good history on the osis-core list regarding work defaulting 
> and it was likely a heated discussion.  I would rather not repeat the 
> debate here.  It is more complicated when you start hashing things out, 
> and when you really think about it, is there a demand to write a 
> reference from a book to another book?  'Type' doesn't really meet a 
> demand I can think of, either.

I deliberately left out any mention of GenBooks, precisely because it is 
messy. In the other modules, the structure and meaning of the modules 
and their keys is fairly rigid and well-defined. In those cases, 'Type' 
can work well.

I have seen some commentaries that declare that all quotes are from a 
particular version of the Bible, unless otherwise noted. I think it 
makes sense for the author of the module to declare that references are 
to that version and to also note those that are to a different specific 
work.

> It's just not worth the hassle, in my 
> opinion.  I have many other high demand items on my list that seem to 
> put this way off the radar.  The information you've added has been, as 
> always, well articulated and valuable; and I'm sure will be beneficial 
> in the future if we ever do have a demand (as you have suggested in a 
> previous email about new modules drive functionality).
>   
I agree and thank you.

> How's the genbook support in jsword? ;)

GenBook is about half done. The harder half remains :)