[sword-devel] virtual modules
mg.pub at gmx.net
Thu Jan 19 03:18:06 MST 2006
> What I'm proposing is that the API would, in addition to real modules
> like the KJV, GerLut, MHC, etc., expose modules that aren't represented
> explicitly through a module stored on disk.
That sounds like a good idea to me.
> For example, a PARALLEL virtual module, assuming which translations to
> present in parallel were somehow specified, would pull a single verse
> from translations A, B, & C, surround them with <verse> tags, and pass
> the result back through standard API functions for getting a verse from
> a regular module.
I don't see too much gain here, at least judging from a BT perspective. If
frontends have to disasseble the resulting OSIS code again, it would perhaps
be even more work. This depends on how the frontends want to present the
> A NOTES virtual module would do the same thing,
> returning just the notes (converted to OSIS) from a specified module for
> a specified verse.
That's what EntryAttributes were created for.
> And a VERSEDIFF virtual module would produce
> something like the wdiff results that have been under discussion, for a
> specified pair of modules and a specified verse.
This could be interesting for a virtual module, because here the virtual
module does some real work.
Another case where I could imagine a good use for it would be the "on-the-fly"
generation of Interlinear Virtual Modules (tm) ;) (based on Strong's
numbers), but there frontend presentation-markup issues come in again.
This is a good and innovative concept, but probably should be thought about
more in order to create a consistent structure in the API. Maybe we should
store this for our discussion about Sword 2?
What do y'all think?
More information about the sword-devel