[sword-devel] XSLT vs. C++

[Ben Morgan]

Hi Greg,

On Thu, Dec 2, 2010 at 2:19 AM, Greg Hellings <greg.hellings at gmail.com>wrote:

> On Wed, Dec 1, 2010 at 8:13 AM, Jonathan Morgan <jonmmorgan at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20101202/2d1e359c/attachment-0001.html>