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 _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
