[sword-devel] Markup Options (was Re: Config file for thml module)

[Greg Hellings]

On Tue, Nov 30, 2010 at 9:18 AM, Peter von Kaehne <refdoc at gmx.net> wrote:
>
>> Von: Greg Hellings <greg.hellings at gmail.com>
>
>> However, a few problems arise.  Namely, I have no control over the
>> display of the text in my target applications (Xiphos and Bibletime)
>> when I use OSIS.  You, being in the semantics-please camp, might think
>> that's a good thing.  You've stymied my attempt, as a content creator,
>> to actually accomplish my goal of influencing rendering.  But as the
>> content creator, I'm not willing to be stymied because the task I was
>> given was to make these texts render the same in SWORD as they do in
>> the source app.
>
> Not withstanding my previous comments on this thread being an annually repetitive occurrence, i do think there is a problem in your reasoning, Greg:
>
> Once you target a specific frontend you end up in the same scenario as we had with the South African modules for BibleCs only. or - on a grander scale - as all those IE6-only sites.
>

These modules are for internal use by an organization.  In time, some
of them might be made available to people outside the org, but for
their internal use, they can control which applications people use.
Additionally, the proprietary software they use is available on
Windows (so BibleCS is a moot point for them) and Macintosh (so
MacSword is also immaterial in their view).  When the project was
started 5 years back, BT and then-Gnomesword were basically the only
two options on Linux, so that was the choice.

Also, the handheld displays are of no interest to them, neither are
the more gimmicky frontends that, for instance, display in a browser
or from the command line.  Since the project was started, BPBible has
also made a showing, and JSword has matured.  I would venture to guess
that BPBible - using largely the same technologies as Xihpos as for
module rendering - would display these modules fine.  My guess is that
MacSword would as well, since I think it uses the HTMLHREF filter
(like Xiphos) and the embedded Safari widget (very similar to BT's
QWebKit widget).  I know not how BibleDesktop would fare, since I have
never used it, but that largely depends on whether it would preserve
the content of the style attribute on the ThML raw SWORD entry.

So the only frontends left to the ravages of cross-format translation
would be BD (ThML -> OSIS -> HTML) and BibleCS (ThML -> RTF).  I'm
fine with BibleCS not working, and maybe some day I'll give BD a look
after these modules work fine in the "target" applications.

> I would much rather we produced good modules and filed endless numbers of bug reports against any application and the library for non-compliance if things which should work do not work, instead of targetting the oddities and non-compliant aspects of each application separately.
>
> And yes, I think XSLT and CSS combination would be the best. I am still waiting for Troy's actual reasoning rather than his gut reaction to XSLT. He promised it.

I understand not wanting to provide the transformation at the engine
level.  SWORD would then need to either provide an XSLT implementation
(any takers?), select one of the ones available (which all come with
lots of baggage - libxml2 is relatively lightweight without too many
dependencies, but it does have some; QXml relies on Qt; Gecko would
require installation of most of the Mozilla/Firefox libraries, etc) or
support many options - which is still more work.  While I might opt to
have libxml2 support if it were up to me, I can understand not wanting
to do so.

But the fact is that all of the front-ends I know of, except for
BibleCS, already have access to XSLT power in their toolkits.  libxml2
is a part of most Gnome stacks, QXml is already available for
BibleTime, BPBible has XML processing built-in to Python and possibly
through wxWidgets as well, Android apps have access to Java which has
extensive XML support, anyone using the Perl bindings has access to a
plethora of CPAN modules to handle XML, etc.  BibleCS might even have
XSLT powers somewhere in Borland's libraries, though I wouldn't know.

So all that points to the power which could be had if the library
produced valid OSIS documents or even fragments for a requested
passage, and then the frontend could select to process through XSLT,
DOM, SAX, or anything else they wanted.  But that would require
someone to step up and fix the *OSIS filters.  I have enough work done
on fixing mod2osis that it could be generalized into the library to
support that use, if this was desired.  But I can't justify taking the
time (for me it would be months because string manipulation in C is
probably my weakest knowledge in programming) away from getting these
modules out the door now.  After they are done, I intend to go back to
that task, but since ThML works grandly for me now, I will just use
it.

--Greg