Ben Morgan wrote: >> Can't we do osis2mod and then mod2osis (or even mod2imp) and >> store/compare that output, so that the comparison is of text? Or is >> there some reason why that can't work?
> Not really, I don't think. The round-trip may be somewhat important, but it > is the bit in the middle that *really* needs testing. You can easily have it > survive the round-trip but be wrong in the middle. >From looking at the mod2imp.cpp code, mod2imp by default doesn't do much at all with what it outputs... unless the -r or -s options are given to it, it basically outputs module->getRawEntry() using cout. No rendering, no filters, nothing. How would this give correct-seeming output if the underlying (binary) module data files were to be incorrect or corrupted? Can you think up an example of this? I'm seeing mod2imp as a "module-to-text" conversion, so that diffs used for testing are readable -- not really as a round trip back to valid OSIS XML. Of course, this could mean that small fixes would invalidate the collection of "known good" test data... but how big a problem that is in practice can only be found out by trying it and seeing what happens, I think :) > Well, yes. It probably is a good idea, if this is the way that people are > meant to import. Is there another way currently used to generate SWORD modules? Other than the SWORD utilities? Jonathan _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
