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
[EMAIL PROTECTED]
http://www.crosswire.org/mailman/listinfo/sword-devel

_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel

Reply via email to