[sword-devel] Taming Wild Threads (was: Getting stuff done (Re: External links))

[Chris Little]

Daniel Owens wrote:
> 2. The Crosswire repo is a bottleneck. I think Chris needs help to get modules through in a timely manner. More people need to be involved at that step. PLEASE let's find a way to reduce the turnaround time for module publishing. I'm willing to contribute there.

There are essentially two independent issues here (I would guess). One 
is the time it takes to get a module into the beta repository and one is 
the time it takes to get a module from the beta repository into the 
public repository.

1) Getting a module into beta requires submitting a validating XML 
document to me and requires that I have the time to check/fix/upload it. 
I still receive more invalid content than valid, in spite of the fact 
that I repeat and repeatedly post the mantra "validate, validate, 
validate" at every opportunity. Submitted .conf files also invariably 
require some amount of work (sometimes extremely minimal) to bring them 
up to the standard we require.

My own ability to work on submissions varies with my schedule of school, 
teaching, testing, & conferences. I usually have time on weekends to 
catch up with my queue, but I'm less excited about delving into a queue 
full of un-validated content.

The moral being: validated content can generally move into the 
repository relatively quickly.

There are certainly others who have permission to post content into the 
beta repository, and I welcome their doing so, provided our standards 
don't get thrown out the window and provided that they don't cause 
permissions problems like we've had in the past (but I think this latter 
point is no longer such an issue as the server corrects incorrect 
permissions via cron and the sticky bit).

2) Getting content from the beta repository into the public repository 
basically requires sufficient testing. I feel like we have an abundance 
of opportunities for people to help here. We have RSS feeds and the 
InstallMgr itself to alert users when new/updated content has been 
uploaded. We have the module testing wiki page for people to make bug 
reports/comment on issues. And we have the bugtracker for people to log 
trackable bugs (in beta or public modules).

I've posted about 10 new modules in the last couple weeks and received 
zero feedback. I've seen no evidence of testing. Without a modicum of 
testing, this content won't be moved to public.

> 4. Yes, let's maintain source files for ALL modules, only making them public if it is appropriate. That will facilitate bug fixing as well as new module creation. I obtained permission from Crossway to view the ESV source once, and that file had been lost. I still can't figure out how to create a source file that produces a compiled module with the features of the ESV module, and it's been over a year since I started working on it. It's NOT a matter of just using valid OSIS--you have to divine or accidentally discover a hack solution. If working modules were available as examples that would help folks like me and Peter learn how to create good source files.

This sounds like two unrelated issues:
1) maintain source files, and
2) provide better support (tutorials?) for OSIS.

1) Personally I maintain my own sources and those of all submissions. 
I'm not generally open to sharing these publicly, but I keep them in the 
event that updates are necessary.

2) I think we could do more to support OSIS generally. I would like to 
propose that we create an [osis-user] list on crosswire.org. This used 
to exist, hosted at WTS, but is now gone. I think it might be a good 
idea for CrossWire to adopt some of the OSIS support and evangelism 
functions that have been more or less abandoned by its initial financial 
supporters, seeing as they have adopted the position that OSIS is a 
complete standard and therefore their work is done. Indeed, OSIS is a 
complete and usable standard, but there are still support needs, and I 
think we could help with that--especially considering we've likely got a 
majority of people interested and knowledgeable in OSIS somehow 
affiliated with CrossWire.

So I'm proposing a new [osis-user] and a new website (we used to host a 
bunch of sample OSIS files, but they were all OSIS 1.1.1). The new 
website could be a separate wiki, for example. But I think we'd want to 
separate and segregate general OSIS material from Sword material--hence 
the separate wikis. Feel free to disagree with the separateness.

> 5. I've only worked at learning OSIS and TEI, not ThML, but I have discovered that PRISTINE OSIS doesn't always work with SWORD, and ironically GnomeSword supports OSIS the best. Credit should go to Karl and the GnomeSword team for that. The wiki page presents an ideal, but in reality there is a SWORD OSIS schema that is unpublished and unarticulated. PLEASE, can we have an AUTHORITATIVE catalog of supported mark-up and a place to request valid OSIS mark-up that we want supported? If the former doesn't sound feasible, surely the latter is. No one should expect complete support of the OSIS schema, but things like headings, footnotes, and crossreferences should just work, but they sometimes don't. Additional markup should be able to be added, though.

Indeed, someone should do this. Why not you?

I presume the comment about a SWORD OSIS schema was rhetorical, because 
we do use the standard schema. When you import, osis2mod can do strange 
and wonderful (sometimes less than wonderful) things to your markup to 
make processing/rendering easier, but that's none of the encoder's concern.

To find out which features are translated from OSIS (or TEI/GBF/ThML) to 
HTMLHREF or RTF or BibleTime's format, you would need to look at the 
filters, such as OSISHTMLHREF. Even if features are handled by the 
filters, potentially they will not be handled by frontends that use 
them. So you may also need to check for support of the features within 
the frontends themselves. Then hopefully you'll stick all of that 
information about which frontends support which markup into a wiki page. 
(And by suggesting that you get the ball rolling on this, I don't mean 
to suggest that others shouldn't help with this.)

--Chris