Both the \fr and \xo fields serve the
same purposes:
Note that both fields are entirely redundant in the sense that
they can always be derived from the book, chapter, and verse
where the note or cross reference source is placed. \v 1-2 and contains a footnote, the footnote's \fr field would have to contain "2:1-2". Strictly speaking, \xo and \fr fields are still optional. In the context of a Sword module, the link aspect of the \xo and \fr fields make no sense, but they could be presented with different formatting such as color, bold, etc. On 01/06/2016 11:09 AM, David Haslam wrote: Yet another subject arising from working on a copy of u2o.py Aydeth treated these two markers differently.\fr is the footnote "origin" reference. · This is the chapter and verse(s) that note refers to. \xo is · the cross reference "origin" reference. · This is the chapter and verse(s) that target reference(s) are being provided for. At first sight they appear to be similar in function, except for how SWORD would handle them after conversion to OSIS and then module. \fr is converted as one would expect to <reference type="annotateRef">...</reference> I see no problems with that. It's the way our own converters already do it. \xr was converted to plain text, without any reference element. He commented: # there is no mapping in the osis manual for the xo usfm tag # old handling of this tag is commented out. # r'\xo': ('<reference type="annotateRef">', '</reference>'), # potential alternate handling of xo and xt... # r'\xo': ('<reference type="x-anchorRef">', '</reference>'), # r'\xt': ('<reference type="annotateRef">', '</reference>'), I added these explanatory comments in the script: # DFH: that was similar to the handling of \fr in footnotes. # In the USFM Reference, \fr and \xo have almost identical descriptions. In their place he had: r'\xo': ('', ''), r'\xt': ('<reference>', '</reference>') I have no substantive issues with how he handles \xt but I see a weakness in merely leaving \xo as plain text rather than something else. Currently, I've changed the handling of \xo in my working script as follows: # DFH: provisionally marking xo using a seg element because # we do need something to separate the origin from any non-reference text # that might precede the real scripture references in poorly constructed USFM r'\xo': ('<seg type="x-origin">', '</seg>'), This doesn't cause any validation issues (using seg rarely does). I have added the following comment lines: # DFH: We ought to implement as documented in the SWORD developers' wiki # http://www.crosswire.org/wiki/OSIS_Bibles#Marking_cross-references_notes # Example: (in which the ! sub-identifier syntax is used) # <note type="crossReference" n="t" osisID="Jer.24.7!crossReference.t"> However, I'm not yet competent enough in Python programming to implement that enhancement. It's early days still. Because SWORD handles a properly constucted OSIS cross-reference as a link to the target passage, I'm fairly convinced that Aydeth was right in not making the \xo origin reference into a link too. Yet that's what our own usfm2osis.pl & usfm2osis.py scripts have always done, if I'm not mistaken. Doing so just adds to "link clutter" within the cross-reference note, and serves no practical purpose. After all, you already know where you are before you click a cross-reference link, and afterwards, it's no longer in view. So when would you ever need to click the origin link? Does anyone disagree with my analysis? Someone might ask what I meant by the phrase "poorly constructed USFM" , but that's more a topic for another day. Suffice it to say that conceptually we should have separated out these two stages of postprocessing after USFM to OSIS conversion: 1. Declutter all references and parallel passage headings 2. Fix cross-references and parallel passage headings by making them into proper OSIS links. Working on the Welsh Beibl again has shown me how much latitude translators can take when they are creating \x_...\x* cross-references. It's not really that they are poorly constructed. It's rather that what USFM allows is not always neatly convertible to OSIS without special care. Best regards, David -- View this message in context: http://sword-dev.350566.n4.nabble.com/SFM-to-OSIS-handling-of-the-markers-fr-and-xo-tp4655619.html Sent from the SWORD Dev mailing list archive at Nabble.com. _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page --
Aloha,
|
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page