[sword-devel] Sword enhancement proposal [was: HTML filter cross references link]

Tue Jul 29 23:39:29 MST 2008

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
>>>>>> <bergmannmd at web.de> 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20080730/e831a6cc/attachment.html 