<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/01/2015 09:29 AM, DM Smith wrote:<br>
    </div>
    <blockquote
      cite="mid:D5186611-43ED-4D65-8544-8C739689BFD4@crosswire.org"
      type="cite">
      <pre wrap="">Having Abbreviation=KJV for a Thai module is clearly not the intent. To use it within a repo with uniqueness by language is entirely a bad idea.</pre>
    </blockquote>
    <font face="FreeSerif">I'm glad I didn't misunderstand this aspect.</font><br>
    <blockquote
      cite="mid:D5186611-43ED-4D65-8544-8C739689BFD4@crosswire.org"
      type="cite">
      <pre wrap="">Collisions are bad. There is always some nook or cranny in the code that has made some assumption about the [name].
</pre>
    </blockquote>
    <font face="FreeSerif">The fundamental issue is whether use of
      Abbreviation is for uni- or bi-directional usage, that is, output
      only vs. input and output.<br>
      <br>
      If Abbreviation is to be used as nothing but a display artifact,
      so as to show convenient, familiar, short names to users in
      headings and tabs and module lists and whatnot, then the problem
      is uni-directional and remains relatively simple.  This is
      "output" usage alone.  You can't make a mistake because nothing
      internal is ever looking at a module name as anything but the
      Real, and substitution is needed only at the last instant as code
      must scribble out the Abbrev instead.<br>
      <br>
      However, if Abbreviation is also a way for users and module
      authors to reference modules, then the problem is bi-directional,
      such that conflicts present themselves, and Abbreviation must
      become unique.  I put bi-directional capability into Xiphos, so
      that it both finds Real-&gt;Abbrev for display purposes as well as
      considers Abbrev-&gt;Real substitution in places like bookmarks
      and module-internal references: If a bookmark says "KJV Gen.1.1,"
      then Xiphos will see if there is an abbrev "KJV" to substitute
      before it navigates.  If a module contains an internal reference
      link to
      "sword://Josephus//The+Antiquities+of+the+Jews/Book+1/Chapter+1/Section+4"
      or "sword://Jub//Jub/5/6" (and one of mine has lots of these),
      then Xiphos will determine whether "Josephus" or "Jub" is an
      abbrev before it decides how to navigate the genbook pane.  This
      is "input" usage on top of "output" usage.<br>
      <br>
      Here's a fun implication: Xiphos speaks <a
        href="http://www.crosswire.org/wiki/BibleSync">BibleSync
        Protocol</a>.  When Alice's Xiphos navigates in her real KJV,
      BSP shovels out a nav packet showing KJV, after being potentially
      substituted Real-&gt;Abbrev,</font><font face="FreeSerif"><font
        face="FreeSerif"> because we in Crosswire app development should
        not expect other BSP-capable apps to understand our sometimes
        peculiar module names</font>.  Real KJV has no Abbreviation so
      it goes out as-is.  Now, as Bob's Xiphos receives this, it is
      treated as a potential abbreviation.  So Bob's Xiphos will do
      Abbrev-&gt;Real substitution on "KJV" to find "engKJV2006" and
      display that.  Now going the other way, Bob navigates his
      engKJV2006, generating a BSP nav packet with Real-&gt;Abbrev
      substitution showing "KJV" which will be analyzed as a potential
      abbrev by Alice, which will drive her Xiphos wrongly to display
      engKJV2006 if she has it installed even though she expected that
      "KJV" actually means real KJV that she was already using.</font><font
      face="FreeSerif"><font face="FreeSerif">  On the one hand, this is
        appropriate, given that this sort of usage is inherently both
        output from Alice and input to Bob in the 1st case, and vice
        versa</font> in the 2nd...but on the other hand it is wrong in
      its effect due to non-uniqueness.<br>
      <br>
      I don't see how one can avoid a need for uniqueness if
      Abbreviation applies to input.<br>
    </font>
    <blockquote
      cite="mid:D5186611-43ED-4D65-8544-8C739689BFD4@crosswire.org"
      type="cite">
      <pre wrap="">If there are ten KJVs in the list, how am I to know one from the other.</pre>
    </blockquote>
    <font face="FreeSerif">FYI, in Xiphos' module list trees -- sidebar,
      module manager, advanced search, and parallel bible/commentary
      selector trees -- modules with abbreviations show up as "Abbrev
      (Real)" so that it is clear to the user what he's getting when he
      sees the selections.</font>
    <blockquote
      cite="mid:D5186611-43ED-4D65-8544-8C739689BFD4@crosswire.org"
      type="cite">
      <pre wrap="">(I do like Peter’s suggestion of allowing the end user to change/add an Abbreviation for one or both. But it’ll be a while before all users upgrade to a front-end that has such support.)
</pre>
    </blockquote>
    <font face="FreeSerif">I am in the middle of adding code to Xiphos
      that [a] ignores Abbreviation when it collides with an existing
      real module name, and [b] provides for the user to change
      Abbreviation at any time, which value is also retained across an
      update (like CipherKey is retained), so the user can de-collide as
      he wishes.</font><br>
  </body>
</html>