Hi Joel,
<< That's an interesting (although severely non-trivial) approach to
the development issue...>>
Well, I never said it would be *easy*. :)
<<...but I was describing a property of the problem space itself. >>
Right. This is where my thinking diverges...I'm not sure to where.
Rather than trying to identify all the ways a phone number could be
formatted, because there are just too many of them even if we don't account
for typographical errors in formatting, let's just say that a phone number
is:
A bunch of numbers with, possibly, some separators at the start
or between them. Once you get to something other than a number,
separator, or one of our "special" text strings (e.g. x, ext, pin),
that's it.
OK, that's a little vague, so we need to add some more rules.
If it comes after <proper-name> 'at, that's a good clue.
If it comes after <number|cell|...> 'is, that's a good clue.
If it looks like one of the following, that's a *really* good clue.
551-1211
800-552-1212
1-800-553-1213
1+800-554-1214
800/555-1215
(800)556-1216
(800) 557-1217
800.558.1218
1.800.559.1219
If there are from 7 to 12 digits, and they're broken up
into tuple-like groups, that's a good clue.
If you find a proper name, and that name is in our address book,
you can verify their number or maybe their country at least.
Is this enough to handle all we might every want? Probably not. Do you want
to allow things like 1.2/3)4(5-6.7 8.9? Perhaps...no. :)
--Gregg
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
