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

[Kahunapule Michael Johnson]

  
  
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.
  
  On 09/02/2015 03:24 AM, Peter von Kaehne wrote:


  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:

  
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

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

[DM Smith]

> On Sep 2, 2015, at 11:14 AM, Karl Kleinpaste  wrote:
> 
> On 09/02/2015 10:51 AM, David Haslam wrote:
>> those whose real module names include a lowercase
>> language code prefix are listed below all the modules that have a
>> capitalized [ModName].
> An unintentional side effect that I intend to try to fix, caused by the 
> modules arriving in the list in ModName order (straight from the Sword API), 
> with the Abbreviation then substituted.  I need to find a way to re-sort 
> before generating the list, but given the sequence of events, it's a bit of a 
> problem.
> 
> One catastrophe at a time.

Yes, one at a time! JSword has the same problem as I’ve been trying to weave in 
Abbreviation. There are lots of places that look odd now.

Right now, I’m trying to figure out whether we need to replace Set, which 
doesn’t allow for collisions, with List. Or what the the true internal module 
ID is for the key.

The displaying of that set is also a problem as we sometimes display a sorted 
list of Module names, other places Description.

— DM

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Karl Kleinpaste]

On 09/02/2015 10:51 AM, David Haslam wrote:
> those whose real module names include a lowercase
> language code prefix are listed below all the modules that have a
> capitalized [ModName].
An unintentional side effect that I intend to try to fix, caused by the
modules arriving in the list in ModName order (straight from the Sword
API), with the Abbreviation then substituted.  I need to find a way to
re-sort before generating the list, but given the sequence of events,
it's a bit of a problem.

One catastrophe at a time.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David Haslam]

And in the sidebar, those whose real module names include a lowercase
language code prefix are listed below all the modules that have a
capitalized [ModName].

So (e.g.) Brenton comes after Worsley.  (LOL)

David





--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655185.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Karl Kleinpaste]

On 09/02/2015 10:24 AM, David Haslam wrote:
> The sidebar (etc) now just displays "Abbrev: Description"
You're right, my mistake.

The display of "Abbrev (Real)" is restricted to the module manager,
which is where I figured it mattered most, or at all.  By the time the
user has installed a module, I think I figured that he'd know what he'd
done when seeing it in other contexts.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David Haslam]

Karl wrote,

"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."

That may have been the case in version 4.0.3 but it is no longer so in
version 4.0.4

The sidebar (etc) now just displays "Abbrev: Description"

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655179.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Peter von Kaehne]

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:
> 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 

Re: [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/.
___
sword-devel mailing list: sword-devel@crosswire.org

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

[DM Smith]

This assumes uni-directional use of an abbreviation. Once it is used for input, 
that is bi-directional, given by a user by typing or otherwise, it has a 
problem.

> On Sep 1, 2015, at 9: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 you look at both the language code and the abbreviation when doing 
> lookups, collisions are avoided.
> 
> Module ID -> abbreviation is OK.
> abbreviation -> Module ID is not OK.
> language ID + abbreviation -> Module ID is OK.
> 
> But the "not OK" case is in active use, now. Sigh.
> 
> Possible solutions:
> Stop doing that, and always require a full module ID whenever you want to 
> find a module. (Requires some software rewriting and distribution.)
> Require that all module abbreviations are globally unique across well over 
> 1,000 translations. (This precludes using locally meaningful and traditional 
> abbreviations in many cases, and results in longer abbreviations.)
> Let the user assign abbreviations and disallow assignment of a duplicate. 
> (You could suggest a default.)
> 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.
> 
> As an aside, finding and picking the Bible(s) you want to read has gotten a 
> bit more challenging. One long pulldown list isn't a great idea, now. It 
> helps to have a way to search with some sort of hierarchy, like 
> Country->Language->Translation and/or have a filter box to apply. This is 
> something we do in inScript. (See http://eBible.org/study/ 
>  or http://inScript.org  -- 
> the latter has more Bibles on it.) That is a front end issue I'm not going to 
> touch, right now, other than to point out the elephant in the UI room and go 
> back to making it even more challenging by adding more Bibles. ;-) 
> 
> On 09/01/2015 12:42 PM, Peter von Kaehne wrote:
>> On Tue, 2015-09-01 at 18:19 -0400, Karl Kleinpaste wrote:
>>> 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.
>> Michael explains that "KJV" is what is - at least in missionary circles
>> - used for the ThaiKJV. So, yes, this is the intent for Abbreviation as
>> a user friendly option.
>> 
>> Certainly I can see that within the Latin script area there may well be
>> clashes for some modules - and we should simply not ever assume that
>> the Abbreviation entry will always be unique across all repos and all
>> modules in existence. 
>> 
>> It _must_ be unique for a user - and either the computer or the user
>> must be able to resolve clashes.
>> 
>> But we should neither assume uniqueness nor rely upon that until a
>> frontend has given for a particular moment the "all clear".  
>> 
>> Peter
>> 
>> ___
>> sword-devel mailing list: sword-devel@crosswire.org 
>> 
>> http://www.crosswire.org/mailman/listinfo/sword-devel 
>> 
>> Instructions to unsubscribe/change your settings at above page
> 
> 
> -- 
> Aloha,
> Kahunapule Michael Johnson
> 
> MICHAEL JOHNSON
> PO BOX 881143
> PUKALANI HI 96788-1143
> USA   eBible.org 
> MLJohnson.org 
> Mobile: +1 808-333-6921
> Skype: kahunapule ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Kahunapule Michael Johnson]

  
  
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 you look at both the language code
  and the abbreviation when doing lookups, collisions are avoided.
  
  Module ID -> abbreviation is OK.
  abbreviation -> Module ID is not OK.
  language ID + abbreviation -> Module ID is OK.
  
  But the "not OK" case is in active use, now. Sigh.
  
  Possible solutions:
  
