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