Re: proposed extensions for as-macro, community names
=> Some issues which seem to require further discussion: => => <string> length => Should we require the <string> to be more than one character => long? That is, should as-macro names such as "AS-A" be => illegal? If we require more characters, how many more => should we require? Alternatively, we could rely on commun- => ity pressure to discourage meaningless names. Don't put "artificial" requirements into the softwre, please. Though we might eventually agree on some operational rules. => => ending characters => Should we require as-macro names to end in an alphabetic => letter or digit? That is, should names such as "AS-ISP_" be => illegal? Alternatively, we could rely on community pressure => to discourage such apparently badly formed names. => No preference - unless there is a *distinct* advantage in implementation to disallow certain character combinations. => case sensitivity => Should the comparisons of as-macro names be case insensi- => tive? That is, should the database software consider the => as-macro name AS-EBONE to be the same as the as-macro name => as-ebone? = =Pick something and let's move on to real problems. I think the whole package is non case sensitive right now. Any specific reason to change that? I'd prefer to stick with *not* being case sensitive. => [....] = =Same here. = =I'm don't favor syntax checking for asthetically pleasing names, but I =don't plan to use really ugly ones either. Go either way. :-) I agree, don't put "style" into syntax rules... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------
participants (1)
-
Wilfried Woeber, UniVie/ACOnet