"Yair Friedman (Jerusalem)" <[EMAIL PROTECTED]> writes:
> Alex Schroeder <[EMAIL PROTECTED]> writes:
>
> > Therefore: Shall we move to plain strings or not?
>
> What are the other choices?
I'll try to list the choices we have with pros and cons:
1. new file format with only plain string zip codes
+ easier to write more code
- new file format annoys people
- all zip codes are stored as plain strings, therefore
no validation (canonicalization) on the input side
o formatting (canonicalization) for output can be done
using the (customizable) address formatting functions
2. add plain strings as "yet another zip format"
+ no file format change
+ non-string zip codes are automatically formatted (canonicalized)
for output
- code base remains baroque
- unrecognized zip code formats result in zip code being stored
as plain strings, therefore no validation (canonicalization)
on the input side
o formatting (canonicalization) for output can be done
using the (customizable) address formatting functions
3. do nothing
+ zip codes are validated (canonicalization) on the input side
- for each new zip code format we have to update the code
- code base remains baroque
o formatting (canonicalization) for output can be done
using the (customizable) address formatting functions
Options 1 and 2 can be augmented by validation mechanisms:
1. Sam Steingold said that he might write something up that
canonicalized zip codes.
2. I recommended a customizable list of regexps that tell us wether a
zip code is well formed. I think it would be easy to write a
string matching and replacing function which can use information
like this:
(("\\([A-Z][A-Z]?\\)\\s *-\\s *\\([0-9]+\\)" . "\\1-\\2")
("\\([0-9][0-9][0-9][0-9][0-9]?\\)\\s *-\\s *\\([0-9][0-9][0-9][0-9]?\\)
. "\\1-\\2"))
etc.
Alex.
--
http://www.geocities.com/kensanata/emacs.html
_______________________________________________
bbdb-info mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/bbdb-info
