I replied to Peter’s question privately.
David
Sent from ProtonMail Mobile
On Tue, Feb 19, 2019 at 08:15, ref...@gmx.net <ref...@gmx.net> wrote:
> I think Michael's advice might be sound.
>
> Which texts are set in this way?
>
> I presume stuff like the population counts in Exodus etc? Or genealogy?
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
> -------- Original Message --------
> Subject: Re: [sword-devel] OSIS files with Tables and Nesting warnings from
> osis2mod
> From: Michael H
> To: SWORD Developers' Collaboration Forum
> CC:
>
>> In usfm, and paratext, each row of a table is independent. That is, several
>> separate "paragraphs" that start r are displayed in a grid form, but each
>> row ( r) is treated separately.
>>
>> As you approach 'tables' in OSIS, I think you'll find that you won't have a
>> problem if you consider this the same way, each row is it's own table.
>>
>> On Mon, Feb 18, 2019 at 4:54 PM DM Smith <dmsm...@crosswire.org> wrote:
>>
>>> When ever a non-milestonable construct is not wholly contained in a verse,
>>> it will not work as a SWORD module in all contexts.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> osis2mod will reverse this and complain where it cannot.
>>>
>>> Anything that converts a different format to OSIS has to work around this
>>> limitation. osis2mod will tell when it is not so.
>>>
>>> One way around this is to have the osisID be for multiple verses and that
>>> contain the construct.
>>>
>>> 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.
>>>
>>> In Him,
>>> DM
>>>
>>>> On Feb 18, 2019, at 5:34 PM, David Haslam <dfh...@protonmail.com> wrote:
>>>>
>>>> Thanks DM.
>>>>
>>>> Sound advice if you were speaking to a translator but it’s not as if any
>>>> of us are.
>>>>
>>>> The context is preparing the text for building a SWORD module for a modern
>>>> translation done by a third party.
>>>>
>>>> We’re not at liberty to change the SFM markup already provided.
>>>>
>>>> We have to deal with things as they are; not with how we’d like them to be.
>>>>
>>>> And the tables markup is in the USFM.
>>>>
>>>> David
>>>>
>>>> Sent from ProtonMail Mobile
>>>>
>>>> On Mon, Feb 18, 2019 at 22:04, DM Smith <dmsm...@crosswire.org> wrote:
>>>>
>>>>> Don’t do it. Tables are often used for presentation when they shouldn’t.
>>>>> Tables should be used for tabular data.
>>>>>
>>>>> Basically, nothing should start or end within a verse that is not
>>>>> milestoned or able to be converted to a milestone.
>>>>>
>>>>> In Him,
>>>>> DM
>>>>>
>>>>>> On Feb 18, 2019, at 10:39 AM, David Haslam <dfh...@protonmail.com> wrote:
>>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> Ryan V wrote about a Bible we're looking at for module build.
>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> Now this is rather odd, seeing as ParaTExt/USFM is quite happy for a
>>>>>> table in which the above happens.
>>>>>>
>>>>>> What advice is there from SWORD developers about how to proceed?
>>>>>>
>>>>>> Must we simply accept the warnings, and just accept the consequences?
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> Sent with ProtonMail Secure Email.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> _______________________________________________
>>> 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
_______________________________________________
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
