[sword-devel] XSLT vs. C++

[Peter von Kaehne]

Thanks Troy,

Probably I am the worst person to answer first, but it was me who threw
the matter once again into the ring. Hence...

On 30/11/10 19:08, Troy A. Griffitts wrote:
> Having finally returned from a hectic 2 weeks of conferences, and lots
> to do before leaving for Christmas, I'm not sure I'm up for a heated,
> passionate debate about technologies right now, but by all means, please
> commence the public discussion.
>
> Let me start by saying that everyone (I believe) agrees that we would
> like to have an HTML output from the engine which is more generic and
> would allow CSS to be applied if a frontend would like to do this.
> Currently HTMLHREF output from the engine is used by the widest number
> of frontends (to my knowledge) and would benefit everyone involved by
> becoming much more generic. e.g.,
>
> <title> -> <h1>
> rather than
> <title> -> <b><br />
>
> <transChange type="added"> -> <span class="tcAdded">
> rather than
> <transChange type="added"> -> <i>
>
> etc.
>
> I believe this will solve a number of issues and possibly get the BT and
> MacSword teams onboard to using the same HTML output filters as the
> other projects involve (or at least subclassing them and using the
> majority of their functionality).
>
A more detailed and accurate feedback from the engine for what is
actually in the source text would certainly be for me a huge step forward.

The lack of detail and fine print in the current filtering is doing
neither the modules nor the vast majority of presentation engines we use
any justice. I guess this is a universal agreement. Essentially we make
no use of most OSIS attributes, but mostly simply translate the tags
themselves. So much so that some are in some frontends actually
re-invented - footnote markers are a case in point.

Moving beyond that agreement, the question is how to proceed.

The single most important reason I have to prefer XSLT over C++ in the
filters is admittedly not technical:

I believe there is a wider range of people within CrossWire who can make
sense of XSLT and could engage with the filters, than with the current
layout in C++.  I think filters are - once we are beyond the basic
implementation - of particular interest to module makers.  I could see a
work flow emerging for module makers which looks like this:

- Create a valid OSIS document with all features which are in the text,
- determine which OSIS features are not yet covered,
- fix/expand the filters.

I have no doubt that this is not sufficient reason and I would be
delighted to see if a similar work flow could emerge with C++, but you
will admit, it has not so far, apart from Chris. I had a good go at
trying to understand osis2htmlref.cpp - and gave up. I will happily try
again, but am not too hopeful. I think the age of the filters is
certainly witness to the fact that not many dared touching them.

The second reason I have is related - an updated style sheet is easily
distributed and would allow a separate and increased frequency of
release. It could even become part of the module manager's refresh
mechanism - check on updates to XSLT sheet and call them in on refresh.
We could then leave actual libsword releases for bugs and fundamental
changes, but have the whole filter release much more dynamic and speedy.

A separated out C++ filter bundle might of course do the same, though I
am not sure how this would pan out technically.

Yours

Peter