[sword-devel] Taming Wild Threads (was: Getting stuff done (Re: External links))
chrislit at crosswire.org
Thu Nov 27 00:42:41 MST 2008
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
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.)
More information about the sword-devel