Stop doing that, and always require a full module ID
  whenever you want to find a module. (Requires some software
  rewriting and distribution.)

Require that all module abbreviations are globally unique
  across well over 1,000 translations. (This precludes using
  locally meaningful and traditional abbreviations in many
  cases, and results in longer abbreviations.)
Let the user assign abbreviations and disallow assignment of
  a duplicate. (You could suggest a default.)

  
  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.
  
  As an aside, finding and picking the Bible(s) you want to read has
  gotten a bit more challenging. One long pulldown list isn't a
  great idea, now. It helps to have a way to search with some sort
  of hierarchy, like Country->Language->Translation and/or
  have a filter box to apply. This is something we do in inScript.
  (See http://eBible.org/study/ or http://inScript.org -- the latter
  has more Bibles on it.) That is a front end issue I'm not going to
  touch, right now, other than to point out the elephant in the UI
  room and go back to making it even more challenging by adding more
  Bibles.  ;-) 
  
  On 09/01/2015 12:42 PM, Peter von Kaehne wrote:


  On Tue, 2015-09-01 at 18:19 -0400, Karl Kleinpaste wrote:

  
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.

  
  
Michael explains that "KJV" is what is - at least in missionary circles
- used for the ThaiKJV. So, yes, this is the intent for Abbreviation as
a user friendly option.

Certainly I can see that within the Latin script area there may well be
clashes for some modules - and we should simply not ever assume that
the Abbreviation entry will always be unique across all repos and all
modules in existence. 

It _must_ be unique for a user - and either the computer or the user
must be able to resolve clashes.

But we should neither assume uniqueness nor rely upon that until a
frontend has given for a particular moment the "all clear".  

Peter

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page




-- 
  
  Aloha,
  Kahunapule Michael Johnson
  

  
MICHAEL JOHNSON
  PO BOX 881143
  PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype: kahunapule
  

  

  


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Kahunapule Michael Johnson]

  
  
On 09/01/2015 12:19 PM, Karl Kleinpaste
  wrote:

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.

Good job. :-)

-- 
  
  Aloha,
  Kahunapule Michael Johnson
  

  
MICHAEL JOHNSON
  PO BOX 881143
  PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype: kahunapule
  

  

  


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Peter von Kaehne]

On Tue, 2015-09-01 at 18:19 -0400, Karl Kleinpaste wrote:
> 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.

Michael explains that "KJV" is what is - at least in missionary circles
- used for the ThaiKJV. So, yes, this is the intent for Abbreviation as
a user friendly option.

Certainly I can see that within the Latin script area there may well be
clashes for some modules - and we should simply not ever assume that
the Abbreviation entry will always be unique across all repos and all
modules in existence. 

It _must_ be unique for a user - and either the computer or the user
must be able to resolve clashes.

