[sword-devel] virtual modules

[Martin Gruner]

Hi Chris,

> 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 
module.

> 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?

mg