Re: [ubl-lcsc] [roe] OAG Comment: Structured vs. Unstructured Address

[Alan.Stitzer@marsh.com]

Again, the insurance industry also provides for this alternative.

The Address structure allows for either using Addr1 - 4 ...or DetailAddr
(StreetName, StreetNumber), then the rest of the Address.

We have an exclusive or between Addr1 and DetailAddr, but then Addr2-4 can
still be used.


____________________
Alan Stitzer
AVP
Marsh USA Inc.
1133 Avenue of the Americas
New York, NY 10036-2774
Phone: (561) 743-1938
Fax: (561) 743-1993
Internet: Alan.Stitzer@marsh.com
____________________


<<< Memo from tmcgrath@portcomm.com.au@Internet on 03 July, 2003, 10:41:58
PM Thursday >>>


tmcgrath@portcomm.com.au@Internet on 3 Jul 2003, 22:41 Thursday

To:    ubl-LCSC
cc:      (bcc: Alan Stitzer)
Subject:    [ubl-lcsc] [roe] OAG Comment: Structured vs. Unstructured
       Address


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



You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php



To:    ubl-LCSC@lists.oasis-open.org@Internet
cc:     (bcc: CN=Alan Stitzer/OU=NYC-NY/OU=US/OU=Marsh/O=MMC)
From:  tmcgrath@portcomm.com.au@Internet