[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Postal address layouts?
Pascal J . Bourguignon
Re: Postal address layouts?
Sat, 6 Sep 2003 06:52:19 +0200
Philippe C.D. Robert writes:
> Björn Giesler wrote:
> > Hi,
> > one more thing... I'm looking for postal address layouts for
> > different countries for the next release of Contacts.app. The
> > problem is that postal addresses are different for each country,
> > so I represent them in property lists looking something like this:
> > (("$Postfach", POBox),
> > (Street),
> > (ExtendedAddress),
> > (ZipCode, City),
> > (State),
> > (Country))
> > Each sub-array is a line as it would appear on a letter. Entries
> > starting with "$" are interpreted as literal strings, everything
> > else is a key into the data base. The proplist above contains all
> > the possible keys.
> > Please, could those who have a couple of free minutes hack
> > something like this together for their countries? I have German,
> > US and Romanian, and I need everything else.
> > Thanks a lot in advance,
> > --Björn
For France, there is a national standard for postal addresses. It
calls for 6 lines of 32 characters, given that standard abreviations
are used. On other documents, I've found specified lines of 38
AFNOR NF Z 69-300 (Octobre 1975) : Représentation de l'adresse postale
pour l'échange entre système de
traitement de l'information
(lignes 4 à 6).
AFNOR NF Z 10-011 : Règle de présentation de l'adresse postale.
(Présentation, positionnement, couleur, police, ...)
AFNOR NF EN ISO 3166-1 (country codes)
line 1: name and firstname or corporate name
line 2: apartment or postal box - floor - corridor - staircase or
service - recipient's identity
line 3: entry, tower, building, residence, industrial park...
line 4: number, extension, type and name of way
line 5: special mention of distribution, P.0. box, locality
line 6: zip code, cedex, city or cedex label
As you can see, there may be a lot a fields, optional or not. There
are also strange rules, for example for mail abroad, a seventh line
with the recipient country is added, and you may then prepend the
country code to the zip code FR-75007, DE-22767, etc).
So you'd have to have in your database any and all the optional fields
that appears perhaps in 1% of the addresses of 1% of countries? And
with field names, translated or not? For example, I've put "corporate
name", but the real title is: "raison sociale", and this is quite
different, because in "raison sociale" you have also, for example,
names of associations. So would you have in your database a field
"corporate name" for corporation, and "raison sociale" for French
"personnes morales" ?
And with more than 180 countries, it'll be a pain wherever you want to
track all the postal address formats...
Now, I'll make an analogy. Let's say you're trying to do the same
thing for email adresses. Let's see Internet email addresses and X400
In Internet email, you have the local part and the domain name
separated by '@'. The domain name is a sequence of names separated by
'.'. The last name represents vaguely the kind of organization, the
before last may be an organization name, and before departments,
services, and perhaps server name. The local part is about anything,
but you may sometimes find a structure in it, like: firstname '.' name
[ '+'|'-' subpart ]
In X400 email, you have complicated stuff, like: CN=NNNNN / OU=XXXXX /
O=YYYYY / P=ZZZZZ / A=TTTTT / C=FR, with an explicitely decomposed
So, you are about to make a database where you want the user to enter
the elementary fields, and have your program build an Internet email
address or an X400 email address, or a UUCP email address, or a BITNET
or a cc:Mail email address, etc depending on an additionnal
Don't you feel that's silly?
I do, and for that reason, I consider that postal addresses, like any
other addresses, while they may have a syntactic structure significant
for their systems, should not be interpreted or built by directory
applications, because their semantic is specific to their system.
Have a record of the "identificant" of the entity, whatever that may
be for the given culture of the entity, in France, that would be
firstname, family name; in Spain that would be firstname, first family
name, second family name, in USA, that would be firstname, middle
initial, family name, etc, don't mess with it, it depends on the
person, take it as a whole.
Have a record of the country, of the city, even of the zipcode as
separate field if you need them to do sorts or selections.
But have the postal address as a free form unique multiline field in
Do not adjust your mind, there is a fault in reality.