[sword-devel] New Modules (front-end developers: please read)
Troy A. Griffitts
scribe at crosswire.org
Sat Jun 12 13:52:26 MST 2004
Chris,
Thanks for all the hard work.
I think we need more discussion before changing modus oparandi on verse
rendering for all clients of the API.
A few bylaws we've adhered to which are valuable to the users of the
engine:
o A client of the engine should only have to render Bible verse numbers
in 1 way (possibly 2-- for an exception like alternate versification-- I
think done with footnotes thusfar); we shouldn't expect them to have
checks in their code for a variety of methods.
o We shouldn't expect a client to know the base markup (even OSIS). We
do the hard work to hand them something they've requested on init of the
lib (previously by subclassing SWMgr and applying appropriate filters,
and now with your newer SWMarkupMgr, which more nicely isolates them
from the plethora of filter combinations).
I think these are valuable things which we might be violating with your
latest changes. Is there a way to provide filtering in OSIS* filters to
retain these benefits?
Up until now, I've had the personal opinion that we should normalize
OSIS modules to our internal OSIS methods of markup, so filters could
all expect constructs in the document to be encoded consistently. We
have a filter OSISOSIS (which is a silly name) which is intended to
filter 'our OSIS' markup back to the 'original OSIS' markup of the
document. It is used primarily to remove non-conformant tags like
<resp> in our KJV module, or any other thing we might add to help our
rendering process, but doesn't either conform to the OSIS standard or
recommended guidelines, like restore x-preverse titles to their original
positions.
Again, thanks for the work. It's nice to have someone finally update
our OSIS support. Just want to maintain integrity of these features, if
we can.
-Troy.
Chris Little wrote:
> I just posted three new modules to the beta site (actually two are
> updated, but they're from scratch and significantly different from their
> previous versions). They are the AB (Apostle's Bible), EMTV (English
> Majority Text Version), and UKJV (Updated King James Version)--all in
> English. They look fine to me but could definitely use some testing.
>
> (non-front-end developers can stop reading past here)
> The modules were built with the updated osis2mod that I just committed.
> It is different from previous versions in that it tries to maintain as
> much of the OSIS document in the module database as possible (and in the
> correct order).
>
> In particular, verse tags are included within each verse. This means
> you can render verse numbers on the basis of markup contained in the
> text rather than on Sword's hardcoded verse numbers. The AB module, for
> example, includes many verses beyond the last verse of a chapter. If
> you simply ignore the verse tags, these will just look like you've
> concatenated the extra verses to the last verse (which is technically
> what has happened). But if you render verse numbers on the basis of
> verse tags, you can simulate alternate versifications to a limited
> degree (as long as they don't cross chapter boundaries--see Ps.150/151
> in the AB for an example where this doesn't work).
>
> This also avoids the <title type="x-preverse"> kludge. If you render
> verse numbers on the basis of verse tags, any titles that precede the
> first verse tag are obviously going to come before the rendered number.
>
> OSIS has two different ways of representing verses. The AB and UKJV
> modules uses <verse> & </verse> tag pairs (the container model). The
> EMTV module uses <verse sID="..."/> & <verse eID="..."/> tag pairs (the
> milestone model--which is more common and named as the best practice).
> So if you implement rendering on the basis of verse tags, realize that
> there are two varieties.
>
> --Chris
>
>
>
> _______________________________________________
> sword-devel mailing list
> sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
More information about the sword-devel
mailing list