4.2.3.3 Addresses
Description
Addresses can vary from one culture to another. The following table provides examples of different address
formats.1
Table 4-7. Address Formats
| Country |
Format |
Notes |
| China |
[<Country>]
<Province> <City>
<Address1>
<LastName> <FirstName> <Honorific> |
<Province>, which is represented by two uppercase letters in parentheses, is used only if the city is not a province
capital. The line with <Country> should use a negative indent. |
| Italy |
<Title> <FirstName> <LastName>
[<CompanyName>]
[blank line]
[<Country>] |
Numbers, for example, house numbers, are always at the end of <Address> for example, via Palmanova 12.
An optional blank line between <Address> and <Country> makes the address easier to read. |
| Russia |
[<Country>]
<PostalCode>
[<State or Republic>] [<Region>] <City>
<Address1>
<Address2>
[<CompanyName>]
<LastName>
<FirstName> <SecondName> |
The <State or Republic> and <Region> fields are used only used in the following cases:
- Letter is sent to another state
- City is not the capital of the region, for example, Moscow Region, Zvenigorod
- Letter is sent from another state to a city that is not a regional capital, in which case both the name of the state
and the name of the region are indicated, for example, Russia, Moscow Region, Zvenigorod.
If <FirstName> and <SecondName> contain only initials followed by periods, it is more appropriate to include these
fields on the same line with <LastName>, for example, LastName A. B. |
| Denmark |
[<Honorific> <Title>] <FirstName> [<SecondName>] <LastName>
[<CompanyName>]
<Address1>
<Address2>
[<CountryCode> ]<PostalCode> <City>
[<Country>] |
Some countries have very special requirements if sending mail outside the country; Denmark is an example of this.
The first and second lines can appear in reverse order, that is, <CompanyName> on the first line and <Honorific> to
<LastName> on the second.
There are two spaces between <PostalCode> and <City>. The postal code is four digits, without a separator.
If mail is sent from abroad to Denmark, the prefix "DK-" (<CountryCode> plus one hyphen) is added to
<PostalCode>. |
| Finland |
[<Title>] <FirstName> [<SecondName>] <LastName>
[<CompanyName>]
<Address1>
<Address2>
<PostalCode> <City>
[<Country>] |
Some countries have special requirements, depending on the mail recipient; Finland is an example of this.
The personal name appears first if the letter is of a personal nature, but the company name appears first in a business
letter. |
1. Rhind, Graham, Global Sourcebook of Address Data Management: A Guide to Address Formats and Data in 194
Countries, Gower, 1999.
Command Line Interface
Addresses can be entered or returned on the command line. The command can take address values in a single order for all
locales, or in a locale-specific order. Likewise, when displaying an address as output, the address can be shown according to the
locale format or it might have a generic display format with labels for the different components to clarify the listing.
Character Interface
Character interfaces can use a freeform field or several labeled fields for address input. In a freeform field, the
user types the address in the exact format preferred. When the address is retrieved for display, it can be returned exactly the way
it was entered. However, if the individual fields are used for other purposes, for example, to enable a database search for entries
from a particular city, then the fields are divided. When returned for display, they might be in the same format as the entry
screen, or they might be formatted according to locale.
Graphical Interface
See "Character Interface."
Application Protocols
Application protocols handling address data can take the data as a delimited string or as individually labeled fields.
They require the address to be in a specific format, which is unlikely to be locale-specific.
Storage and Interchange
Addresses are usually stored in databases, broken down into their components. In some cases, however, they might be
stored as a freeform text field.
Application Programming Interfaces (APIs)
Sometimes, special APIs that use locale-specific rules are provided for address formatting. If they are available, you
should use them. If they are not available, you can use product-specific APIs or pre-constructed templates for address formatting.
Requirements for Compliance
Command Line Interface
No special requirements for providers.
The following requirements apply to consumers:
- Consumers must either specify one format for all addresses, or a format for each supported locale.
- If an address is returned as output, it must either be in the locale-specific format, or in a format with labels for
each of the components.
- All components necessary for the addresses of the platform-supported locales must be available, though not all are used
in each locale.
Character Interface
No special requirements for providers.
The following requirements apply to consumers:
- If a user interface is used to create an address, it must be flexible enough to enable locale-specific formatting.
- No assumption can be made with regard to the amount of information required or the order of each component.
Graphical Interface
See "Character Interface."
Application Protocols
Providers must accommodate all possible components of addresses in the platform-supported locales.
Consumers must supply protocols with appropriate components and label elements, where relevant.
Storage and Interchange
Providers must accommodate all possible components of addresses in the platform-supported locales.
Consumers must supply appropriate components and locale information, where relevant.
Application Programming Interfaces
The following requirements apply to APIs:
- Ensure that formatting rules for addresses are separate from the source code, configurable, and accessible through
system-sensitive or language-sensitive platform APIs.
- Provide product-specific APIs or pre-constructed templates if platform APIs are not available.
- Ensure that all characters required for addressing can be input and displayed.
|
|
Print-friendly Version
