[roe] OAG Comment: Structured vs. Unstructured Address

[Tim McGrath <tmcgrath@portcomm.com.au>]

To facilitate debate and consensus on the reviewed items, I am posting 
relevant issues as discussion points.  The intention is that after a one 
week period the team shall resolve these issues.  For example, this 
issue will be resolved at the call on Friday July 11th.

Item 6.

OAGIS has concluded that address line detail information has been widely 
implemented using one of two methods - a structured method where each 
property of an address line (e.g. house number, street name, unit) is 
captured as separate data elements [this is the current UBL method] or 
an unstructured method where address line 1, address line 2, etc. is 
captured as a string of text.  Both methods are perfectly valid and 
forcing one method as the standard (while preferable from a standards 
perspective) would be extremely burdensome for a large number of 
existing applications.

As a compromise position, OAGIS has implemented a xsd choice group which 
allows users to select either method but not both.  Choice groups are 
quite useful in these situations and while they are not specifically 
mentioned in CCTS v1.90, they are not expressly prohibited either.

There are three issues here:

a. Do we accept the need for unstructured address information?
b. is the line1, line2, line3, etc. approach the best way of doing this? 
 For example, the proposed alternative is not truly unstructured as it 
requires presentation structure (what goes on line 1, line 2 etc..). 
 truly unstructured would just be a text that is called AddressText.
c. How do we describe choice (e.g. may have either, but must choose one) 
in our spreadsheets?

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160