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

[Karl Kleinpaste]

On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:
> 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.
"If all you do is..."

That's entirely the problem: That is /not/ 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.
> Module ID -> abbreviation is OK.
> abbreviation -> Module ID is not OK.
But it /must be made/ OK.

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 /cannot/ 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 /must/ 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 /must/ interoperate.

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.
> language ID + abbreviation -> Module ID is OK.
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.
> Stop doing that, and always require a full module ID whenever you want
> to find a module. (Requires some software rewriting and distribution.)
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.
> Require that all module abbreviations are globally unique across well
> over 1,000 translations.
> Let the user assign abbreviations and disallow assignment of a duplicate.
This is the solution needed, in combination: Abbreviations must be
unique, and conflicts must be resolved as they are encountered.
> 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.
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.

The alternative is for abbreviation references literally not to work as
input, yet they /must/.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20150902/8714cf5f/attachment-0001.html>