by Jon Griffin

I. Introduction

This document describes the requirements for the ACS Location service package. This package has the following primary functions:

  • It allows applications to refer to and employ a common set of location data.
  • It gives administrators the ability to run standard reports on this data.
  • It offers a convenient repository for and the ability to run reports on location data.
  • It will allow for local independent storage of locations and some methods for validation of location specific data.

II. Vision Statement

What is so difficult about handling location data? The difficulty stems from the fact that there are no worldwide standards for representing location specific information. [insert some examples of the disparity of formats here]

Some examples of locations include:

  • Address
  • State
  • Point of Interest

Historically, locations have been modeled with the country or region the developers are living as the primary influence and this representational legacy has carried over to the web. The problem is that such a representation scheme falls significantly short due to notational as well as structural constraints imposed by each region’s local representation scheme for locations. For example, if locations are modeled on the US location representation scheme, locations will be identified via an ordered triple composed of City, State, and zip code. While the data to fill these fields may exist in other countries they need not all be present, nor will they necessarily be presented in the same order as we typically present them. For example, Russian city addresses take the following form:308061, Belgorod
A.R. 495

You can see that there are several issues that arise here:

  • We cannot appropriately represent the city name correctly in HTML, as the ‘R’ sound appearing therein is actually a cyrillic character
  • The order of the street number, city, and postal code is different than our normal representation.

There are plenty of other examples of this sort of problem throughout the world. Fortunately for us the International Postal Standards specify using the western character set as an accepted alternative. While there are ISO standards (ISO 11180) for addressing mail, this only goes so far to solving our dilemma, as it only indicates the standards by which the International Postal Service sends and receives mail. For example, according to ISO 1180 (9.3), The number of lines in a postal address shall be limited to six. Other requirements (ISO 7372) place line length at 30 characters, but you must use a 1/12 width spacing if a longer string is needed.The order of the elements can not be standardized and the sequence of elements is recommended to be written according to the appendix, but variance for country specific needs are allowed for. This is especially important in the case of postal codes (zip in the USA).

Another problem is genericizing a location. What is the base unit of a location? Probably at its most basic level of description it is a latitude and a longitude specifying the central point of the location in question. [need to say more here about why this is the case]

One of the goals of this module is to allow for validation and exportation of the data as efficiently and accuratly as possible. To that end I have decided to follow the HR-XML Postal Address DTD/Schema as a model. This is a schema that is designed to be flexible enough to be a global standard and useful for sending mail to individuals and/or companies. A broad overview breaks the schema into the following:

  • PostalAddress
    • CountryCode – mandatory
    • PostalCode – optional
    • Region – optional
    • Municipality – optional
    • DeliveryAddress – optional
    • Recipient – optional
  • DeliverAddress
    • AddressLine
  • Recipient
    • PersonName
    • AdditionalText
    • Organization
  • PersonName – This ideally should link to HR-XML personName object
    • FormattedName
    • GivenName
    • PreferredGivenName
    • MiddleName
    • FamilyName
    • Affix

III. System Overview

The ACS Location package consists of:

  • A standard framework for storing locations.
  • Methods to validate location types (address types).
  • Methods to parse the data into XML and other formats (csv).
  • Methods to pass this data to a mapping program such as GIS.

IV. Use-cases and User-Scenarios

[to be filled in]

V. Related Links

  • Design document

VI.A Requirements: Data Model

VI.B Requirements: API

VII. Implementation Notes

The package will require ACS Reference to be installed and enabled in order to function properly.

    VIII. Revision History

    $Log: requirements.adp,v $
Revision 1.1  2003/03/24 06:35:07  jon
initial cvs

Revision 1.1  2001/04/28 05:17:41  jon
initial version

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.