<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Nov 14, 2006, at 6:20 PM, Daniel Hilton wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><B class="gmail_sendername">DM Smith</B> wrote:<DIV><SPAN class="gmail_quote"></SPAN><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[snip] ... when a prefix is absent, there are two <BR>different mechanisms for determining the document to which the osisRef<BR>refers. It is possible to map particular elements via the<BR>workPrefixDefault header element to a work. Lacking that an osisRef<BR>refers to the same work. </BLOCKQUOTE><DIV><BR>You are right about that... In my own assumption I chose to ignore the workPrefixDefault for simplicity's sake. But for full osis compliance, both methods would have to be accounted for.<BR></DIV><BR> <BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If I am not mistaken, Sword currently assumes that all osisRefs are to a<BR>bible of the user's choice... </BLOCKQUOTE><DIV><BR>Is there a consesus that this is an acceptable assumption?  Or does anyone agree that the original document should determine each osisRef's target?<BR></DIV></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>It is really not a question of whether it is acceptable. It isn't</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It works for the most part in Bibles because they are mostly used for cross references and it works in commentaries because they are mostly referring to bibles.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The difficulty is more a question of how to move forward.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And yes for an OSIS document an unqualified osisRef is to the same document. So I guess the best way to proceed is to do the lookup in the current document, failing that fall back to the current behavior.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV><DIV></DIV><BR><BLOCKQUOTE class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ...Personally, I'd rather that we have the header for an OSIS work so that<BR>we can use it's metadata rather than creating new mappings in the<BR>current conf.</BLOCKQUOTE><DIV><BR>It would definitely be useful to preserve the osis header metadata, but that doesn't solve the problem of mapping osisWork identifiers to sword module names.  There could possibly be some way to encode that into a &lt;work&gt; tag ( maybe &lt;format type="x-sword"&gt;moduleName&lt;/format&gt; ) if such a hack could be agreed upon, but the conf file seemed to me the most appropriate place for that information, since it is useful only in the Sword environment, and would be irrelevant to the OSIS document in other contexts. </DIV></DIV></BLOCKQUOTE><BR></DIV><DIV>While an original OSIS document may refer to a particular version of the Bible, I think that Sword will continue to allow the user to pick the Bible they want to use. For example, a commentary may be based on the RSV, which is not available as a Sword module, but the user, being German, may want to read the verses in German from their favorite German Sword module.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It may be of interest that a particular reference is to a particular translation/version and perhaps that should be preserved. If so, I'd suggest changing the module creation program osis2mod (which handles Bibles and commentaries) to map the workIDs into module names.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>BTW, where this interest me is that I am a developer for JSword and I know it does not handle it the way it should.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Also, I'd be willing to contribute changes to osis2mod as needed.</DIV><BR></BODY></HTML>