[
Lists Home |
Date Index |
Thread Index
]
AndrewWatt2000@aol.com wrote:
>> PHB: "Hey, we've got lots of invalid phone numbers in our documents!"
...
> Isn't the problem there the phone numbers which validate and which don't
> work? :)
It depends. In the project I grabbed the example from they found
shorcut numbers like "*35", which don't validate but work perfectly
well for the guys who configured their phones to map this to the
correct number. Also, internal phones need a special prefix, which
may differ dependent on how the local telephone system was configured.
This leads to series of corrections "Dumb! It's 001234567." "Geez,
they should now it is actually #901234567".
Straying a bit off the telephone number track, you might remember
the ZIP code reform in germany 10 years ago, where they suddenly
realized that what everybody regarded as a number until then was
really a string of digits, as new codes were introduced with a
mandatory leading zero.
There are lots of irregularities which break common assumptions on
certain data. Account numbers are no longer numbers if you want the
"number" to be the SWIFT id of a bank. You can't infer from the fact
that nobody yet had a total amount of securities in a depot which
overflowed a 10 digit number that this will never happen (and
unsurprisingly a program crashed because of this at the end of 1999).
There is a swiss municipality which is italian by telephone country
code, breaking the usual nationality->phone country code mapping.
There are quite a few villages where one half pays its tax to the
authority of region A, the other to region B, requiring you to
maintain a map by street/house number.
If you want to integrate several applications things tend to
become worse. Regardless how sophisticated the schema for the
data is, there's always an application with yet another exception.
Otherwise, you wouldn't need this application, I think. As Mike Kay
once noticed here "if you found two exactly matching fields, you
have a winner". This happens rarely enough, and no amount of CORBA
or Web Services standardisation is going to change this. Of course,
Web Services make it easier to transform the data while on transport,
which is one of the main reasons (together with NULL values) why they
will ultimately win over CORBA.
<rant mode off/>
J.Pietschmann
|
