[osis-editors] suggested corrections

[Michael Paul Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 01:29 17-03-04, you wrote:
>Michael Paul Johnson wrote:
...
>> The first difficulty came in attempting to encode the required 
>> xml:lang attribute on the osisText element. There is no 2-letter 
>> code 
>> for this language. Two-letter codes for languages are inadequate 
>> for 
>> Bible translation use, because there are over 6,000 living 
>> languages 
>> spoken today on this planet. Two-letter codes are limited to 676 
>> combinations. Three letters could work, albeit a bit cryptically, 
>> using SIL Ethnologue codes. Tok Pisin does have a perfectly good 
>> three-letter Ethnologue code (PDG), which I tried to insert, and 
>> that 
>> caused a validation failure. Suggestion: make this attribute 
>> OPTIONAL, 
>> but require the header/work/language element, which does allow 
>> language type "SIL".
>> 
>Actually, it should validate if you use "x-" to preface the value you 
>are using for xml:lang. I don't know why the W3C choose such a small 
>list of language codes but they do allow IANA language codes and 
>anything that is preceded by an "x-".

I now use xml:lang="x-SIL-PDG" in that spot.

>> The second difficulty came in encoding verse identifiers for verse 
>> bridges. Because of word order constraints and translational 
>> considerations, it is often better to translate more than one verse 
>> as 
>> a unit. A few less literal translations and paraphrases even in 
>> English use verse bridges, too. In these cases, the verses are 
>> marked 
>> with a range. Allowing an osisID range in the same way as an 
>> osisRef 
>> range would solve this problem. OSIS is not usable for a broad 
>> range 
>> of Bible texts without a good way to encode verse bridges. I 
>> recommend 
>> using the same syntax for verse bridge OSIS IDs as for OSIS 
>> references, but document that the meaning of this syntax for an 
>> osisID 
>> is for a verse bridge, and should not be used to identify passages 
>> that really are translated verse by verse.
>>
>
>The value of an osisID can be a list of osisIDs. That is you can say: 
><p 
>osisID="John.1.1 John.1.2 John.1.3"> Note the whitespace separation 
>of 
>the IDs.
>
>Unlike the range solution you propose, I don't know of a requirement 
>that the refereces be contiguous, although they are most likely to be 
>so.

OK. This works well enough. Lists can be cumbersome, but most verse 
bridges are short, anyway, and it is possible (although not highly 
probable) that someone would want to drop a verse from the middle of a 
bridge and put it in a footnote for textual criticism reasons.

>> One minor point I noticed while attempting to convert the World 
>> English Bible and Hebrew Names Version to OSIS 2.0 was that 
>> footnote 
>> start tags had no equivalent in OSIS. These are the tags that make 
>> it 
>> easy to convert the text that a note refers to into a hyperlink (as 
>> you will see in, for example, http://eBible.org/web/John.htm, which 
>> was converted from web.gbf in http://eBible.org/web/webgbf.zip). 
>> For 
>> now, I threw in some milestone elements with x-startNoteAnchor 
>> attributes at those points. The equivalent element in XSEM is the 
>> "anchor" element.
>> 
>
>Not sure I understand but OSIS has a note element, as well as the 
>HTMP 
><a> element. Oh, you mean how does the anchor get there to point to 
>the 
>note? If so, that is a matter of processing, not encoding.
>
>For example, I have a note in the text and I want to print the text 
>to 
>paper (yikes!). What gets rendered is a number in the text, usually 
>superscripted and a matching number at the bottom of the page or end 
>of 
>the chapter. Neither of those is actually marked in the text.
>
>The reason for that is the question you raise, now I want to do an 
>HTML 
>document and I want a hyperlink to the note. In addition to doing the 
>superscripted number, perhaps even highlighting the word where it is 
>found, I automatically generate a hyperlink as well that points to 
>the 
>note.

But where should the hyperlink start?

>Think of the numbers you see on footnotes as being manual pointers 
>and 
>you will see what I am talking about.

I don't think you get my point, yet, so I'll try again by explaining 
how GBF works, and how I process it, and then maybe you will see the 
hole in the current draft of OSIS. In GBF, each footnote MUST have a 
point marked where the footnote is inserted. At this point, the 
footnote marker is NOT specified, but that is where one would go. The 
text of the footnote is inserted within the element (between <RF> and 
<Rf>, which if it were HTML would probably be <footnote> and 
</footnote>. In GBF, each footnote MAY also have an indicator that 
indicates the beginning, rather than the end, of what the footnote 
pertains to (<RB>). If the footnote does not have this marker, then 
the footnote itself should make that obvious. In processing for 
display or conversion to another format, the mandatory footnote 
elements are processed just as for OSIS when that is all there is. For 
example, in print, a marker may be inserted in the text (such as a 
superscript letter, number, or a symbol like asterisk or dagger), and 
the text rendered at the end of the page. In HTML, a hyperlinked 
marker may be used to invoke a pop-up, a link to a footnote in another 
frame, or to an anchor indicating where the footnote is in the current 
document, with a return link back to the footnote insertion point. 
When the optional beginning marker (<RB>) is present, then much better 
HTML is easier to render for footnotes, in that the hyperlink can 
easily by applied to the word or phrase so marked, rather than to an 
extra marker. You can't do that with OSIS, without resorting to an 
"extra" milestone, like I did. I suppose that you could use the markup 
within the footnote to extrapolate back to where the beginning marker 
should be if it were there, but that is not worth the effort in my 
opinion.

>Hope you are having a great day!

Yes, I am. :-)

>> Thank you for your work towards making OSIS a usable standard. It 
>> isn't too far off...

You are welcome. I hope that it actually gets accepted widely as a 
Scripture interchange & archiving format. Most of its shortcomings can 
be overcome, and in those cases where they can't, conversions can be 
made to and from more suitable formats.

May God bless you.
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: http://eBible.org/mpj/gpg.htm

iD8DBQFAV5IjRI/gxxfXR7sRAqwcAJ90FSUrvzQ6pVshdiTUH0ZgK2rjoACbB5x7
UuoYeH4OJENJq1tdI5PDkBY=
=xwrr
-----END PGP SIGNATURE-----