[jsword-devel] Verse markup in OSIS modules

[DM Smith]

Thanks for your reply, I think I have enough to go on. I will be doing a 
little bit of refactoring, pushing some behavior from 
PassageAbstractBook into SwordModule.


Joe Walker wrote:
> 
>  From a verse markup point of view:
> There is a future discussion on alternative verse markups, and one 
> possible solution is to have the Russian Bible return the same original 
> text translated and the English, but with different verse boundaries. So 
> the Key to lookup is defined in terms of English, but the markup 
> returned is defined in terms of the visible data.
> 
In reading the OSIS 2.0.1 User Manual, I see that there is an effort to
define a standardized mapping, but it looks like it is just starting.

>  From a theoretical touchy feely point of view:
> PassageAbstractBook does not feel like the best place to deal with 
> module encoding issues to me, it would make more sense to ask the 
> filters to do it,

Since a filter does not know its context, it would need to be told its 
context. Right now the filters seem to be working w/o knowledge of 
anything but a simple transformation from one markup to another. So the 
filters work equally well with non-bibles.

My preference is to leave the filter as it is.

> or maybe SwordBook is different enough that it should 
> have it's own copy of that method.

Good point. It does seem that this is a Sword module issue and not an 
issue with books from other sources. So if we were to add drivers for 
other providers, then it may have other assumptions about the storage of 
the text.

> 
>  From an OSIS point of view:
> It sounds like verse milestones are the only really sensible way to 
> handle complex markup, and using milestones helps get out of the issues 
> of how paragraph markers and verse markers should be used. The fact that 
> we currently use verse container elements has complicated our XSL in 
> handling paragraphs. So verse milestone feels like a better solution for 
> us.

If we are adding missing markup, we can add verse milestones, but if we
are dealing with OSIS as given, then the XSLT will need to be able to
handle both. At the current time, it does not handle verse milestones
and will actually output a verse number for a eID milestone. The same is
true for the other elements that may be either containers or milestones.

I think that the 2.0 spec allows for so much flexibility that it
requires a complex, well documented XSLT to handle all of it. I think
that it will be an evolutionary development process to get there.

Since the XSLT is an informal contract of what JSword expects the OSIS
to be, should we create test cases for it?

> 
> All of these say that verses should be the domain of the filters and not 
> PassageAbstractBook.

This is my opinion also. But the best solution, IMHO, is that the verses 
should be marked in the text itself.

A problem I see with migrating verse markup into the filter is that it 
represents an architectural divergence from how filters are used in 
Sword. How important is it for JSword and Sword to share the same filter 
architecture?

A second problem is that a filter should not know its context/module.

> 
> I suppose question 2 is should we swap to verse milestones before v1.0 
> or after, and I guess that depends on how bit the change is.

I think the verse milestone change is fairly localized (hits a small 
number of modules) and is easy to do. I will look into making that change.

> 
> Joe.