But we should neither assume uniqueness nor rely upon that until a
frontend has given for a particular moment the "all clear".  

Peter

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [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
.  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.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Peter von Kaehne]

On Tue, 2015-09-01 at 16:47 -0400, David 
> 
> So as a new frontend developer I'm confused. What is the purpose of 
> the Abbreviation conf entry and why world I want to use it over 
> module name which should already be shortish (at least compared to 
> title)?

If we could get it right then the Abbreviation conf entry will be
something entirely independent of the module ID aka ModuleName entry.

ModuleName entries - other than for English texts - do not really
reflect the names people give to their Bibles. I kind of got used to
GerLuther1912, but my Iranian friends have a bit of a problem with
FarFLB and would prefer Tafsiri or even تفسیری. 

Now with the addition of Kahunapule's repo and the 700 Bibles in there
the problem has become a universally accepted one, which is nice as it
was one for a long time ago, but took time to register in the more
anglocentric we have here.

At the moment we have endless foul compromises in our ModuleName
section and satisfy neither the need for a unique module identifier
across a growing number of repos with 1000s of texts nor do we really
satisfy the need of users to recognise texts for what they are, without
weird additions.

Does this make sense?

Peter

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[DM Smith]

> On Sep 1, 2015, at 4:47 PM, David Judah's Shadow Blue  
> wrote:
> 
> 
> So as a new frontend developer I'm confused. What is the purpose of the 
> Abbreviation conf entry and why world I want to use it over module name which 
> should already be shortish (at least compared to title)?

The [name] of the module is severely limited. When lowercased it is used as the 
name of a folder where the data files are kept and the name of the conf file. 
And in upper case it is used as the name of a zip. It is further constrained by 
an original definition of a windows INI file. As such, it is limited to upper 
and lower case a-z and to digits 0-9. Because of this usage, it has to be 
unique without regard to case in a repository. 

We were also having a tradition of module names that had non-English language 
designation as the prefix, such as Ger for German. Probably should have been 
prefixed w De or not at all.

This is not appropriate for languages that use other scripts or have lots of 
accents. Peter proposed Abbreviation as a means of providing what the very 
short, well known, internationalized name that is more appropriate.

Hope this makes sense.

In Him,
DM


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David "Judah's Shadow" Blue]

On September 1, 2015 3:59:09 PM EDT, Kahunapule Michael Johnson 
 wrote:
>On 08/31/2015 10:26 PM, David Haslam wrote:
>
>Yesterday, I added a note in the wiki page:
>http://www.crosswire.org/wiki/DevTools:conf_Files#cite_note-1 1. We
>strongly advise to avoid using an Abbreviation that's identical to the
>ModName or Abbreviation of any other module. It only leads to
>confusion, and may have unexpected consequences for some front-ends.
>Peter thought that this might confuse some module developers, but I'm
>more concerned about the unexpected consequences of the semantic
>problem at the software. 
>
>
>Yes. This module developer is confused. I can give you unique
>abbreviations or short abbreviations that match traditional usage.
>Choose one. You can't have both.
>
>-- 
>
>Aloha,
>Kahunapule Michael Johnson
>
>MICHAEL JOHNSON
>PO BOX 881143
>PUKALANI HI 96788-1143
>USA eBible.org
>MLJohnson.org
>Mobile: +1 808-333-6921
>Skype: kahunapule 
>
>
>
>___
>sword-devel mailing list: sword-devel@crosswire.org
>http://www.crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page

So as a new frontend developer I'm confused. What is the purpose of the 
Abbreviation conf entry and why world I want to use it over module name which 
should already be shortish (at least compared to title)?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Kahunapule Michael Johnson]

  
  
On 08/31/2015 10:26 PM, David Haslam
  wrote:


  Yesterday, I added a note in the wiki page:

http://www.crosswire.org/wiki/DevTools:conf_Files#cite_note-1

1. We strongly advise to avoid using an Abbreviation that's identical to the
ModName or Abbreviation of any other module. It only leads to confusion, and
may have unexpected consequences for some front-ends.

Peter thought that this might confuse some module developers, but I'm more
concerned about the unexpected consequences of the semantic problem at the
software.


Yes. This module developer is confused. I can give you unique
abbreviations or short abbreviations that match traditional usage.
Choose one. You can't have both.

-- 
  
  Aloha,
  Kahunapule Michael Johnson
  

  
