[sword-devel] Namespace Proposal re eBible - collissions, duplication, clean-up etc

[John Austin]

Peter is right. Looking toward the bigger and brighter future, the 
module name should be an internal code to represent a particular text 
from a particular publisher. By "publisher" I mean whoever actually 
created the module, not the copyright holder. If another publisher wants 
to issue the "same text" they need to give it their own module name. 
Since it has been through their publishing preparations, it is indeed 
their own unique publication, and is always potentially different from 
that of any other publisher. This is the most logical approach to module 
naming, and happens to be the most trouble-free solution.

-john



On 09/04/2015 03:16 AM, Peter von Kaehne wrote:
> In terms of precendent:
>
> the Wycliffe repo uses namespaces in modulenames. Per copyright owner
> rather than repo publisher, but still.
>
> [lang]_[namespace]_[year] is the form of modulenames there.
>
> For reasons David has mentioned - small displays, this is not ideal.
> [lang]{year](namespace] or
> [lang][abbr][namespace] and
> [lang[[abbr][year][namespace] is clearly better. No wasted spaces dt
> underscors and the user relevant stuff at the front.
>
> Peter
>
>
> On Thu, 2015-09-03 at 21:59 +0100, Peter von Kaehne wrote:
>> On Thu, 2015-09-03 at 14:32 -0400, DM Smith wrote:
>>
>>> If I’m right then one could rename the kjv.conf to whatever
>>> -kjv.conf
>>> and it would work just as well.
>>>
>>> If this is the case, then the conf can have a namespace prefix.
>>
>> yes, that will work. At least for Sword. I have not tested JSword on
>> it. The conf file name and the module name are entirely independent
>> of
>> each other. Just convention keeps them the same.
>>
>>> 3) This leaves the problem of collisions of module name and
>>> abbreviation.
>>
>> The former (collision of two pre-existing identical modulenames) will
>> not be solved by your proposal, but will be solved by mine.
>>
>> The collision of Abbreviations with each other is in essence
>> unavoidable if we want to allow free choice of abbreviation, but will
>> need to be resolved by the user. None of the proposals will nor can
>> resolve this
>>
>> Collision of Abbreviation and ModuleName is a software bug in
>> frontends
>> and needs to be resolved there and not here.
>>
>> Peter
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>