<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">When ever a non-milestonable construct is not wholly contained in a verse, it will not work as a SWORD module in all contexts.<div class=""><div class=""><br class=""></div><div class="">From a module perspective, a verse is what is stored as a verse. It includes all the content between what we know as verses, such as titles, sections, paragraphs.</div><div class=""><br class=""></div><div class="">Basic reason is that modules are verse oriented. Each verse has to be able to display in isolation. When a verse is not well formed XML, then it cannot.</div><div class=""><br class=""></div><div class="">We recommend that authors of OSIS see the major constructs of a module to be Books, Chapters, Sections and Paragraphs, expressed as containers. And that verses are milestoned.</div><div class=""><br class=""></div><div class="">osis2mod will reverse this and complain where it cannot.</div><div class=""><br class=""></div><div class="">Anything that converts a different format to OSIS has to work around this limitation. osis2mod will tell when it is not so.</div><div class=""><br class=""></div><div class="">One way around this is to have the osisID be for multiple verses and that contain the construct.</div><div class=""><br class=""></div><div class="">Another way is for the converter to throw away the “offending” construct and just keep the content. That’s what JSword does on a verse by verse basis.</div><div class=""><br class=""></div><div class="">In Him,</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>DM</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 18, 2019, at 5:34 PM, David Haslam &lt;<a href="mailto:dfhdfh@protonmail.com" class="">dfhdfh@protonmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">   <div class="">Thanks DM.</div><div class=""><br class=""></div><div class="">Sound advice if you were speaking to a translator but it’s not as if any of us are.&nbsp;</div><div class=""><br class=""></div><div class="">The context is preparing the text for building a SWORD module for a modern translation done by a third party.&nbsp;</div><div class=""><br class=""></div><div class="">We’re not at liberty to change the SFM markup already provided.&nbsp;</div><div class=""><br class=""></div><div class="">We have to deal with things as they are; not with how we’d like them to be.&nbsp;</div><div class=""><br class=""></div><div class="">And the tables markup is in the USFM.&nbsp;</div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div id="protonmail_mobile_signature_block" class="">Sent from ProtonMail Mobile</div> <div class=""><br class=""></div><div class=""><br class=""></div>On Mon, Feb 18, 2019 at 22:04, DM Smith &lt;<a href="mailto:dmsmith@crosswire.org" class="">dmsmith@crosswire.org</a>&gt; wrote:<blockquote class="protonmail_quote" type="cite">  Don’t do it. Tables are often used for presentation when they shouldn’t. Tables should be used for tabular data.<br class=""><br class="">Basically, nothing should start or end within a verse that is not milestoned or able to be converted to a milestone.<br class=""><br class="">In Him,<br class="">        DM<br class=""><br class="">&gt; On Feb 18, 2019, at 10:39 AM, David Haslam &lt;<a href="mailto:dfhdfh@protonmail.com" class="">dfhdfh@protonmail.com</a>&gt; wrote:<br class="">&gt;<br class="">&gt; Dear all,<br class="">&gt;<br class="">&gt; Ryan V wrote about a Bible we're looking at for module build.<br class="">&gt;<br class="">&gt;&gt; As for the nesting errors, I haven't look at all of them yet. But the ones I did look at have verses starting inside a table, and then ending outside of a table. It's not possible to fix the nesting errors that osis2mod reports in that situation.<br class="">&gt;<br class="">&gt; Now this is rather odd, seeing as ParaTExt/USFM is quite happy for a table in which the above happens.<br class="">&gt;<br class="">&gt; What advice is there from SWORD developers about how to proceed?<br class="">&gt;<br class="">&gt; Must we simply accept the warnings, and just accept the consequences?<br class="">&gt;<br class="">&gt; Best regards,<br class="">&gt;<br class="">&gt; David<br class="">&gt;<br class="">&gt; Sent with ProtonMail Secure Email.<br class="">&gt;<br class="">&gt;<br class="">&gt;<br class="">&gt; _______________________________________________<br class="">&gt; sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class="">&gt; <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">&gt; Instructions to unsubscribe/change your settings at above page<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div>_______________________________________________<br class="">sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" class="">sword-devel@crosswire.org</a><br class=""><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" class="">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br class="">Instructions to unsubscribe/change your settings at above page</div></blockquote></div><br class=""></div></div></body></html>