On 10/02/2009 03:06 PM, Matthew Talbert wrote:
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.
It "seems" straightforward.
Does it handle "self"? (Which will be in dictionaries.)
Does it handle Bible.KJV:reference or Bible.ref-system.work:reference?
(I.e. where the workID is not merely the name of the module but contains
other info?) At least it should then split on '.' and take the last part.
Does it handle all valid osisRefs? E.g.
osisRef="ESV:Matt.1.1-Matt.2.3,Gen.1.1" (discontiguous range)
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
http://www.crosswire.org/pipermail/sword-devel/2008-November/029892.html
http://www.crosswire.org/pipermail/sword-devel/2008-November/029724.html
http://www.crosswire.org/pipermail/sword-devel/2008-November/029762.html
I remember that. And since I'm not much of a SWORD programmer, I didn't
say much.
My point: By having a workable mechanism in the engine that is updated
as needed to handle more and more of the osisRef spec, more front-ends
can share the fruits of labor.
Troy and Chris stated, in those email threads, it is essentially a
front-end issue. I won't argue that. But it is one that has to be solved
by each front-end. It would be nice for the solution to be done once and
shared.
In Him,
DM
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
