Dear Troy.
Am 29.07.2008 um 12:01 schrieb Troy A. Griffitts:
There are plenty of XML repository/database frameworks available,
and a
frontend developer is welcome to use one, instead of SWORD.
I have no intention to use an other library as SWORD.
It is not only the library, it is also the people.
And the spirit is right here.
The SWORD Engine does not seek to be so generic a framework. We are a
Bible Software Engine and hope to do most all processing work for the
frontend developer.
What do you understand by 'processing work'?
The purpose of a library/framework is that is collects common
functions that otherwise, if not split (backend - fontend), all
frontends would need to implement.
This is of course not so easy because the requirements from frontend
to frontend may vary.
The benefit of having the SWORD engine encapsulate most processing is
that we can all share a common set of tools and collaborate on their
improvement for a variety of platforms (including embedded devices).
Clear.
Does it remove some flexibility as to how the frontend developer
wishes
to display? Not really and here is why.
If the SWORD engine is used how it was intended to be used a frontend
developer can write a basic Bible Software frontend in a couple days
because the engine encapsulates most of the processing work. Only
connecting hooks from the engine to a GUI is required. If they seek
more control over how things work, the engine provides mechanisms at
most every point to allow a developer to plugin their own processing
classes-- allowing them to fall back on the default processing of the
engine as much as they want, but providing their custom processing
when
they feel it necessary.
This is good. The question is to what cost is the more control possible?
If you mean by 'processing work' the HTML rendering then I do not
fully agree.
It is nice that one can develop a frontend in a couple of days. This
mainly is the case because SWORD can deliver ready to go HTML which as
you said just needs to be hooked into the frontend.
But in my opinion this should be an option.
After all it is all about handling data. A library/framework should
make available this data in a way so that the user can choose what to
do with it. Having the framework produce preconfigured HTML for easy
display is one way of making this data available. But in my opinion
and due to the nature of HTML it should not be default way.
I like for example the getEntryAttributes() method because it is an
object model the framework should provide to deliver the data the user
may request.
The problem with getEntryAttributes() is that tight word related data
tagging cannot be retrieved.
There are a number of good technologies we could choose-- and your
XML/XSLT idea is good. But it is not the technology we use for
realtime
processing in the engine. JSword uses this technology and if it would
be more beneficial for your project, you might consider using their
implementation, but I would hope you might help us genericize the
HTMLHREF filters so we might all be able to share more of the default
processing inside the SWORD engine.
It would be possible to use Java in Objective-C environment like we
used Java Lucene for indexing/searching formerly.
But Objective-C is C oriented like C++ and thus C++ is prefered.
I would like to help and maybe in the future I would like to do some
development on the SWORD library itself, if I may. ;)
What don't you like about how HTMLHREF display? Is it the
superscripted
'x'? Could we put it in a <span class="footnote_marker"> allowing you
to write a CSS rule to display or hide as you would like?
What I have in mind is that all additional information in the HTML is
hidden. It actually could be plain text then.
Some information should be shown while moving the mouse over the words
in the HTML view or somewhere in another floating information window.
That would mean making the word a link that has normal display
attributes. But the data of the link might be something individual.
I don't kknow at the moment if this can be done by adding a marker and
using CSS. Actually I didn't thought about using CSS.
The thing is that I want to have the text display for text only (or
almost only) and other information is shown somewhere else. The text
display should be kept as simple as possible.
Maybe this can be achieved somehow by creating HTML filter subclasses.
I was also thinking about using the OSIS filters that Chrtis
mentioned. But parsing XML myself is actually something I don't want
to do.
Regards,
Manfred
Manfred Bergmann wrote:
Am 29.07.2008 um 09:25 schrieb Chris Little:
Manfred Bergmann wrote:
Am 29.07.2008 um 09:10 schrieb Chris Little:
Greg Hellings wrote:
On Tue, Jul 29, 2008 at 1:45 AM, Manfred Bergmann
<[EMAIL PROTECTED]> wrote:
Although I don't understand right now how the Sword module
data is
stored,
my proposal here is that Sword should have a simple intermediate
XML format
that can be used by API users to have full access to the module
data.
Simple HTML/RTF can still be produced from this intermediate
format by
Sword. But HTML should not be used to give access to the module
data while
at the same time raw data access should not be used.
Having XSDs would make is easy for API-users to use XML->Object
binding (I
only know JAXB in Java but this might be available to most
languages as it
is used in protocols like SOAP).
Also XSLT stylesheets can be used to produce HTML or whatever
output.
Frontends could choose to use the HTML rendered output or choose
totally
different approaches by using the data of the intermediate XML.
Let me know what you think.
It seems to me that this is one of the better ideas. After all,
the
library should supply display-agnostic data to the front end,
which
then renders it into a display format, rather than presenting it
with
a list of a few preselected display formats which are supported
at
the
engine level.
If you want OSIS, just ask the engine for OSIS. There's no
requirement
that you tell the API to render text as HTML or RTF. You can
just as
easily tell the API to render to OSIS, and it will happily perform
(or
at least attempt) the conversion from GBF and ThML to OSIS. The
GBFOSIS
and ThMLOSIS filters might need a little more work, but they
should
already work fairly well.
So that means, basically, there is something like intermediate XML
produced on the fly.
Not by default, but you can certainly ask the API for XML in a
single
format.
Do you know approximately how expensive it is to filter to OSIS
instead of HTML?
Manfred
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
