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

Manfred Bergmann bergmannmd at web.de
Mon Jul 28 23:45:06 MST 2008


Troy.

I installed GnomeSword and checked how they do with cross-references.
Actually it is quite similar to how BibleCS deals with it.

The main problem I have with this is that as far as I understood  
without Sword producing the markup output there is no full access to  
all the meta data because on the other hand you are saying that we  
should not use the raw access which I can understand because using raw  
access means one has to deal with different types of raw sources.
This in my opinion ties the hands of the frontend-developer in that  
Sword interferes too much into the display of the data or differently  
spoken does not give the flexibility and data access without having  
Sword produce data meant for display.
HTML is my eyes is a markup meant for display.

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.


Regards,
Manfred



Am 28.07.2008 um 12:35 schrieb Troy A. Griffitts:

> Manfred,
>
> 	In addition to what Ben wrote, GnomeSword uses the stock HTMLHREF
> filters and doesn't add their own.  These filters are usually  
> updated by
> me or someone on their team.  It might be good to pop in to
> irc.freenode.net #sword and ask charcoal about how they do certain
> things with these filters.
>
> 	-Troy.
>
>
>
> Manfred Bergmann wrote:
>> Hi Ben.
>>
>> Ok, one can get the cross-references by getting the entry attributes.
>> But if the body is not passed in again to the filter you can't figure
>> anymore to which word the cross-reference is related to by just
>> parsing the attributes.
>> The only chance to get the relationship is to show the information in
>> the tooltip or while clicking on the cross-ref link.
>> Please correct me if I'm wrong.
>> If this is correct I have to say that this is quite unflexible.
>> If someone chooses to not render anything related to cross-references
>> but still wants to have the data (to show it somewhere else) there is
>> no way to get the word -> cross-ref relationship.
>>
>>
>>
>> Regards,
>> Manfred
>>
>>
>> Am 28.07.2008 um 01:35 schrieb Ben Morgan:
>>
>>> Yes, there was a change.
>>> I had to change BPBible as well :)
>>>
>>>> From r2157:
>>> Modified: trunk/src/modules/filters/
>>> osisfootnotes.cpp
>>> ===================================================================
>>> --- trunk/src/modules/filters/osisfootnotes.cpp 2008-05-13 02:58:16
>>> UTC (rev 2156)
>>> +++ trunk/src/modules/filters/osisfootnotes.cpp 2008-05-13 23:37:56
>>> UTC (rev 2157)
>>> @@ -108,7 +108,7 @@
>>>                                       hide = false;
>>>                                       if (option ||
>>> (startTag.getAttribute("type") && !
>>> strcmp(startTag.getAttribute("type"), "crossReference"))) {    // we
>>> want the tag in the text; crossReferences are handled by another
>>> filter
>>>                                               text.append(startTag);
>>> -                                                
>>> text.append(tagText);
>>> +//
>>> text.append(tagText);   // we don't put the body back in because it
>>> is retrievable from EntryAttributes["Footnotes"][]["body"].
>>>                                       }
>>>                                       else    continue;
>>>                               }
>>>
>>> As it says, you can just get the text using getEntryAttributes at
>>> the end of the note.
>>>
>>> The way BPBible installs custom filters is by subclassing the
>>> MarkupFilterMgr's AddRenderFilters, rather than the SWMgr's
>>>
>>> It would be nice if you could pass the filters you wanted used in,
>>> though. This would be a pretty common use case...
>>>
>>> God Bless,
>>> Ben
>>> -------------------------------------------------------------------------------------------
>>> The Lord is not slow to fulfill his promise as some count slowness,
>>> but is patient toward you, not wishing that any should perish,
>>> but that all should reach repentance.
>>> 2 Peter 3:9 (ESV)
>>>
>>>
>>> On Sun, Jul 27, 2008 at 9:09 PM, Manfred Bergmann
>>> <bergmannmd at web.de> wrote:
>>> Hi Troy.
>>>
>>>
>>> Am 26.07.2008 um 18:44 schrieb Troy A. Griffitts:
>>>
>>>>      Do you have:
>>>>
>>>>     swordManager.setGlobalOption("Cross-references", "On");
>>>>
>>>> anywhere in your code?
>>> Yes.
>>> I just tested a version of MacSword with Sword library 1.5.10 where
>>> the cross ref list (<reference> elements) are placed inside the note
>>> element and are passed to the HTML filter.
>>> Has there been a change for this from 1.5.10 to 1.5.11?
>>>
>>>> Yes.  You should never have to call AddRenderFilter to a module,
>>>> though
>>>> we do allow you to add your own special filters by overriding the
>>>> virtual SWMgr::AddRenderFilters() method if one of the default  
>>>> SWORD
>>>> filter sets does not work for you.  Not sure how MacSword does it
>>> now.
>>>
>>> Hmm, we are doing exactly that ATM.
>>> We didn't override AddRenderFilters() in SWMgr but set Filter  
>>> subclass
>>> instances for every module in a loop via Module::AddRenderFilter().
>>> So the prefered way is to do this via SWMgr::AddRenderFilters().
>>>
>>>> The MarkupFilterMgr is the mechanism to ask SWORD to give you a
>>>> specific
>>>> output markup from RenderText().  This code figures out which  
>>>> filter
>>>> set
>>>> to apply to each module depending on the module SourceType (OSIS,
>>> GBF,
>>>> ThML, etc...) and will apply the correct filters to meet your
>>>> requested
>>>> output type.  But if you can't use any of the default filter sets,
>>>> then
>>>> you'll have to override SWMgr::AddRenderFilters() and apply your
>>>> custom
>>>> filters.
>>> We did that and used RenderFilters from BibleTime project from 2001.
>>> But I adapted some changes of the current Sword render filters so  
>>> the
>>> new attributes are checked for additionally to the depricated ones.
>>>
>>>
>>>
>>> Regards,
>>> 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
>>
>>
>> _______________________________________________
>> 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/20080729/7575501c/attachment-0001.html 


More information about the sword-devel mailing list