[sword-devel] Titles and other Inter-verse material

[Kahunapule Michael Johnson]

On 07/23/2012 06:26 PM, Chris Little wrote:
> On 07/23/2012 07:35 PM, Kahunapule Michael Johnson wrote:
>>
>>
>> On 07/23/2012 04:06 PM, Chris Little wrote:
>>> On 07/23/2012 07:09 AM, David Haslam wrote: ...
>>>
>>>
>>>> He therefore introduced a new OSIS element <milestone
>>>> type="x-p-indent" />
>>>>
>>>> It's used to provide a poetry indentation as an alternative to
>>>> using line elements with level attributes. Currently, deeper
>>>> indents are created by two or three <milestone type="x-p-indent"
>>>> /> elements in series.
>>>
>>> That sounds incredibly bad. It's up there with milestoned <p/>.
>>>
>>> Why not just encode &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * the number of
>>> indents? Or use the UTF-8 equivalent, which is only 10-bytes long.
>>> They both require no processing by rendering filters and are
>>> meaningless as standard markup like the milestone tag above.
>>
>> The reason that Xulsword works well with poetry is that its different
>> markup is matched with its different display code making a better
>> over-all system with respect to poetry display.
>
> ...which could have also been achieved by rendering the standard markup as expected, rather than by adding handling of non-standard markup.

True. I'm sure that alternative was considered, and rejected for reasons I'm not privy to. There are usually many ways to solve the same problem.

>
>> If you think that milestoned paragraph types, poetic or otherwise,
>> are a bad idea, then the best argument you can make is by making
>> non-milestoned paragraphs, poetry, and prose work well end-to-end. In
>> the mean time, somebody just proved that milestoned poetic lines can
>> work well.
>
> <p/> is bad because it uses a container element to represent a non-container, and it abuses the semantics of the element for purely typographic purposes.
>
> <milestone type="x-p-indent" /> is bad because it employs a private-use extension to imply the semantics of a container element, again for purely typographic purposes.

At one point, I remember that OSIS was supposed to be able to represent paragraphs as containers and verse markers as milestones and vice versa. The "vice versa" there implies the existence of paragraph markers as containers. I fail to see what the problem would be with consistently using verses as containers and consistently delimiting paragraphs as milestones. Theoretically, either way can 100% represent the data. Indeed, the verse-primary model better represents what many Bible study software packages
actually do. I'm not saying you should or should not do that, but that this is not obviously a bad thing to do. Indeed, it may be a clever thing to do in some cases, for typographic or other reasons.

>
>> In the end, I think that it is the whole system that matters, not
>> just the source markup, module creation, module format, engine, and
>> front ends individually, but how they work together as a unit to
>> display Scriptures in many languages and with the features and
>> typographic formatting richness that people have come to expect from
>> their Bibles.
>
> Yes... it's the whole system that matters, and having one front end render non-standard markup in a non-standard way doesn't really aid the situation, considering that the texts that come from CrossWire are all going to conform to the standard. Following a standard is precisely how to make all the individual parts work together in predictable ways.

True, indeed. However, when a problem tempts people to extend, bend, or disregard the standard to get proper results, it might be wise to at least consider if the standard itself has a problem, either in the mechanics of it or in the documentation and usage.

>
> It also hasn't been identified why
> <l level="2">....</l>
> is more difficult to translate into an indentation than
> <milestone type="x-p-indent" />,
> so I necessarily see this as a solution in search of a problem.

No, but it is apparent by lack of implementation that there must be some difficulty... maybe it is just a shortage of developer time.