[sword-devel] milestone element, osisRef attribute

Mon Sep 17 04:32:49 MST 2018

Semantics:
osisID marks the address of the current item.
osisRef points the address of a different item that the current item references.

I think that the osis manual gives a suggested mechanism for two v11ns in the same document. My computer is in the shop and I cannot check. 
— DM Smith
From my phone. Brief. Weird autocorrections. 

> On Sep 17, 2018, at 3:16 AM, David Haslam <dfhdfh at protonmail.com> wrote:
> 
> Thanks Horst for explaining. 
> 
> Why is osisRef used rather than osisID ?
> 
> The latter would be valid to the schema. 
> 
> David
> 
> Sent from ProtonMail Mobile
> 
> 
>> On Mon, Sep 17, 2018 at 06:22, Horst Sclemmer <schlemmerhorst1731 at gmail.com> wrote:
>> Hi all, 
>> 
>> It's good to see this discussion going on. 
>> I try to briefly explain the need for having the osisRef in a milestone. 
>> As many people are able to read Russian, most translations for languages 
>> in the former Soviet Union use the SynadalProt versification. So, people 
>> comparing their translation with Russian scriptures won't be confused. 
>> On the other hand most of the (former Soviet Union) scriptures don't 
>> follow the versification in every detail. 
>> A very common difference is the problem you see in the Uighur Cyrillic 
>> with Romans 14 and 16. 
>> As Peter already mentioned, there is an anomalie with the last three 
>> verses of Romans 14 and 16. Most western translations (KJV) follow 
>> manuscripts that have these verses in Romans 16:25-27, whereas 
>> SynodalProt has them in Romans 14:24-26. 
>> Romans 16:25-27 seems to be the better place to have them, so most 
>> Central Asian translations decided, not to follow the SynodalProt 
>> versification here. 
>> 
>> The milestone types "x-vsys-..." and annotateRef 
>> annotateTypes="x-vsys-..." are used to reference these moved verses to 
>> the right verses. 
>> See 
>> https://github.com/JohnAustinDev/osis-converters/blob/master/scripts/bible/osis2sourceVerseSystem.xsl 
>> for all the details and possible types. 
>> These milestone and annotateRef types are already used in a lot of OSIS 
>> files for scriptures in the IBT repository 
>> (http://ibt.org.ru/ftpmirror/pub/). 
>> 
>> I can remove the parts that are currently not supported by the OSIS schema. 
>> But as this is a general solution to deal with translations that vary 
>> from their versification, I would suggest to take the effort to adjust 
>> the OSIS schema and add the osisRef attribute to the milestone element. 
>> 
>> Kind regards 
>> 
>> Horst 
>> 
>> 
>> 
>> On 9/13/2018 6:21 PM, David Haslam wrote: 
>> > In the OSIS 2.1 Users Manual, for the milestone element only three attribute names are mentioned: type, n, marker 
>> > 
>> > The osisRef attribute is currently defined only for the following OSIS elements: catchWord, chapter, div, figure, note, q, reference 
>> > 
>> > If we wish to enhance the CrossWire updated OSIS schema, the request should be added as a new subsection in this wiki page: 
>> > https://wiki.crosswire.org/OSIS_211_CR
>> > 
>> > What does the Uighur translation team envisage as the practical use of osisRef in the OSIS example given? 
>> > What would we expect SWORD to do with it? 
>> > 
>> > Best regards, 
>> > 
>> > David 
>> > 
>> > Sent with ProtonMail Secure Email. 
>> > 
>> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ 
>> > On Thursday, 13 September 2018 10:01, Peter von Kaehne <refdoc at gmx.net> wrote: 
>> > 
>> >> Deal all, 
>> >> 
>> >> I am in the process of uploading an update to our cyrillic Uygyur 
>> >> module. 
>> >> 
>> >> There are a few instances where the new text does not validate due to 
>> >> use of osisRef in the milestone element. The author asserts that 
>> >> osisRef should be possible inside the milestone element and I can not 
>> >> see any reason indeed why it should not - other than "the schema does 
>> >> not allow it". Below an example. The textual background is a manuscript 
>> >> anomaly in Romans 14 and 16, where a couple of verses appear commonly 
>> >> at the end of Romans 16, but in some manuscript in Romans 14. 
>> >> 
>> >> 30965 <verse osisID="Rom.14.23 Rom.14.24 Rom.14.25 Rom.14.26" 
>> >> sID="Rom.14.23 Rom.14.24 Rom.14.25 Rom.14.26" type="x-vsys- 
>> >> fitted"/><milestone type="x-vsys-verse-start" annotateRef="Rom.14.23" 
>> >> annotateType="x-vsys-source"/>Лекин бирәр йемәкликкә шәк кәлтүрүп 
>> >> туруп, йәнә шу йемәкликни йегән киши вижданиниң әйиплишигә учрайду. 
>> >> Чүнки у киши өзи йегән йемәкликниң тоғра екәнлигигә ишәнч қилалмиди. 
>> >> Тоғра екәнлигигә ишәнч йоқ һалда қилинған һәр қандақ иш 
>> >> гунадур.</p><milestone type="x-vsys-movedto" annotateRef="Rom.16.25" 
>> >> annotateType="x-vsys-source" osisRef="Rom.14.24"/><milestone type="x- 
>> >> vsys-movedto" annotateRef="Rom.16.26" annotateType="x-vsys-source" 
>> >> osisRef="Rom.14.25"/><milestone type="x-vsys-movedto" 
>> >> annotateRef="Rom.16.27" annotateType="x-vsys-source" 
>> >> osisRef="Rom.14.26"/><verse eID="Rom.14.23 Rom.14.24 Rom.14.25 
>> >> Rom.14.26" type="x-vsys-fitted"/><milestone type="x-vsys-verse-end" 
>> >> annotateRef="Rom.14.23" annotateType="x-vsys-source"/> 
>> >> 
>> >> Any views? Should the schema be updated or should I reject the module 
>> >> in its current form? 
>> >> 
>> >> Peter 
>> >> 
>> >> 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 
>> > 
>> > 
>> > _______________________________________________ 
>> > 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 
>> 
>> 
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20180917/9c3e01ef/attachment.html>