Hi Greg,<br><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings <span dir="ltr">&lt;<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan &lt;<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>&gt; wrote:<br>
&gt; Speaking as a BPBible developer, I would tend to prefer C++ filters to<br>
&gt; XSLT.  Here are some reasons why:<br>
&gt; 1. It works now (well, OK, it doesn&#39;t always work as well as one might like,<br>
&gt; but it does work).<br>
<br>
</div>It works for our historical collection of modules, but the current<br>
implementations of some of the filters are rigid and very difficult to<br>
update or modify.  But yes, it more or less works now.<br></blockquote><div>I agree it can be very fiddly and fragile - that&#39;s mostly the filters like the headings filters which are run before render; the OSISHtmlHref filters are simple enough to work with. Extending it in python once it is set up is very easy as well (basically defining a start_&lt;tag&gt; and end_&lt;tag&gt; handler - for our handling of poetic lines, for example, see <a href="http://code.google.com/p/bpbible/source/browse/branches/webconnect/backend/osisparser.py#475">http://code.google.com/p/bpbible/source/browse/branches/webconnect/backend/osisparser.py#475</a>)</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt; 2. It is (fairly) readily able to be customised by application developers<br>
&gt; using the magic of inheritance.  BPBible at least takes advantage of this,<br>
&gt; and 0.4.7 contained about 800 lines of Python in our filter code.  For 0.5<br>
&gt; the OSIS filter has doubled in size.  By contrast, if we were to maintain an<br>
&gt; app-specific XSLT file, we would probably need to duplicate the whole file<br>
&gt; and then make changes to it, and any changes made to the base XSLT file<br>
&gt; would have to be manually merged in.  Bye-bye to the idea of having only one<br>
&gt; lot of library source to maintain.<br>
<br>
</div>XSLT is easily extensible.  SAX is easily extensible.<br></blockquote><meta charset="utf-8"><div>Basically what is used already is a SAX-like model, just implemented by Sword. Customizability is just the same as you describe.</div>

<div><br></div><div>I do not believe XSLT is a good option; for a start, it requires (AFAIK) valid XML fragments, which we do not have within a verse in much of existing content (or even at all necessarily). JSword I believe has fallbacks to extract the text if not valid xml, but I would far prefer not to use such hacks; SWORD can handle this quite well (as probably SAX could if non-validating). Also, due to the structure of OSIS with multiple hierarchies, however you process it it will be complicated and this loses much of the benefits of XSLT. (Disclaimer - never used XSLT) </div>

<div><br></div><div>Also, on a personal level, due to having never used XSLT, I feel comfortable using Python/C++ whereas XSLT is scary.</div><div> </div>God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>

Multitudes, multitudes,<br>    in the valley of decision!<br>For the day of the LORD is near<br>    in the valley of decision.<br><br><div>Giôên 3:14 (ESV) </div></div>