<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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/">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">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>
  </body>
</html>