MICHAEL JOHNSON
  PO BOX 881143
  PUKALANI HI 96788-1143
USA

eBible.org
MLJohnson.org
Mobile: +1 808-333-6921
Skype: kahunapule
  

  

  


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[DM Smith]

I forget what JSword and BD do now but it is different than back then. I’m 
pretty sure that Description doesn’t come into play anymore.

— DM

> On Sep 1, 2015, at 12:47 PM, David Haslam  wrote:
> 
> Hi DM,
> 
> Yep - collisions are bad.
> 
> I recall several years ago we had a conversation about having two versions
> of the same module in Bible Desktop, and being informed that there was a
> further requirement that the Description strings also had to be different. I
> don't think we ever documented this in the wiki.
> 
> For module developers, this is sometimes necessary. 
> i.e. To have both the last release and the update candidate version
> installed at the same time for comparison and testing purposes.
> 
> btw. I just noticed that for some IBT modules John has not used
> Abbreviation, but rather a xulsword custom property called TabLabel.
> 
> eg. in the module [TJK] he has 
> TabLabel=Таҷ
> 
> Many other IBT modules still use Abbreviation, e.g. for Localization in
> Arabic script ...
> Abbreviation=قىرع–ۉن
> 
> Regards,
> 
> David
> 
> 
> 
> --
> View this message in context: 
> http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655157.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David Haslam]

Hi DM,

Yep - collisions are bad.

I recall several years ago we had a conversation about having two versions
of the same module in Bible Desktop, and being informed that there was a
further requirement that the Description strings also had to be different. I
don't think we ever documented this in the wiki.

For module developers, this is sometimes necessary. 
i.e. To have both the last release and the update candidate version
installed at the same time for comparison and testing purposes.

btw. I just noticed that for some IBT modules John has not used
Abbreviation, but rather a xulsword custom property called TabLabel.

eg. in the module [TJK] he has 
TabLabel=Таҷ

Many other IBT modules still use Abbreviation, e.g. for Localization in
Arabic script ...
Abbreviation=قىرع–ۉن

Regards,

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655157.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[DM Smith]

> On Sep 1, 2015, at 9:01 AM, Peter von Kaehne  wrote:
> 
> On Tue, 2015-09-01 at 01:26 -0700, David Haslam wrote:
>> Yesterday, I added a note in the wiki page:
>> 
>> http://www.crosswire.org/wiki/DevTools:conf_Files#cite_note-1
>> 
>> 1. We strongly advise to avoid using an Abbreviation that's identical 
>> to the
>> ModName or Abbreviation of any other module. It only leads to 
>> confusion, and
>> may have unexpected consequences for some front-ends.
> 
>> 
>> Peter thought that this might confuse some module developers, but I'm 
>> more
>> concerned about the unexpected consequences of the semantic problem 
>> at the
>> software.
> 
> I continue to think this is a totally unwarranted piece of advice which
> is not only wrong but also seriously misguided. It replaces finding a
> solution for a annoying but surmountable problem with confusion and
> mess for users and module makers alike + has the added "benefit" of
> totally undermining the utility of "Abbreviation" in the first place. 
> 
> We have 1000 + modules between the different repos and no one - neither
> user nor module maker - should ever be forced to wade through these to
> make sure that an Abbreviation (which after all is for user
> convenience!) and nothing else is not duplicated somewhere else in a
> language or a in a ModuleName most users might not ever want to use. 
> 
> Karl has pointed at a problem in Xiphos  (and possibly beyond) which
> will need attention, but no solution of it should ever result in the
> above "advice" being implemented as a fix.
> 
> We should have a clear and unique _internal_ module ID which is not
> replicated anywhere, based on some form of name space per publisher
> (Xiphos, IBT, CrossWire, eBible, Net, whoever) and the ModuleName and
> then, quite separate from that a free form, UTF8  Abbreviation, which
> might or might not be delivered by the module maker, but should
> certainly be open to users (re)defining for their own use.  
> 
> If a module is newly installed or its Abbreviation renamed by the user
> with a clashing Abbreviation then this is a problem, but the frontend
> should be able to take care of that. It should be relatively easy
> addition to most frontends to run a consistency check at start or
> whenever something changes and say "Ouch, you got two modules you
> choose to call "Luther", can you please fix this?" with the user then
> renaming one to e.g. Luther1912 and/or the other to Luther1984. 
> 
> URI's - the place where Karl found his problem - are in essence
> internal pieces of data and should be based on the Module ID to be
> consistent, clear and unique across the local system and preferentially
> beyond (e.g. for sword URI's on the net or wherever). At least when
> they leave the system they should not be based on Abbreviation.
> 
> A translation table for Abbreviations<->Module ID could be a flexible
> and dynamically created and updated table, depending on what modules a
> user has up and running. 
> 
> Greg's suggestion for the user to make a choice whether to have the URL
> handler run with Abbreviation or ModuleName (did I understand you
> right, Greg?) remains an option, but does not really solve the problem
> of Abbreviation clashing with each other (rather than with ModuleName).

The point of Abbreviation was that [name] had to be A-Za-z0-9 w/o spaces, punct 
and such and didn’t allow for localization. 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. (While I’m not a typical user, I have every 
module I can get my hands on.)

Collisions are bad. There is always some nook or cranny in the code that has 
made some assumption about the [name].

In the case of BibleDesktop, we had used the [name] in a dropdown. Which is 
really silly looking with a 1000 modules. But it is worse when I added 
Abbreviation support. If there are ten KJVs in the list, how am I to know one 
from the other. (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.)

Right now SWORD and JSword has a single, joint local module repository for 
storage. This means that if there are two different modules with the same 
DataPath or conf name a collision occurs.

Does there need to be a local repository for each?

Does any front end do this already? If so, what are the naming conventions and 
pathing to it? I’d like for JSword based front-ends to use and provide the same 
downloaded modules.

— DM



___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Peter von Kaehne]

