[sword-devel] New Modules (front-end developers: please read)

Chris Little chrislit at crosswire.org
Thu Jul 22 16:07:37 MST 2004

Troy A. Griffitts wrote:
> 	There are a number of issues that need to be addressed if we 
> change the modus operandi of verse number handling (which we are doing in 
> spite of your insistence that we are not).  There are merits of using the 
> verse tag to provide the verse number, and there are merits to not use the 
> <verse> tag.  These are all thing which need to be discussed and WE WILL 
> DISCUSS THEM before changing the modus operandi.  This will not be a 
> supported behaviour in 1.5.8.

Okay, I'm fine with discussing them.  I would prefer we do change the 
method of determining the verse number to render, but I don't really 
care whether we do it now or later.  I do care that we include the 
<verse> tags themselves.  Whether they are used or not, they need to be 

>>>I was working on a new module anf run into trouble with your new module.
>>>The module has titles so I think osis2mod put the title tag into each verse 
>>>followed by the verse tag.
>>Correct.  We've always put titles into the verse that immediately 
>>follows them.
> and marked them as preverse text.  This should not change right now.  the
> frontends already deal with preverse number text this way and will for the
> 1.5.8 release.  If you want your modules to be supported in 1.5.8, then
> they need a section of text that is marked somehow as x-preverse that is
> placed into the appropriate entryAttributes element.  You are welcome to
> add a <div type="x-preverse"> if you would like, and then search for
> x-preverse in the osis filters (which I believe only look for it in the
> <title> element currently) and add the check for the <div>.  This should
> allow all frontends to continue to operate without changes.

You're the only one who has ever used the preverse tag.  I doubt 
seriously that it is supported in all frontends since, to my knowledge, 
you have only used x-preverse in the NASB (but I could well be incorrect 
in both of those beliefs).  If the new modules don't implement 
x-preverse and no one supports the new method, then they'll supported in 
1.5.8 just as well as titles have been for the past five years.

> I'm still standing with my position that we will not support all valid 
> OSIS markup in the engine.  The IMPORT code will normal the great 
> diversity of OSIS markup into a normalized (even possibly extended-- gasp) 
> OSIS markup that we understand.  Our filters cannot all try to handle 
> every kind of osis-- from milestone pseudo-containers, to BCV vs. DP, to 
> all the other anomalies that I don't have to remind you about.

That's fine, but it's no reason not to try to support useful markup, 
which I feel this is.

>>>My problem: That is nowhere supported atm.
>>>If I want to implement this in BibleTime I need to know if the module includes 
>>>the <verse> tags in the text itself or if it's a module prepared in the old 
>>Just check the OSISVersion entry in the .conf.  The new modules are 
>>tagged with OSISVersion=2.0.1.  Other OSIS modules won't have this tag 
>>at all and most of them would be tagged as OSISVersion=1.1.1, if we went 
>>back and added the metadata to them.  So you can assume that if 
>>OSISVersion >= 2 then ALL tags from the OSIS document are supposed to be 
>>in the Sword module, including <verse> tags.
> this requires a frontend change, not merely a filter change,
> e.g.
> <title>yoyo</title>
> <verse>verse text</verse>
> will display as e.g. "3 YOYO 3 verse text" since the frontend adds verse 
> numbers currently.

You're mixing up two issues.  I was only dealing with mutliple verses 
inside a single verse entry, since that is what Joachim was talking 
about.  For that, you can just drop the first <verse> tag and render 
numbers for the others.

The change you're talking about is for rendering titles that precede a 
verse, which is exactly parallel to your x-preverse stuff and can be 
handled by parallel code (but code that operates on standard OSIS rather 
than extensions).


More information about the sword-devel mailing list