[sword-devel] OSIS feature support and questions

Matthew Talbert ransom1982 at gmail.com
Fri Oct 2 12:06:56 MST 2009

>>  I thought there was a long discussion about
>> this previously and we discovered that there was indeed support for
>> this, just the OSISHTMLHREF filters needed updated to output something
>> for it. As of 1.6.0, the filters have been modified to output sword://
>> style links for these references, which works in Xiphos and BPBible
>> (which are the only ones using these filters as far as I know).
> Is the code to handle it part of Xiphos and BPBible? or is it part of the
> SWORD engine? (If so, please point me to the file and line.)

Well, we handle the sword:// references in Xiphos, but they are
created in the filter. See osishtmlhref.cpp starting in L307. It
appears all that is being done is that tag.getAttribute("osisRef")
returns the entire reference, which is then split on ':' to get the
work and reference. It seems fairly straightforward.

> Short of that I'd expect routines to give back the parts (work, v11n,
> category, grain, reference, ...) of an osisID.

Well, it's just splitting on ':' so I guess it wasn't considered
necessary to make it any fancier.

>>  <reference osisRef="ISBE:MIZRAIM">Mizraim</reference>
>> does exactly what you would expect.
> That's good. Is this true of all front-ends (other than those based on
> JSword, which does not handle it.)

No, the front-ends would have to a) be using the HTMLHREF filters, and
b) implement support in their application for following these links.

>> Anyway, this works fine for me in Xiphos, so I guess I'm unclear where
>> the lack of support is.
>> Matthew
>> PS It looks like these links cause a segfault in BibleTime, so
>> apparently they don't have support for this in their filters after
>> all. Still, it's a filter issue, not an engine issue.
> The filters are part of the SWORD engine. I'm aware that at least one
> frontend has their own render filters. But they are or were based on the
> filters in the SWORD engine.

> I think that common handling of lookup should be pushed into the SWORD
> engine.

This is certainly a different perspective than has been shared before. See

More information about the sword-devel mailing list