On Tue, 2015-09-01 at 01:26 -0700, David Haslam wrote:
> Yesterday, I added a note in the wiki page:
> 
> http://www.crosswire.org/wiki/DevTools:conf_Files#cite_note-1
> 
> 1. We strongly advise to avoid using an Abbreviation that's identical 
> to the
> ModName or Abbreviation of any other module. It only leads to 
> confusion, and
> may have unexpected consequences for some front-ends.

> 
> Peter thought that this might confuse some module developers, but I'm 
> more
> concerned about the unexpected consequences of the semantic problem 
> at the
> software.

I continue to think this is a totally unwarranted piece of advice which
is not only wrong but also seriously misguided. It replaces finding a
solution for a annoying but surmountable problem with confusion and
mess for users and module makers alike + has the added "benefit" of
totally undermining the utility of "Abbreviation" in the first place. 

We have 1000 + modules between the different repos and no one - neither
user nor module maker - should ever be forced to wade through these to
make sure that an Abbreviation (which after all is for user
convenience!) and nothing else is not duplicated somewhere else in a
language or a in a ModuleName most users might not ever want to use. 

Karl has pointed at a problem in Xiphos  (and possibly beyond) which
will need attention, but no solution of it should ever result in the
above "advice" being implemented as a fix.

We should have a clear and unique _internal_ module ID which is not
replicated anywhere, based on some form of name space per publisher
(Xiphos, IBT, CrossWire, eBible, Net, whoever) and the ModuleName and
then, quite separate from that a free form, UTF8  Abbreviation, which
might or might not be delivered by the module maker, but should
certainly be open to users (re)defining for their own use.  

If a module is newly installed or its Abbreviation renamed by the user
with a clashing Abbreviation then this is a problem, but the frontend
should be able to take care of that. It should be relatively easy
addition to most frontends to run a consistency check at start or
whenever something changes and say "Ouch, you got two modules you
choose to call "Luther", can you please fix this?" with the user then
renaming one to e.g. Luther1912 and/or the other to Luther1984. 

URI's - the place where Karl found his problem - are in essence
internal pieces of data and should be based on the Module ID to be
consistent, clear and unique across the local system and preferentially
beyond (e.g. for sword URI's on the net or wherever). At least when
they leave the system they should not be based on Abbreviation.

A translation table for Abbreviations<->Module ID could be a flexible
and dynamically created and updated table, depending on what modules a
user has up and running. 

Greg's suggestion for the user to make a choice whether to have the URL
handler run with Abbreviation or ModuleName (did I understand you
right, Greg?) remains an option, but does not really solve the problem
of Abbreviation clashing with each other (rather than with ModuleName).

blessings

Peter
 


> 
> David
> 
> 
> 
> --
> View this message in context: http://sword
> -dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs
> -Abbreviation-XYZ-tp4655148p4655154.html
> Sent from the SWORD Dev mailing list archive at Nabble.com.
> 
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page


___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David Haslam]

