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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > 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: [email protected] >> >> http://www.crosswire.org/mailman/listinfo/sword-devel >> >> Instructions to unsubscribe/change your settings at above page >> > >> > >> > _______________________________________________ >> > sword-devel mailing list: [email protected] >> > http://www.crosswire.org/mailman/listinfo/sword-devel >> > Instructions to unsubscribe/change your settings at above page >> >> > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page
_______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
