<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Robert's point about also standardizing Scripture metadata with
      the ScriptureBurrito standard is a good one.</p>
    <p>USX's limitations relative to OSIS are both an advantage and a
      disadvantage. Because USX is more focused on primarily Scriptures,
      it has the advantage that the markup is less ambiguous and more
      likely to be understood by someone else who just read the
      standard, but had no additional information. It is clearly better
      as an interchange format between applications. OSIS is probably
      better for non-Scripture texts, or would be if it had enough
      software support. Ironically, constraining the ways in which data
      can be represented makes it easier to represent a richly formatted
      Bible. Importing from a ScriptureBurrito could include not only
      the USX Bible text, but metadata for our config files.<br>
    </p>
    <p>Both USX and OSIS lack style sheets that say how data should be
      presented, since both are (mostly) semantic markup. Paratext uses
      external style sheets for this purpose, at least for display
      within that program. Various other publishing paths have their own
      style sheets, which are not really standard.<br>
    </p>
    <div class="moz-cite-prefix">On 2/18/24 11:41, Robert Hunt wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:c994f38c-0fee-4388-ab25-495c53a3f01e@gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>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.<br>
      </p>
      <p>So for a fair comparison with OSIS, I think you'd have to
        specify USX  <b>along with ScriptureBurrito metadata</b>: see <a
          href="https://www.burrito.bible/" moz-do-not-send="true">https://www.Burrito.Bible</a>
        (which is also in the process of being supported by the most
        influential Bible-translation orgs AFAIK).</p>
      <p>Blessings,<br>
        Robert.<br>
        <a href="https://OpenEnglishTranslation.Bible"
          moz-do-not-send="true">https://OpenEnglishTranslation.Bible</a><br>
      </p>
      <div class="moz-cite-prefix">On 19/02/24 10:19, Michael Johnson
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:d429b565-10e8-4102-92f9-1f863fa46b24@eBible.org">
        <meta http-equiv="Content-Type"
          content="text/html; charset=UTF-8">
        <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/"
            class="moz-txt-link-freetext" moz-do-not-send="true">https://ubsicap.github.io/usx/</a>.
          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.</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 class="moz-cite-prefix">On 2/18/24 09:42, Michael H wrote:<br>
        </div>
        <blockquote type="cite"
cite="mid:CAJ9hia8J-B-uoH3GGQ9ALLtiBaG7RD9_vXXPYHR0KgqqiPKCWg@mail.gmail.com">
          <meta http-equiv="content-type"
            content="text/html; charset=UTF-8">
          <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"
                moz-do-not-send="true" class="moz-txt-link-freetext">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"
                moz-do-not-send="true" class="moz-txt-link-freetext">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"
                moz-do-not-send="true">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" moz-do-not-send="true">a mailing
                    list dead since 2015</a>, <a
                    href="https://wiki.crosswire.org/Category:OSIS"
                    target="_blank" moz-do-not-send="true">a few wiki
                    pages</a> and <a href="https://crosswire.org/osis/"
                    target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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é</div>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </blockquote>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
    </blockquote>
    <div class="moz-signature">-- <br>
      <meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
      <title>signature</title>
      <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/">mljohnson.org</a> • <a
            href="https://eBible.org">eBible.org</a> • <a
            href="https://WorldEnglish.Bible">WorldEnglish.Bible</a> • <a
            href="https://PNG.Bible">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">Facebook:
            fb.me/kahunapule</a></font></p>
    </div>
  </body>
</html>