Hi Greg,<br><br><div class="gmail_quote">On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings <span dir="ltr"><<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>></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 <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> wrote:<br>
> Speaking as a BPBible developer, I would tend to prefer C++ filters to<br>
> XSLT. Here are some reasons why:<br>
> 1. It works now (well, OK, it doesn't always work as well as one might like,<br>
> 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'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_<tag> and end_<tag> 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>
> 2. It is (fairly) readily able to be customised by application developers<br>
> using the magic of inheritance. BPBible at least takes advantage of this,<br>
> and 0.4.7 contained about 800 lines of Python in our filter code. For 0.5<br>
> the OSIS filter has doubled in size. By contrast, if we were to maintain an<br>
> app-specific XSLT file, we would probably need to duplicate the whole file<br>
> and then make changes to it, and any changes made to the base XSLT file<br>
> would have to be manually merged in. Bye-bye to the idea of having only one<br>
> 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>