<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/01/2015 09:45 PM, Kahunapule
Michael Johnson wrote:<br>
</div>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">The
uniqueness of an abbreviation is not required as long as you never
try to look up which module corresponds to that abbreviation. If
all you do is use the abbreviation as a short way to display which
text is selected, i.e. just looking up the abbreviation given the
module name, collisions are no big deal.<br>
</blockquote>
<font face="FreeSerif">"If all you do is..."<br>
<br>
That's entirely the problem: That is <i>not</i> all we (need to)
do. You are proceeding from false assumption. As DM said, you're
wrongly insistent on demanding uni-directional "output" use, as a
mere eyeball convenience. And that is simply not the case in the
real world, and actually hasn't been so for a long time, if it
ever was. Joe Average wants to type "KJV" in many contexts.
Module authors want to cross-ref into "KJV" in their content as a
matter of routine. Network protocols want to ship "KJV" as a
commonly-understood reference name.</font><br>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">Module
ID -> abbreviation is OK.<br>
abbreviation -> Module ID is not OK.<br>
</blockquote>
<font face="FreeSerif">But it <i>must be made</i> OK.<br>
<br>
You said to me in private email that you "live in a wider world
than Crosswire." I suppose that's true along one axis of
consideration. I live in a wider world than Crosswire along a
different axis: I am a network head, and absolutely positively
anything that threatens to share data from Hither to Yon (or from
Alice to Bob) must be not merely handled, but expected all the
time. You <i>cannot</i> expect that Bob will tell Alice -- the
nature of whose Bible app is unknown to Bob -- that her app should
locate a module absurdly named "engKJV2006." It is entirely
unreasonable to believe that other software producers will name
any module that way, and Alice's app may not be from Crosswire.
So common abbreviations are the way to achieve generality across
software architectures, and they <i>must</i> be accepted as input
that way. If Bob likes engKJV2006 as his KJV implementation,
great, and he should tell Alice that he's using (what he thinks of
as) "KJV," but Alice wants the official version as supplied for
her software. They <i>must</i> interoperate.<br>
<br>
A cardinal rule of the Internet since the ARPAnet days has been
"be conservative in what you send, and liberal in what you
accept." Conservatively, "KJV" is the correct way to identify the
King James Version to anyone on the planet. Liberally, "KJV" is a
correct identification of a Bible to be provided by someone else,
yet it is not unique in a (Crosswire or any other) world where KJV
and (something like) engKJV2006 try to co-exist.</font><br>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">
language ID + abbreviation -> Module ID is OK.<br>
</blockquote>
<font face="FreeSerif">No, it is not. At very best, you could claim
that you have reduced the breadth of conflict, but sometime next
week someone else will produce a different "Thai KJV" module that
they want to show up in our module selector lists, and so again
conflict resolution is needed because yours is not necessarily
special to Thai speakers any more than Crosswire's KJV is
necessarily special to English speakers. This example conflict
just happens to become localized to the subset of modules specific
to Thai. One cannot expect that there is always and forever
exactly one module implementation of XYZ in any language group.</font><br>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">Stop
doing that, and always require a full module ID whenever you want
to find a module. (Requires some software rewriting and
distribution.)</blockquote>
<font face="FreeSerif">Absolutely impossible, for all the reasons
discussed above. Users type Bible names, common names with which
they've been familiar since childhood. Commentary authors mention
those same common Bible names. Networks transport those same
common Bible names. The programmatic handlers of these names must
resolve such references to something in the user's (local) real
world. So Alice will tell Bob via BSP to find a certain verse in
"KJV" and Bob's preference for engKJV2006 as his "KJV" means he'll
get what he wants.</font><br>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">Require
that all module abbreviations are globally unique across well over
1,000 translations.</blockquote>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">Let
the user assign abbreviations and disallow assignment of a
duplicate.<br>
</blockquote>
<font face="FreeSerif">This is the solution needed, in combination:
Abbreviations must be unique, and conflicts must be resolved as
they are encountered.</font><br>
<blockquote cite="mid:55E654C3.7090107@gmail.com" type="cite">Personally,
I don't like the idea of burdening the user with managing unique
abbreviations, unless you have working defaults so that this level
of customization is not required.</blockquote>
<font face="FreeSerif">It is a mighty small burden: "By the way,
your set of modules has 1 naming conflict. Here's how to fix..."
As far as I know, at this moment, there are exactly 2 actual
conflicts, KJV and WEB. You have already made the former go away
by removing engKJV2006 from eBible; Crosswire will make the latter
go away by removing WEB from Crosswire main. But the problem is
general and could re-present itself tomorrow with some other name.<br>
<br>
The alternative is for abbreviation references literally not to
work as input, yet they <i>must</i>.</font><br>
</body>
</html>