<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="FreeSerif">The particular example at hand is KJV vs.
engKJV2006. I know that Michael is removing the latter from
eBible repo, but this is a specific instance of a general
problem. So I will use it as my example.<br>
<br>
Problem: KJV is a real module name. engKJV2006.conf contains
Abbreviation=KJV.<br>
<br>
David Haslam noticed a glitch in my new Xiphos 4.0.4: If one is
currently displaying KJV, and uses the context menu by which to
change one of the module settings (e.g. en/disable Strong's or
morph), then engKJV2006 is substituted in display. The option
change requested is recorded for KJV, but engKJV2006 is displayed
according to its previously-defined options.<br>
<br>
The sequence by which Xiphos trips over this is:<br>
- Xiphos uses the real non-abbrev name KJV by which to change the
option requested. Fine so far.<br>
- Xiphos then constructs an internal URL by which to induce
re-render of the chapter under the new option setting, e.g.
sword://KJV/Gen.1.1. In principle, this is again fine so far.<br>
- This URL is handed to a different part of Xiphos which expects
to evaluate module abbreviations. Here, it finds that KJV is an
abbreviation for engKJV2006, so it substitutes the latter even
though KJV was being displayed and had just had its options
changed.<br>
<br>
The error is one-way: If KJV is displayed, and an option is
changed, engKJV2006 will be substituted. But if engKJV2006 is
displayed, and an option is changed, engKJV2006 will still be
displayed. This gives an odd "higher value" on the aliased name
rather than the real one.<br>
<br>
As I've thought about this, my conclusion is that the fundamental
problem is not that Xiphos wants to re-interpret potential
abbreviations so as to find real module names; rather, the problem
is that there is in effect <i>a pretender to the name</i>.
Abbreviation=XYZ must never name a real module already named XYZ.
This is an inherent semantic conflict that I think is not
reasonably resolvable. For example, some frontends including
Xiphos can be started using such a URL as a command line
argument. How is the user to get the real module, if the
abbreviated pretender is always to be preferred?<br>
<br>
I believe I would like to see us make a policy requirement
statement to this effect, i.e. that Abbreviation=XYZ must not name
an existing real module XYZ.<br>
<br>
Aside: Michael suggested that the Abbreviation config directive is
language-specific, i.e. if thaKJV2003.conf contained
Abbreviation=KJV, this would be an alias specific to the ภาษาไทย
(Thai) group of modules and would not "cross over" to English
modules. I cannot find any support for this specificity anywhere
in the wiki. Could someone more knowledgeable clarify?<br>
<br>
--karl<br>
</font>
</body>
</html>