[sword-devel] Semantic problem: real module names vs. Abbreviation=XYZ

[Karl Kleinpaste]

On 09/01/2015 09:29 AM, DM Smith wrote:
> 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.
I'm glad I didn't misunderstand this aspect.
> Collisions are bad. There is always some nook or cranny in the code that has made some assumption about the [name].
The fundamental issue is whether use of Abbreviation is for uni- or
bi-directional usage, that is, output only vs. input and output.

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.

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->Abbrev for display purposes as well as considers Abbrev->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.

Here's a fun implication: Xiphos speaks BibleSync Protocol
<http://www.crosswire.org/wiki/BibleSync>.  When Alice's Xiphos
navigates in her real KJV, BSP shovels out a nav packet showing KJV,
after being potentially substituted Real->Abbrev,because we in Crosswire
app development should not expect other BSP-capable apps to understand
our sometimes peculiar module names.  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->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->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.  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
in the 2nd...but on the other hand it is wrong in its effect due to
non-uniqueness.

I don't see how one can avoid a need for uniqueness if Abbreviation
applies to input.
> If there are ten KJVs in the list, how am I to know one from the other.
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.
> (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.)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20150901/83a13aa0/attachment.html>