Yesterday, I added a note in the wiki page:

http://www.crosswire.org/wiki/DevTools:conf_Files#cite_note-1

1. We strongly advise to avoid using an Abbreviation that's identical to the
ModName or Abbreviation of any other module. It only leads to confusion, and
may have unexpected consequences for some front-ends.

Peter thought that this might confuse some module developers, but I'm more
concerned about the unexpected consequences of the semantic problem at the
software.

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655148p4655154.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[David Haslam]

We know that xulsword also makes use of Abbreviations, primarily for
Localization (just as they were intended), so it would be useful to have
some response from John.


Now that we have an IBT repository, if I install one of the IBT modules
using Xiphos, because xulsword recognizes my sword path in Windows, it can
display two copies of the same module at the same time, the other having
already been installed by xulsword itself to its own modules path. The two
modules may even be different versions.  Because module selection is by
Abbreviation, it's not so easy to know which one is being selected when
there are two with the same.  Though this might be somewhat confusing to the
user, it does not seem to cause any critical problem to the application
software.

I should also mention that I had long ago added the xulsword resources
directory as a local modules source for Xiphos.  e.g.

C:\Users\David\AppData\Roaming\IBT\MK\Profiles\resources

So vice versa applies.

Regards 

David



--
View this message in context: 
http://sword-dev.350566.n4.nabble.com/Re-Semantic-problem-real-module-names-vs-Abbreviation-XYZ-tp4655150p4655152.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Greg Hellings]

3) Use the same model as operating systems do for opening urls or file
types that have multiple registered handlers. Let the user select which to
use and possibly set a default.
On Aug 31, 2015 8:49 PM, "Peter von Kaehne"  wrote:

> My take on this is following:
>
> To have a rule of no clash for abbreviations with ModuleName is
> unreasonable. The whole point of Abbreviation is that i can name my modules
> how they are named in common parlance. Irrespective of if there is
> somewhere else, in a language i do not care about a module which uses
> module's Abbreviation as ModuleName.
>
> At the same time, soneone who has two modules installed where a clash is a
> problem needs a way out.
>
> Two options:
>
> 1) let the user fix it if there is a clash, assist the user finding
> clashes, e.g. during install.
>
> 2) do not allow Abbreviation in the url.
>
> Peter
>
>
>
> Sent from my phone. Apologies for brevity and typos.On 31 Aug 2015 23:59,
> Karl Kleinpaste  wrote:
> >
> > 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.
> >
> > Problem: KJV is a real module name.  engKJV2006.conf contains
> Abbreviation=KJV.
> >
> > 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.
> >
> > The sequence by which Xiphos trips over this is:
> > - Xiphos uses the real non-abbrev name KJV by which to change the option
> requested.  Fine so far.
> > - 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.
> > - 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.
> >
> > 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.
> >
> > 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 a pretender to the name.  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?
> >
> > 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.
> >
> > 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?
> >
> > --karl
> ___
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

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

[Peter von Kaehne]

My take on this is following:

To have a rule of no clash for abbreviations with ModuleName is unreasonable. 
The whole point of Abbreviation is that i can name my modules how they are 
named in common parlance. Irrespective of if there is somewhere else, in a 
language i do not care about a module which uses module's Abbreviation as 
ModuleName. 

At the same time, soneone who has two modules installed where a clash is a 
problem needs a way out. 

Two options:

1) let the user fix it if there is a clash, assist the user finding clashes, 
e.g. during install.

2) do not allow Abbreviation in the url. 

Peter



Sent from my phone. Apologies for brevity and typos.On 31 Aug 2015 23:59, Karl 
Kleinpaste  wrote:
>
> 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.
>
> Problem: KJV is a real module name.  engKJV2006.conf contains 
> Abbreviation=KJV.
>
> 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.
>
> The sequence by which Xiphos trips over this is:
> - Xiphos uses the real non-abbrev name KJV by which to change the option 
> requested.  Fine so far.
> - 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.
> - 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.
>
> 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.
>
> 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 a pretender 
> to the name.  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?
>
> 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.
>
> 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?
>
> --karl
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page