Re: Postal address layouts?

[Pascal J . Bourguignon]

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
characters...

http://www.laposte.fr/sna/

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
email addresses.

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
structure.

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
country/network field.

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
your records.



-- 
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.