<div dir="ltr"><div>That's a debate that goes far beyond the scope of the current discussion, but to be honest I don't understand why USX even exists ^^'</div><div><br></div><div>USFM favours easy editing of the files with its simple text tags.</div><div>It makes perfect sense for editing bibles, in particular in translation software.</div><div><br></div><div>OSIS favours accurate semantic description of the document structure (with nested elements and such), making use of the full power of XSD.</div><div>It makes perfect sense for published document representation, and for software that cares about searching and rendering.</div><div><br></div><div>USX takes the worst of both worlds : it takes all the heaviness of XML, while using it to render flat sequences like USFM does. It's basically "USFM, but heavier". I see no gain compared to USFM, except potentially the fact that escaping of special characters is made easier (because handled natively by the XML parser). That's not a whole lot to justify a brand new format.<br></div><div><br></div><div>My personal conclusion after this exchange would simply be "Great, if nobody else currently cares, we can take full ownership of OSIS, let's do it ! " :-D<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 18 févr. 2024 à 22:20, Michael Johnson <<a href="mailto:kahunapule@ebible.org">kahunapule@ebible.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>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.</p>
<p>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).</p>
<p>I honestly think that fully supporting USX would be a better use
of limited resources than tweaking OSIS to overcome its current
defects.</p>
<p>For those that don't know, USX is an XML representation of USFM.</p>
<p>USX is well documented and actively maintained at <a href="https://ubsicap.github.io/usx/" target="_blank">https://ubsicap.github.io/usx/</a>.
OSIS is abandoned by almost everyone by Crosswire. Backup copies
of the Schema or on <a href="http://crosswire.org" target="_blank">crosswire.org</a> and eBible.org, but there is
currently no official pumpkin holder to maintain it.</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>USX has organizational support from the most influential Bible
translation agencies.<br>
</p>
<p>Using USX and/or USFM makes versification mapping easier, because
someone else has already done the work.</p>
<p>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.</p>
<p>If OSIS is good enough as is, fine. But if it isn't, then I
suggest that it be phased out rather than modified.<br>
</p>
<p><br>
</p>
<div>On 2/18/24 09:42, Michael H wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-family:garamond,serif;font-size:large">Re: Lack of
momentum for OSIS. <br>
<br>
OSIS as described on wikipedia is owned by a committee
including United Bible Societies, SIL International, and the
Society of Biblical Literature. <br>
<br>
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. <br>
<br>
A history and analysis of why this is published in Balisage
2021 conference: <br>
<br>
<a href="https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html" target="_blank">https://www.balisage.net/Proceedings/vol26/html/Robie01/BalisageVol26-Robie01.html</a><br>
<br>
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. <br>
<br>
<a href="https://gitlab.com/cmahte/osis-users-manual-2.1" target="_blank">https://gitlab.com/cmahte/osis-users-manual-2.1</a><br>
<br>
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.) <br>
<br>
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. <br>
<br>
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. <br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Feb 17, 2024 at
9:47 AM Arnaud Vié <<a href="mailto:unas.zole%2Bavie@gmail.com" target="_blank">unas.zole+avie@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hi everyone,</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div>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 href="http://crosswire.org/pipermail/osis-core/" target="_blank">a mailing list
dead since 2015</a>, <a href="https://wiki.crosswire.org/Category:OSIS" target="_blank">a few wiki pages</a>
and <a href="https://crosswire.org/osis/" target="_blank">a few downloadable documents</a>
which are supposedly the latest version.</div>
<div><br>
</div>
<div>I think a lot of that could be improved by making
better use of <a href="https://github.com/crosswire" target="_blank">the crosswire
github project</a>, which is nowadays the first contact
most young developers will have with these crosswire
projects.</div>
<div><br>
</div>
<div>I'd like to propose a few changes, get your opinions,
and volunteer to execute them if everyone agrees.</div>
<div>
<ul>
<li><b>Revive the jsword github repository</b>.<br>
That includes</li>
<ul>
<li>Backporting the <a href="https://github.com/AndBible/jsword/pulls?q=is%3Apr+is%3Aclosed" target="_blank">relevant
changes from the andbible fork</a> (excluding
android-specific stuff - which I already mostly
removed in my last PR there).<br>
</li>
<li>Setting up a release process to publish the jar on
a maven repository.</li>
<li>Setting up a clear branching model and writing
clear contribution guidelines.<br>
</li>
<li>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.<br>
<br>
</li>
</ul>
<li><b>Create a new Git repository for the OSIS
specification</b>.<br>
Must contain :</li>
<ul>
<li>In Git, the OSIS XSD schema, and the functional
specification (basically, the contents of the
current manual) in markdown or asciidoc format.<br>
So that contributions to the standard may be opened
as pull requests, reviewed, potentially stored as
separate branches, etc.<br>
</li>
<li>A wiki tab where all relevant OSIS-related
resources from the crosswire wiki should be copied.<br>
<br>
</li>
</ul>
<li>Ideally, I'd also suggest <b>moving the C++ sword
code to github</b>.<br>
Having it only on <a href="https://crosswire.org/svn/sword/trunk/" target="_blank">an old SVN
repo</a>, 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.</li>
</ul>
</div>
<div>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.<br>
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.<br>
</div>
<div><br>
</div>
<div>Please let me know your thoughts !<br>
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 ?</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Arnaud Vié<br>
</div>
</div>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<div>-- <br>
<p><font color="#000000">Aloha,<br>
<b><big><i>Michael Johnson</i></big></b></font><b><br>
<font color="#000070">
26 HIWALANI LOOP • MAKAWAO HI 96768-8747</font></b><font color="#000070"> • USA<br>
<a href="https://mljohnson.org/" target="_blank">mljohnson.org</a> • <a href="https://eBible.org" target="_blank">eBible.org</a> • <a href="https://WorldEnglish.Bible" target="_blank">WorldEnglish.Bible</a> • <a href="https://PNG.Bible" target="_blank">PNG.Bible</a><br>
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921<br>
Skype: kahunapule • Telegram/Twitter: @kahunapule • <a href="https://www.facebook.com/kahunapule" target="_blank">Facebook:
fb.me/kahunapule</a></font></p>
</div>
</div>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div>