Checking on the state of these modules, the first one I tried in Xiphos was RSThcsK. Xiphos crashed on it when I moused over an xref. I was in Gen 4:3 when it happened.
Footnotes in RSThcsK are encoded e.g.: <note type="crossReference"> <reference osisRef="Lev.2.12"></reference> <reference osisRef="Num.18.12"></reference> </note> Compare to NASBnew, where a Gen 4:2 xref is encoded: <note n="A" osisID="Gen.4.2.xref.A" type="crossReference"> <reference osisRef="Luke.11.50">Luke 11:50</reference>, <reference osisRef="Luke.11.51">51</reference> </note> The difference, it seems, is just whether there is non-empty content between <reference></reference>. The specific failure occurs because Xiphos was not prepared for an empty return from getEntryAttributes()["Footnote"]["1"]["RefList"].c_str() which is how the backend module of Xiphos obtains xref content, where "1" is the note# within the verse. Obviously Xiphos should not crash in such circumstance regardless. But I need to know what manner of self-defense is in order: Ignore it silently, pop up a warning "this module is evidently improperly encoded", announce an engine failure, ... What I'd like to know is: - whether RSThcsK's encoding is proper, and - whether the engine's empty response in reaction to that encoding is proper. _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
