<div class="gmail_quote">Speaking as a BPBible developer, I would tend to prefer C++ filters to XSLT. Here are some reasons why:<br>1. It works now (well, OK, it doesn't always work as well as one might like, but it does work).<br>
<br>2. It is (fairly) readily able to be customised by application developers using the magic of inheritance. BPBible at least takes advantage of this, and 0.4.7 contained about 800 lines of Python in our filter code. For 0.5 the OSIS filter has doubled in size. By contrast, if we were to maintain an app-specific XSLT file, we would probably need to duplicate the whole file and then make changes to it, and any changes made to the base XSLT file would have to be manually merged in. Bye-bye to the idea of having only one lot of library source to maintain.<br>
<br>3. It allows developers to use sources that are outside the document being transformed. This has had some issues for us (from memory, the filter code isn't re-entrant), but we use this functionality to do things like expanding a list of cross-references in the user's locale, looking up the headwords for Strong's Numbers, and looking up the text in the current version for a passage in a harmony. By contrast, unless we have some good way to call into C++/Python from XSLT we will not be able to use sources outside the current document unless we do some complex post-processing. If we do have such a way it could just increase complexity.<br>
<br>4. It allows us to share common functionality between the ThML filters and the OSIS filters (which we do). I think this proposal would have us still using C++ ThML filters while moving the OSIS filters to XSLT, which would make the results further apart.<br>
<br>5. I would be concerned if performance dropped at all, as I suspect it would (especially if calls into C++ were involved as well).<br><br>6. Currently our rendering works on a verse-by-verse basis. I'm not sure what it would look like if we were trying to do something like a chapter at once. Do we run through the chapter in one go? What kind of well formed OSIS document can we get from a single verse or collection of verses to pass into an XSLT? Is there much cost to fire up an XSLT engine just for the one verse we have in our search preview? What would you do if you wanted to have a discontinuous range of verses or to show versions in parallel verse-by-verse? We also surround each verse and a rendered section with other extra stuff which varies depending on the context. I'm not sure where this would fit in the XSLT (if at all).<br>
<br>In short, as a BPBible developer I much prefer implementation in C++ because it allows us to do things we want to do much more easily than with XSLT (though if Troy or anyone else wants to improve the present implementation they are welcome to). I cannot speak for the pros and cons from a module creator point of view.<br>
<br>Jon<br><br>On Wed, Dec 1, 2010 at 6:08 AM, Troy A. Griffitts <span dir="ltr"><<a href="mailto:scribe@crosswire.org">scribe@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Having finally returned from a hectic 2 weeks of conferences, and lots<br>
to do before leaving for Christmas, I'm not sure I'm up for a heated,<br>
passionate debate about technologies right now, but by all means, please<br>
commence the public discussion.<br>
<br>
Let me start by saying that everyone (I believe) agrees that we would<br>
like to have an HTML output from the engine which is more generic and<br>
would allow CSS to be applied if a frontend would like to do this.<br>
Currently HTMLHREF output from the engine is used by the widest number<br>
of frontends (to my knowledge) and would benefit everyone involved by<br>
becoming much more generic. e.g.,<br>
<br>
<title> -> <h1><br>
rather than<br>
<title> -> <b><br /><br>
<br>
<transChange type="added"> -> <span class="tcAdded"><br>
rather than<br>
<transChange type="added"> -> <i><br>
<br>
etc.<br>
<br>
I believe this will solve a number of issues and possibly get the BT and<br>
MacSword teams onboard to using the same HTML output filters as the<br>
other projects involve (or at least subclassing them and using the<br>
majority of their functionality).<br>
<br>
<br>
Now, as to the other issue of using XSLT internally in the engine to<br>
process OSIS -> HTML<br>
<br>
I will throw a few melons into the air for target practice, and let the<br>
shooting commence.<br>
<br>
_____________________________<br>
*Multiple Language*<br>
<br>
XSLT is a programming language in the same sense that C++ is a<br>
programming language.<br>
<br>
The SWORD Project C++ engine is written in C++. It is not a Python<br>
engine; it is not a Perl engine; it is not a Java engine; it is C++.<br>
<br>
One might say, "Well, you can use XSLT from C++. Doesn't JSword do this<br>
from Java?" Well, yes, of course you can, and DM can comment, if he<br>
feels the desire to recommend his decision to encorporate an XSLT engine<br>
into the JSword logic flow. But simply because one CAN doesn't mean one<br>
SHOULD. We COULD encorporate a Perl text processing engine in our C++<br>
code, or an Awk processing engine... that doesn't mean we SHOULD. I'm<br>
sure some would say we SHOULD. And obviously DM has thought he SHOULD<br>
encorporate XSLT processing for JSword, so I'm not intending to say it<br>
is a BAD decision, just that it is not a decision I would make; in the<br>
same way as our projects each chose C++ vs. Java to implement our objective.<br>
<br>
_______________________<br>
*XSLT better than C++*<br>
<br>
One might say, "well, XSLT is better suited to process XML than C++."<br>
That's a loaded and unquantified statement.<br>
<br>
Certainly the C++ language specification doesn't include facilities to<br>
easily process XML, but that doesn't mean a plethora of C++ libraries<br>
don't exists for assisting in this task.<br>
<br>
The SWORD engine includes classes like XMLTag and SWBasicFilter which<br>
implement a SAX processing model.<br>
<br>
The current filters do not all use SWBasicFilter, nor XMLTag. They've<br>
been written over 15 years and many before these classes existed. Some<br>
are ugly and need to be rewritten for readability, certainly. But not<br>
necessarily in a different programming language.<br>
<br>
________________________<br>
*COMPLEXITY*<br>
<br>
The task of enumerating all types of OSIS <title> tags, and deciding<br>
what to do with each, and how to classify all <title> tags from all<br>
possible OSIS documents into our enumeration is still going to be a<br>
complex task using XSLT. <title> is a complex example, but certainly<br>
not the most complex.<br>
<br>
It is a tall task to generalize all elements of all documents from all<br>
publishers into one conceptual model with one chosen output for a<br>
frontend-- whether that be for an audience on the Desktop, web-based, or<br>
a handheld.<br>
<br>
The complex processing required by the engine will require long, complex<br>
XSLT-- which likely will encorporate callbacks to C++. It will not be<br>
more simple-- only mixed language.<br>
_______________________<br>
*Semantic vs. Display*<br>
<br>
Some will say (and have), "well, let everything be display oriented and<br>
let the publisher decide". Fine, then you lose 2 things: the ability to<br>
display differently per user preference, per display device; and you<br>
also give up the promise to actually do any interesting research on the<br>
text. When you lose semantic markup, then you lose all interesting<br>
information about WHAT is being marked up.<br>
<br>
_______________________<br>
*More than a Rending Engine*<br>
<br>
The SWORD C++ Engine is more than simply a text rendering engine-- it is<br>
a Biblical text research engine.<br>
<br>
If I'd like to know the morphology of word 3 in 2Thes 2.13 of the WHNU<br>
Greek text, the entire program to do such is:<br>
<br>
SWMgr library;<br>
SWModule *whnu = library.getModule("WHNU");<br>
whnu->setKey("2th.2.13");<br>
whnu->RenderText();<br>
<br>
cout << "The morphology of word three is: " <<<br>
whnu->getEntryAttributes()["Word"]["003"]["Morph"] << endl;<br>
<br>
<br>
That reads nice (at least in my opinion). I don't need to know about<br>
XML, XSLT, care what markup the WHNU module uses, I don't even have to<br>
know how to make a SWORD filter. The current filters do all the work of<br>
breaking out these attributes and making them available in a nice and<br>
interesting map.<br>
<br>
______________________<br>
<br>
<br>
And finally, if bullets aren't flying already, I'll stir the heat up with...<br>
<br>
XSLT sucks. A good C++ programmer can do anything in C++ better than<br>
any XSLT programmer.<br>
<br>
<br>
:)<br>
<br>
*duck*<br>
Have fun.<br>
<br>
Troy<br>
<br>
PS. In summary, I understand the current filters are sometimes overly<br>
complex and need cleanup, standardization, etc. It comes down to the<br>
fact that they mostly work, and other things which don't get priority,<br>
so they don't get much attention. But honestly, I think one might be<br>
oversimplifying the problem at hand without realizing it, if one simply<br>
thinks switching to XSLT will make things easier.<br>
<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" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div><br>