<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK. On my end with module generation,
I'll not worry about abbreviation uniqueness if there are strong
traditional abbreviations to use, but try to be unique most of the
time in module generation. Any conflicts that slip through
(especially across repositories) will be left to front ends and
users to resolve.<br>
<br>
On 09/02/2015 03:24 AM, Peter von Kaehne wrote:<br>
</div>
<blockquote cite="mid:1441200274.3051.8.camel@gmx.net" type="cite">
<pre wrap="">Karl, can I summarise :
1) Abbreviations need to be bidirectional
2) Uniqueness needs to happen at user-level for bidirectionality to
work. Not above.
3) Both across repos and internal to repos we can have one, some and
many modules which carry the same abbreviation - KJV being the most
notorious. It will be (see 2) up to the user to resolve this - but we
should make an effort to create sensible defaults.
4) Apart from all that, we should try and eliminate genuine
duplications and ensure that we do not confuse users more than
necessary. E.g. to have many KJV (English language 1769 King James
Bibles) modules is not desirable.
I think this is sensible and good.
Peter
On Wed, 2015-09-02 at 08:28 -0400, Karl Kleinpaste wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">"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.
</pre>
<blockquote type="cite">
<pre wrap="">Module ID -> abbreviation is OK.
abbreviation -> Module ID is not OK.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap=""> language ID + abbreviation -> Module ID is OK.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Stop doing that, and always require a full module ID whenever you
want to find a module. (Requires some software rewriting and
distribution.)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">This is the solution needed, in combination: Abbreviations must be
unique, and conflicts must be resolved as they are encountered.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<p><font color="#000000">Aloha,<br>
<i>Kahunapule Michael Johnson</i></font></p>
<table cellpadding="7" cellspacing="0">
<tbody>
<tr>
<td style="background: rgb(255, 255, 0)"><font
color="#000000"><b>MICHAEL JOHNSON<br>
PO BOX 881143<br>
PUKALANI HI 96788-1143</b><br>
USA</font></td>
<td style="background: rgb(0, 255, 255)"><font
color="#000000">
<a href="http://eBible.org">eBible.org</a><br>
<a href="http://MLJohnson.org">MLJohnson.org</a><br>
Mobile: +1 <b>808-333-6921</b><br>
Skype: kahunapule</font></td>
</tr>
</tbody>
</table>
</div>
</body>
</html>