> Okay, I'm pretty behind in all the bug reports, so forgive me if this has
> been reported already.
> LDs (and possibly other modules) with a ~ in the module name cause an
> error on load. The error reads: "LexDictRTFERaf~en" is not a valid
> component name. (ERaf~en is the module name.) I th
> The only additional restriction I would add, which you pointed out,
> would be to limit module names from beginning with a digit (to comply
> with xmlnames. And since you're the perl guy, there's a challenge for
> ya: come up with regex that defines the domain of a module name with the
> 'no p
>>Not sure what you mean? I thought [a-z,A-Z,0-9,_] was fairly explicit.
>
> It's explicit, but it looks entirely arbitrary. Can you identify how you
> decided upon this set?
Well, I can give you my justification again for this set, if you would
like. We need a set of values for unique iden
On Fri, 2 Aug 2002, Troy A. Griffitts wrote:
> [a-z,A-Z,0-9,_] are the only valid characters in module names.
>
> > Ok So can you actually cite a standard you are adopting here?
>
> Not sure what you mean? I thought [a-z,A-Z,0-9,_] was fairly explicit.
It's explicit, but it looks ent
> We can adopt XML Name, confined to Latin-1, if you would like. That
> adds [:\.] to the options but requires that the first character be
> in [a-zA-Z_:].
Note that ':' is reserved for XML namespaces! It is unreasonable to use it in module
names as module names, except probably of the case w
[a-z,A-Z,0-9,_] are the only valid characters in module names.
> Ok So can you actually cite a standard you are adopting here?
Not sure what you mean? I thought [a-z,A-Z,0-9,_] was fairly explicit.
> [a-zA-Z0-9_] is not sufficient. Using a standard of [source language
> id][separat
On Thu, 1 Aug 2002, Troy A. Griffitts wrote:
> >>[a-z,A-Z,0-9,_] are the only valid characters in module names. The
> >>module name should be changed.
> >
> >
> > Because?
>
> This standard is necessary for problems exactly as the one you've
> experienced in the win32 frontend. These are i
Friday, August 02, 2002 12:19 AM
Subject: Re: [sword-devel] Beta S bug
> > Then I strongly vote for adding an optional Displayname= or something
> > like that to the configuration files. I think it is not wise to
> > identify internal module identifier and screen display name --
> Then I strongly vote for adding an optional Displayname= or something
> like that to the configuration files. I think it is not wise to
> identify internal module identifier and screen display name -- these
> are two distinct concepts.
Yep, that's why we have 'name', 'description', and 'about'.
>This standard is necessary for problems exactly as the one you've
>experienced in the win32 frontend. These are internal names that need
>to be usable in standard encoding mechanisms such as programming
Then I strongly vote for adding an optional Displayname= or something
like that to the co
>>[a-z,A-Z,0-9,_] are the only valid characters in module names. The
>>module name should be changed.
>
>
> Because?
This standard is necessary for problems exactly as the one you've
experienced in the win32 frontend. These are internal names that need
to be usable in standard encoding mec
On Thu, 1 Aug 2002, Troy A. Griffitts wrote:
> [a-z,A-Z,0-9,_] are the only valid characters in module names. The
> module name should be changed.
Because?
Your standard looks rather arbitrary since this is the only problem I have
yet witnessed due to a module name with a tilde. Minimally i
[a-z,A-Z,0-9,_] are the only valid characters in module names. The
module name should be changed.
Chris Little wrote:
> Okay, I'm pretty behind in all the bug reports, so forgive me if this has
> been reported already.
>
> LDs (and possibly other modules) with a ~ in the module name cause an
Okay, I'm pretty behind in all the bug reports, so forgive me if this has
been reported already.
LDs (and possibly other modules) with a ~ in the module name cause an
error on load. The error reads: "LexDictRTFERaf~en" is not a valid
component name. (ERaf~en is the module name.) I think we
14 matches
Mail list logo