Hi Greg, On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings <greg.helli...@gmail.com>wrote:
> On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan <jonmmor...@gmail.com> > wrote: > > Speaking as a BPBible developer, I would tend to prefer C++ filters to > > XSLT. Here are some reasons why: > > 1. It works now (well, OK, it doesn't always work as well as one might > like, > > but it does work). > > It works for our historical collection of modules, but the current > implementations of some of the filters are rigid and very difficult to > update or modify. But yes, it more or less works now. > 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 http://code.google.com/p/bpbible/source/browse/branches/webconnect/backend/osisparser.py#475 ) > > 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. > > XSLT is easily extensible. SAX is easily extensible. > Basically what is used already is a SAX-like model, just implemented by Sword. Customizability is just the same as you describe. 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) Also, on a personal level, due to having never used XSLT, I feel comfortable using Python/C++ whereas XSLT is scary. God Bless, Ben ------------------------------------------------------------------------------------------- Multitudes, multitudes, in the valley of decision! For the day of the LORD is near in the valley of decision. Giôên 3:14 (ESV)
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page