in a significant way. Ever since he pops up here again, offering his modules up for "testing". Sent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: Re: [sword-devel] Virtual modules (parallelism) & fragmentary textsFrom:
nt way. Ever since he pops up here
> again, offering his modules up for "testing".
>
>
> Sent from my mobile. Please forgive shortness, typos and weird
> autocorrects.
>
>
> Original Message
> Subject: Re: [sword-devel] Virtual modules (parallel
here again, offering his modules up for "testing". Sent from my mobile. Please forgive shortness, typos and weird autocorrects. Original Message Subject: Re: [sword-devel] Virtual modules (parallelism) & fragmentary textsFrom: "Andrew T." To: SWORD Developers
lace here in this project for you to offer your modules
> whether for "testing" or otherwise.
>
> Thanks
>
> Sent from my mobile. Please forgive shortness, typos and weird
> autocorrects.
>
>
> ---- Original Message ----
> Subject: [sword-devel] Virtual
al Message Subject: [sword-devel] Virtual modules (parallelism) & fragmentary textsFrom: "Andrew T." To: SWORD Developers' Collaboration Forum CC: The wiki’s whiteboard shows discussion about support for virtual modules:https://wiki.crosswire.org/Whiteboard/Virtual_ModulesSpe
The wiki’s whiteboard shows discussion about support for virtual modules:
https://wiki.crosswire.org/Whiteboard/Virtual_Modules
Specifically the idea of pushing parallelism back to the API has
potentially great benefit for modules built from incomplete MSS. For
example, I’ve compared the English t
> > I think that there is more that can be done in the API.
>
> I merely meant that we are nearly feature complete. That doesn't mean we
> won't still have plenty of work ahead of us in the area of improving the
> API.
Yes. There are some milestones defined in http://crosswire.org/bugs that are
v
Chris Little wrote:
DM Smith wrote:
Didn't think it was going to be easy. But I was going to start with
Bibles, since their structure is more well known and the problem
space would be greatly reduced. Besides, OSIS is not quite there yet
for describing a commentary (though one could use Bibl
DM Smith wrote:
Didn't think it was going to be easy. But I was going to start with
Bibles, since their structure is more well known and the problem space
would be greatly reduced. Besides, OSIS is not quite there yet for
describing a commentary (though one could use Bible markup, if it is a
DM Smith wrote:
> The trick is to get the Strong's Numbers in the first place.
IOW, "Bible" modules that contains just Strong's Numbers for the
Greek NT, Hebrew OT, and Greek LXX.
> This search could be done on a background thread and presented asynchronously
> as "Verses of Possible Interest"
Jonathon Blake wrote:
DM Smith wrote:
How about adding Strong's numbers virtually?
One not so little issue:
Word order. Different languages uses words that mean the same thing,
in a different sequence. [ EG: Subject Object Verb, Subject Verb
Object, Object, Subject Verb ]
A
Greg Hellings wrote:
Presumably that problem has already been solved because we have the
translations already. The concept does seem a little far-out,
though. It would be interesting to hear a more detailed version of
what exactly was being suggested for the virtual addition of the
Strong's
On 1/22/06, Chris Little <[EMAIL PROTECTED]> wrote:
I am actually talking about dynamically creating the configurationsthemselves (using SWConfig). So a user would use the frontend tomanually add some set of modules to a new parallel virtual module (orremove them). Each time the configuration is ch
Presumably that problem has already been solved because we have the translations already. The concept does seem a little far-out, though. It would be interesting to hear a more detailed version of what exactly was being suggested for the virtual addition of the Strong's Numbers.
--GregOn 1/22/06,
DM Smith wrote:
> How about adding Strong's numbers virtually?
One not so little issue:
Word order. Different languages uses words that mean the same thing,
in a different sequence. [ EG: Subject Object Verb, Subject Verb
Object, Object, Subject Verb ]
The same word in a language can be us
Chris Little wrote:
DM Smith wrote:
If I understand correctly, the osisIDs are to form a nesting
hierarchy. If it weren't for the fact that an element with an osisID
can start in one document element and finish outside of it, I think
elements with osisIDs could be represented with begin and
I am actually talking about dynamically creating the configurations
themselves (using SWConfig). So a user would use the frontend to
manually add some set of modules to a new parallel virtual module (or
remove them). Each time the configuration is changed, SWConfig would
write out its new confi
DM Smith wrote:
I think that there is more that can be done in the API.
I merely meant that we are nearly feature complete. That doesn't mean we
won't still have plenty of work ahead of us in the area of improving the
API.
If I understand correctly, the osisIDs are to form a nesting hiera
Troy A. Griffitts wrote:
I've been listening to the discussion and ideas but haven't had too
much time to comment. I like the idea of providing these 'virtual
modules' as dropin solutions for frontend developers. It's a great
idea. I think we discussed previously that I would like for
Is it necessary that the library utilize saved conf files for this construct? I really like the ability to dynamically swap modules in and out, and that seems like it would require the creation of new .conf files for every module combination that is desired. It seems to me that the number of para
DM Smith wrote:
Another idea for a virtual module.
How about adding Strong's numbers virtually?
One of the things that has been suggested is to be able to look up
verses by a Strong's number.
If we knew of a module that had Strong's numbers, we could use that to
do a search, but present res
Another idea for a virtual module.
How about adding Strong's numbers virtually?
One of the things that has been suggested is to be able to look up
verses by a Strong's number.
If we knew of a module that had Strong's numbers, we could use that to
do a search, but present results from the oth
Chris Little wrote:
Troy made a comment to me when we were in Philadelphia for the last
OSIS conference about Sword (the library) nearing a feature-complete
state, where we've pretty much got the capability to do all the basic
stuff that anyone else is doing. Going forward, most of the work i
Hey Chris,
I've been listening to the discussion and ideas but haven't had too
much time to comment. I like the idea of providing these 'virtual
modules' as dropin solutions for frontend developers. It's a great
idea. I think we discussed previously that I would like for us to add
an 'extr
Martin Gruner wrote:
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 tags, and pass
the result back through standard API functions for getting a verse fr
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 t
My vote would be to push it into the API. Especially since the front-end code decides how to display it. And those front-ends who do not use this feature aren't really hurt by having it in the API. Not all front-ends in existence use the entire API as it stands anyway, right? (At least in my limite
Greg Hellings wrote:
I think that the plan is a good one. We are dealing with a large amount
of redundant code in the case of parallel displays. However, what if
two different front-ends want to display the parallel text in different
ways? BibleCS does an internlinear display, but presents
I think that the plan is a good one. We are dealing with a large amount of redundant code in the case of parallel displays. However, what if two different front-ends want to display the parallel text in different ways? BibleCS does an internlinear display, but presents that verse-by-verse. What
Martin Gruner wrote:
please help me understand how your proposal differs from the entry attribute
system that we have now. IIRC that is what BibleTime uses to extract
footnotes, for example.
I admit I haven't even looked at the entry attribute system. I think
that post-dates most of my expe
DM Smith wrote:
I also suggest that this virtual module be expressed as OSIS regardless
of what the underlying encoding.
Well... yeah. :D
I'd probably do something like {GBF|OSIS|ThML|plaintext} > OSIS >
virtual module filter magic > virtual module exposed to API.
--Chris
_
Chris,
please help me understand how your proposal differs from the entry attribute
system that we have now. IIRC that is what BibleTime uses to extract
footnotes, for example.
mg
Am Mittwoch, 18. Januar 2006 19:57 schrieb Chris Little:
> We've got a number of what you might call "virtual modu
Chris Little wrote:
We've got a number of what you might call "virtual modules" either
implemented or desired. I can't speak of other frontends, but BibleCS
has a "PARALLEL" tab, used to present multiple versions interlinearly.
I've recently implemented a "NOTES" tab in BibleCS that pulls any
We've got a number of what you might call "virtual modules" either
implemented or desired. I can't speak of other frontends, but BibleCS
has a "PARALLEL" tab, used to present multiple versions interlinearly.
I've recently implemented a "NOTES" tab in BibleCS that pulls any
footnotes in the sele
34 matches
Mail list logo
