[sword-devel] Making better use of the CrossWire GitHub project ?

[Robert Hunt]

Just to add a little to Michael Johnson's comments below, OSIS can 
include significantly more metadata than USX specifies (which is little 
more than the book code -- not even whether it's an original text 
(Heb/Greek) or what language translation it is). OSIS can specify many 
other things like version number, licenses and contributors' names, etc.

So for a fair comparison with OSIS, I think you'd have to specify USX 
*along with ScriptureBurrito metadata*: see https://www.Burrito.Bible 
<https://www.burrito.bible/> (which is also in the process of being 
supported by the most influential Bible-translation orgs AFAIK).

Blessings,
Robert.
https://OpenEnglishTranslation.Bible <https://OpenEnglishTranslation.Bible>

On 19/02/24 10:19, Michael Johnson wrote:
>
> Thank you, Michael, for the pointer to Jonathan Robie's paper on 
> Scriptural markup in the Bible translation community. I think it 
> diplomatically states why USX won out over OSIS as the primary and 
> best-supported XML standard for representing Scripture.
>
> I really don't expect USFM or USX to go away any time soon, nor do I 
> expect OSIS to gain significant traction where it is not in use 
> already. I think it is safe to say that Crosswire is the group that 
> cares most about OSIS. In many ways, the USX vs. OSIS competition is 
> like the old VHS vs. BetaMax video tape competition. (Remember way 
> back when video tapes were actually used?) BetaMax was technically 
> superior in many ways, but VHS won because of (1) greater support by 
> content providers, (2) slightly lower cost of implementation, and (3) 
> incompatibility between the formats (i.e. no machine could read both 
> formats).
>
> I honestly think that fully supporting USX would be a better use of 
> limited resources than tweaking OSIS to overcome its current defects.
>
> For those that don't know, USX is an XML representation of USFM.
>
> USX is well documented and actively maintained at 
> https://ubsicap.github.io/usx/. OSIS is abandoned by almost everyone 
> by Crosswire. Backup copies of the Schema or on crosswire.org and 
> eBible.org, but there is currently no official pumpkin holder to 
> maintain it.
>
> USX is fully automatically convertable to and from USFM with no loss 
> or human intervention needed. This is not true of pure OSIS for 
> technical and philosophical reasons. This is probably the biggest 
> reason that OSIS was never supported natively in Paratext, and most 
> likely never will be.
>
> USX is the native format of the Every Tribe Every Nation Digital Bible 
> Library, which is the highest-quality and best-supported repository of 
> Bible translations in the world.
>
> USX and/or USFM are supported by all of the best Bible translation 
> software, including open source options. OSIS has no Bible translation 
> software support.
>
> USX and/or USFM are supported by numerous Bible publishing options, 
> both digitally and for print. OSIS has no significant Bible publishing 
> support outside of Crosswire.
>
> USX has organizational support from the most influential Bible 
> translation agencies.
>
> Using USX and/or USFM makes versification mapping easier, because 
> someone else has already done the work.
>
> There are currently at least 2 reasonable ways to convert from USFM or 
> USX to OSIS with minimal losses in formatting. Neither one is perfect, 
> but maybe good enough. There is a lot of code assuming OSIS inputs to 
> Sword modules, and that could remain, along with GBF and TEI, but I 
> can see better quality coming from direct USX support.
>
> If OSIS is good enough as is, fine. But if it isn't, then I suggest 
> that it be phased out rather than modified.
>
>
> On 2/18/24 09:42, Michael H wrote:
>> Re: Lack of momentum for OSIS.
>>
>> OSIS as described on wikipedia is owned by a committee including 
>> United Bible Societies, SIL International, and the Society of 
>> Biblical Literature.
>>
>> However, this team got together and created the version that is 
>> available, then almost completely ignored it, and went back to the 
>> SFM tagging system and then produced USFM, when turned into several 
>> more closely related XML languages, but has become USX. There was in 
>> the UBS/SIL Paratext translation program the ability to produce OSIS 
>> output until version 8, but since about 2016, there is no use or 
>> mention of OSIS in Paratext.
>>
>> A history and analysis of why this is published in Balisage 2021 
>> conference:
>>
>> https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html
>>
>> Even in 2024, the tagging language USFM remains the "primary" tool to 
>> encode biblical works at almost all the organizations that produced 
>> OSIS. There is no momentum for that committee to ever meet again. But 
>> the spec has holes.
>>
>> https://gitlab.com/cmahte/osis-users-manual-2.1
>>
>> I started working on updating OSIS, and in the process received a 
>> reply from someone at ABS or UBS that although the OSIS spec is 
>> copyrighted and does not contain specific verbiage about reuse, I 
>> could and should consider it licensed under creative commons BY-SA. 
>> (At the time, I wasn't seeking to update OSIS, but freely copy from 
>> it in creating a successor or fork.)
>>
>> This means that OSIS is both abandoned and available for adoption by 
>> a successor body.  I've also since moved on from ever producing 
>> proposed changes to it or a fork myself. IF I ever got far enough 
>> along to need a formal spec, it would be extensions USFM or to 
>> OpenDocument or more directly synonymous with that XML.  If you're 
>> interested, I'll dig up the contact information, and pass it along. 
>> But I do have a copy re-edited into USFM (or more specifically a 
>> draft version of PSFM... which means the way tables are built in my 
>> text are unusual.) If there is an effort to update. I can transform 
>> my work into LibreOffice Writer format.
>>
>> I suggest it is time to consider an OSIS 3, or at least an OSIS 2.2 
>> spec that is owned by a successor organization instead of 
>> organizations that effectively abandoned it. That's the missing link 
>> which would provide a mechanism to actually make changes to the 
>> standard.  People (including me) keep doing this search and landing 
>> at Crosswire Bible society as the best option for a new owner. But 
>> maybe who OWNS can be one of the topics considered by a committee.
>>
>> On Sat, Feb 17, 2024 at 9:47 AM Arnaud Vié <unas.zole+avie at gmail.com 
>> <mailto:unas.zole%2Bavie at gmail.com>> wrote:
>>
>>     Hi everyone,
>>
>>     Having dived into the whole crosswire ecosystem recently, I'm at
>>     the same time impressed at the quality of the tools provided (in
>>     particular the OSIS standard and the JSword lib, as I've been
>>     working in Java), and worried by what I perceive as a lack of
>>     dynamism around it's development and difficulty to contribute.
>>
>>     By "lack of dynamism" I of course don't mean to criticise the
>>     time anyone spends (as we contribute to a free ecosystem, we all
>>     have lives keeping us busy elsewhere), but rather to highlight
>>     how rough it is for external enthusiastic people to join.
>>     For example, I'd like to contribute evolutions to the OSIS
>>     standard around versification systems, but I have no idea where
>>     to make such proposals, as there is only a mailing list dead
>>     since 2015 <http://crosswire.org/pipermail/osis-core/>, a few
>>     wiki pages <https://wiki.crosswire.org/Category:OSIS> and a few
>>     downloadable documents <https://crosswire.org/osis/> which are
>>     supposedly the latest version.
>>
>>     I think a lot of that could be improved by making better use of
>>     the crosswire github project <https://github.com/crosswire>,
>>     which is nowadays the first contact most young developers will
>>     have with these crosswire projects.
>>
>>     I'd like to propose a few changes, get your opinions, and
>>     volunteer to execute them if everyone agrees.
>>
>>       * *Revive the jsword github repository*.
>>         That includes
>>           o Backporting the relevant changes from the andbible fork
>>             <https://github.com/AndBible/jsword/pulls?q=is%3Apr+is%3Aclosed>
>>             (excluding android-specific stuff - which I already
>>             mostly removed in my last PR there).
>>           o Setting up a release process to publish the jar on a
>>             maven repository.
>>           o Setting up a clear branching model and writing clear
>>             contribution guidelines.
>>           o Having a team of several people familiar with Java
>>             development to review PRs or answer questions in the
>>             issue tracker. I obviously volunteer, but more people is
>>             always the best.
>>
>>       * *Create a new Git repository for the OSIS specification*.
>>         Must contain :
>>           o In Git, the OSIS XSD schema, and the functional
>>             specification (basically, the contents of the current
>>             manual) in markdown or asciidoc format.
>>             So that contributions to the standard may be opened as
>>             pull requests, reviewed, potentially stored as separate
>>             branches, etc.
>>           o A wiki tab where all relevant OSIS-related resources from
>>             the crosswire wiki should be copied.
>>
>>       * Ideally, I'd also suggest *moving the C++ sword code to github*.
>>         Having it only on an old SVN repo
>>         <https://crosswire.org/svn/sword/trunk/>, not browsable or
>>         searchable online, really harms its visibility. I used a
>>         little bit of SVN while in engineering school 12 years ago,
>>         but I doubt that most young devs nowadays even know about it.
>>
>>     But for this last C++ part, I suspect it has bigger impact on
>>     current developers, since Troy is still actively developing it
>>     and using the Jira bugtracker for this part - so there is no
>>     urgent need to change.
>>     I'm really more worried about the jsword repo (it breaks my heart
>>     to see it dead since 2019) and having a visible and versioned
>>     location for the OSIS standard.
>>
>>     Please let me know your thoughts !
>>     And whoever is currently admin of the github project, would you
>>     be willing to grant me some permissions on the jsword repo and a
>>     new "osis-spec" repo to start setting up all of this ?
>>
>>     Regards,
>>
>>     Arnaud Vié
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20240219/2046fc90/attachment-0001.htm>